Posts tagged with "developers"

Apple Cracking Down On Sites Selling Access To iOS Betas

Last month, Andy Baio wrote a story for Wired detailing the world of selling access to Apple beta software to non-developers. Specifically, Baio’s piece focused on sites that, for a price, allowed regular people to have their UDID (unique device identifier) activated for installation of iOS betas, which Apple makes available for developers only. To install an iOS beta, a developer has to register his/her account with Apple, which costs $99 per year and allows for the configuration of 100 devices in the so-called “Provisioning Portal” through the aforementioned UDID.

While becoming a registered developer costs $99, sites selling UDID activation did so for a low price, usually within the range of $10. Baio wrote:

For a small developer, unauthorized activations are a lucrative business that’s likely worth the risks. UDID Activation publishes their order queue on their official site, which shows more than 2,300 devices activated in the last week alone. At $8.99 for each activation, that’s more than $20,600 in revenue, with $2,277 paid to Apple for the 23 developer accounts. Their homepage claims that more than 19,000 devices were activated so far, and that’s only one of several services. And since device activations only last for a year, each service can reuse their expired slots with no additional cost.

After noticing several of the sites mentioned in Baio’s article had become unavailable in recent weeks (activatemyios.com, iosudidregistrations.com, activatemyudid.com, udidregistration.com, instantudidactivation.com), we reached out to some of them asking whether Apple was behind the takedown of their “services”, which infringed on Apple’s developer agreement. While most of our emails bounced, we heard back from one of the site owners (who asked to remain anonymous), who confirmed his hosting provider took down the site after a complaint for copyright infringement by Apple. Similarly, the CEO of Fused tweeted in a reply to Andy Baio that Apple had been “fairly heavy-handed” with DMCA requests to UDID-selling sites hosted on their network.

In the email, the site owner said that their website made $75,000 since last June, when Apple released the first beta of iOS 6 to developers. “We do not believe our service was infringing and our services did not violate their guidelines for iOS 6”, the site owner commented, adding that they will soon launch another similar site, “with better and more secure data lines to handle Apple”.

The owner of another site replied to our emails with a “no comment”. According to him, “the Wired article has caused all these sites to go down”.

Indeed, it appears Apple has started taking action against these sites recently, and more precisely after Wired ran the story on UDID activation. Last year, Apple reportedly closed developer accounts of people who sold their available UDID slots to other users; this year, it appears Apple has chosen the more direct path of shutting down websites and their services by filing DMCA requests to their hosting providers.

When Wired published its story, Apple added that “unauthorized distribution is prohibited, and may be subject to both civil and criminal liability”. It is unclear whether Apple terminated memberships to the Developer Program this year as well.

Surprisingly, one of the most popular sites selling access to iOS betas, udidactivation.com, is still online. However, their “UDID order queue” – a webpage displaying the amount of total sales – fails to load, and the same page on their “backup site”, udidactivation.us, displays the latest sales as being from June 28.

Apple seems to have taken action against sites selling access to OS X beta downloads, as well. A popular one, iMZDL.com, put a notice on their website saying “we will no longer be putting up downloads on iMZDL.com for Apple Betas”. Their website is still up, and rather than hosting the download links themselves, they have now switched to torrents for sharing links to iOS and OS X betas.

As we previously wrote, access to Apple beta software should be restricted to developers, as they know how to provide meaningful feedback and report bugs to Apple.

Apple Removes Negative Reviews From Apps Affected By DRM Bug [Updated]

Earlier this week, an error in Apple’s DRM code generation for App Store apps caused a number of app updates to crash on launch. The issue, initially reported by Instapaper developer Marco Arment, began spreading to more than 100 iOS and Mac app updates including GoodReader, Angry Birds HD Free, and The Early Edition. As the bug was causing updated apps to crash immediately after launch without even displaying an error message, several users became upset with the developers of the apps – as they didn’t know the issue was on Apple’s servers – and began leaving negative reviews on the App Store. Developers, on the other hand, had to deal with a issue that they couldn’t fix, while explaining to customers how they should back up their data and wait for a solution.

Last night, Apple officially acknowledged the issue and explained it was associated with DRM code generation on the App Store. Apple said they had fixed the issue, and Macworld reported that, according to their sources, Apple would also remove all negative reviews that had been left during the hours the bug was spreading on various international App Stores.

As of this morning, it appears Apple has indeed removed negative reviews from apps affected by the bug. Apps like Instapaper, GoodReader, and The Early Edition are showing no reviews for the latest versions available, which are the ones that were crashing earlier in the week. We haven’t checked on every single app that was affected, but it is safe to assume at this point Apple will remove all reviews (not just negative ones) from any app that received a corrupted update.

Apple hasn’t issued a public apology to developers, but the removal of reviews will definitely help in leaving this issue behind without having to deal with the aftereffects on the App Store as well.

Update: As noted by several readers on Twitter, it appears Apple didn’t completely wipe the old reviews left during the DRM outage – it re-issued app updates for the same version of the app, and moved the “Current Version” reviews to “All Versions”.

In spite of the version being the same – for Instapaper, the affected version was 4.2.3 – the old reviews are not showing up in the Current Version section of the App Store. This helps hiding possible negative reviews from the section that it loaded by default in iTunes.

By re-issuing the old version as an update again, Apple is making sure customers can re-install the fixed version of an app without having to delete it first, as noted by Marco Arment. It is unclear whether the old reviews will still affect overall ranking of an app.

App Store Adding New “Food & Drink” Category

The App Store will soon be updated with a new “Food & Drink” category, according to developers of existing iOS applications who received an email from Apple today about the upcoming change. “In the next few weeks”, applications will be automatically migrated to the new category; currently, the App Store doesn’t provide a specific category for these types of apps, which have been typically listed under Lifestyle by their developers. According to Apple, the new category will include “apps that help users cook and bake, mix drinks, manage recipes, find new restaurants and bars, and learn what their friends like to eat and drink”. Food & Drink won’t include diet, grocery shopping, coupon clipping, or food-related game apps.

The new category is another change coming to the App Store, which Apple has been tweaking and revamping with new features lately. Ahead of a major redesign coming with iOS 6, Apple re-organized its selection of Editor’s Choice apps and App of the Week selections, providing a standalone category with weekly updates. Recently, Apple also started grouping previous game bundles into a macro category accessible from the App Store’s homepage.

The dedicated Food & Drink category comes after thousands of apps have been successful in using iOS devices as tools to manage recipes and find local restaurants. Notably, iOS 6 will also feature Yelp check-ins in the new Maps applications – a renewed focus on this area that will surely benefit from a new category on the App Store.

Currently, Apple only offers a custom Cooking section to showcase handpicked app selections for recipes, drinks, shopping, and reference material.

Update: the new category will appear “in the next few weeks” according to Apple.

The World Of Selling Access To iOS Betas→

The World Of Selling Access To iOS Betas

Andy Baio reports on the not-so-underground world of selling access to iOS betas to people who are not developers, but are simply interested in trying the latest OSes during their beta stages.

For a small developer, unauthorized activations are a lucrative business that’s likely worth the risks. UDID Activation publishes their order queue on their official site, which shows more than 2,300 devices activated in the last week alone. At $8.99 for each activation, that’s more than $20,600 in revenue, with $2,277 paid to Apple for the 23 developer accounts. Their homepage claims that more than 19,000 devices were activated so far, and that’s only one of several services. And since device activations only last for a year, each service can reuse their expired slots with no additional cost.

Without having to read the warnings that Apple puts on the Developer Center (and that, as Baio details, appear to be completely ineffective against sellers of paid activations), it’s important to remember that betas need to be tested by developers because only people with a technical knowledge can report bugs, send feedback, and lead to a better final product. The iOS beta isn’t meant for the general public: it is a an ongoing collection of changes, updated APIs, and visual refinements that only a developer can properly evaluate, understand, and criticize.

That’s not to say regular users shouldn’t be interested in trying the latest toys before they are released because Apple’s site says so. We at MacStories, too, have access to iOS betas but we are not developers ourselves; however, that access is necessary to have a better understanding of things to come (without breaking the NDA). The negative side-effect of spreading iOS betas to users who aren’t willing to treat them for what they are – betas – is, instead, a worrying amount of iTunes reviews for apps that can’t be updated for iOS 6 yet. We have written about this last year, and Rene Ritchie recently posted his thoughts on the matter as well.

It’s okay to be curious about the future. But the proliferation of “UDID Activation” websites has generated a number of repercussions on third-party developers, and that’s a problem Apple needs to fix.

Permalink

Why Upgrade Pricing Isn’t Coming To The App Store

The 2012 WWDC keynote has come and gone, and we now know which of the many rumored announcements turned out to be true and which turned out to be false. But there was one unrumored announcement many developers were hoping would be true that failed to materialize altogether: the option to offer paid upgrades and true demo versions for their apps.

Demos and paid upgrades are something that App Store developers (where “App Store” encompasses both iOS and Mac) have long since wanted, as Wil Shipley explained in his blog post “The Mac App Store Needs Paid Upgrades” and as John Gruber and Cabel Sasser discussed on episode 5 of The Talk Show. No doubt there are many Apple users, especially longstanding Mac fans, who would be happy for the opportunity to support their favorite developers and be rewarded with lower prices for new versions of their favorite apps as well (the “99¢ IS TOO EXPENSIVE” crowd need not apply). As Shipley’s post lays out, it would seem there are many good reasons for Apple to implement these. So why haven’t they?

I think it comes down to one of Apple’s core values: simplicity.

The fact that Apple chose to name their online retail presence the “App Store” is, I think, telling. Remember that Apple aims squarely for the mass market (much to the consternation of some advanced and pro users) and remember what shopping at a real life store is like for that market.

When most people go to a store, they don’t expect to take home products that catch their eye and try them out for a limited time. They don’t expect to get reduced prices on the latest version of a product they’ve paid for before. The retail model of a typical store from a consumer’s point of view is simple. You walk in, look for something you want, pay for it, and walk out. This is exactly how Apple’s physical stores work, and it is how their digital stores are designed to work as well.

Whether this is the way digital stores should work is another discussion, and one that is certainly well worth having. But if we assume that this is how Apple wants their stores to work, their policies for not allowing demos and upgrades make sense. In Apple’s physical stores, and indeed nearly all retail establishments, take-home trials and upgrade pricing is nearly unheard of. At best they offer demo units of products you can try, but only ones they choose and only while you remain at the store. Try insisting on half-price for the next-gen MacBook Pro with Retina display because you bought a 13” MacBook Air two years ago and see how far you get before you’re asked to leave.

Developers and longtime computer users may be used to the shareware, time trial, pay-full-price-once-upgrade-cheaply-forever model of buying and selling software, but regular people, the mass market that Apple continues to court first and foremost, aren’t. Adding demos (“I thought this app was free, but now it’s telling me I have to pay to keep using it? What a ripoff!”) and paid upgrades (“Wait, I bought this app last year and now I have to pay again to keep using it? Screw that!”) would introduce a layer of confusion and make buying an app a more arduous process, which would result in people buying fewer apps.

At least, that’s the rationale behind Apple’s decision not to implement them. To be clear: what I just wrote is not my opinion of how things should be. This is only my guess at Apple’s reasoning.

So if Apple is basing their digital stores on their physical ones, how should developers like Wil Shipley and Cabel Sasser handle the problem of making enough money from past and future customers in order to eat and make more cool software? I think Apple thinks they should take cues from how Apple handles their own software transitions: no upgrade pricing, just one reasonable price that is palatable to its target audience. Make your software great and easy to buy, and more people will buy it.

Yes, there are edge cases where some unlucky customers will fall through the cracks (those who bought your old app right before the new one came out) and those who won’t be happy to pay again for the “same” app regardless of how much time has passed (two words: “Tweetie 2”). And it would be great for customers and developers alike if Apple implemented a way to stop selling an old app but still let devs provide bug fixes. But Apple knows that while you can’t please everyone, you can make good money by pleasing the majority. And as long as the majority likes affordable, straightforward app-buying, that’s what they’ll continue to offer.

Apple’s Phill Schiller On App Store Curation and Promotion For Developers→

Apple’s Phill Schiller On App Store Curation and Promotion For Developers

In an interview with The Wall Street Journal published yesterday, Apple’s Phill Schiller weighed in on App Store curation, promotion of third-party apps, and traditional retail selling space.

The opportunity is the best it has ever been for software developers,” Mr. Schiller said, adding that he thinks the app store is a far more democratic way to sell software than traditional retail stores with limited shelf space.

Mr. Schiller also pointed out that Apple promotes apps in multiple ways, such as popularity charts and featured app lists. “Every other day you hear about another app going off the charts,” he said. “You can still get discovered and get a hit overnight.

There’s no doubt Apple has done a “tremendous amount” (Schiller’s words) to help apps get discovered on the App Store. With the iPhone and the App Store, Apple created a new economy that, in the U.S. alone, has spurred the creation of over 200,000 jobs. But as I have outlined last month, the App Store of 2012 isn’t the same that launched in 2008 to 900 apps: there are over 650,000 apps on the App Store today, and while Apple has done a lot for developers, it could optimize the layout of the Store to do more and better. I wrote:

Custom sections provide a decent solution to browse titles Apple has previously “curated”; however, these sections aren’t usually updated as often as they are created — N.O.V.A. 3, a new shooter game by Gameloft, still isn’t listed under Benchmark Games: Stunning Graphics, whilst the majority of reviewers and publications have outlined the game’s remarkable graphic capabilities.

The IconFactory’s Craig Hockenberry also noted how Apple could bring its “personal touch” to the App Store to showcase great software with different methods than simple Top Charts, or “curated lists” that are often abandoned and never updated.

Instead of fighting for a short-term placement in the Top 100 lists, we’d fight for a long-term product review. Look at the amazing things developers do to earn an ADA and imagine if that happened once a week. Earning that “Apple approval” could ensure a product’s success for a long time. Which would be great for both customers and developers alike.

Hopefully Apple is thinking about this stuff. Earlier this year they acquired app recommendation service Chomp, and they revamped their “App of the Week” section with a new “Editor’s Choice” tag. The redesigned App Stores of iOS 6 come with Facebook integration and improved layout for descriptions and screenshots, something developers have been asking for. It’s too early to tell, but it seems like the iOS 6 App Store is on track to deliver great improvements for navigation and user interaction this Fall; to improve discoverability and promotion, however, Apple should also consider tweaking longstanding minor, yet important aspects such as filters, search, and Category sorting options.

Read the full interview with Schiller (who also confirms a new tracking tool for developers being discussed at WWDC sessions) here.

Permalink

The Siri API→

The Siri API

Samuel Iglesias has written an excellent post detailing the (possible) challenges developers will have to cope with if Apple decides to release a Siri API.

The second half of Siri integration, Semantics, is the tricky part: something that most iOS developers have never dealt with. Semantics will attempt to capture the various ways a user can ask for something, and, more importantly, the ways Siri, in turn, can ask for more information should that be required. This means that developers will need to imagine and provide “hints” about the numerous ways a user can ask for something. Sure, machine learning can cover some of that, but at this early stage Siri will need human supervision to work seamlessly.

This is exactly what I have been wondering since speculation on the Siri API started last year. How will an app be capable of telling Siri the kinds of input (read: natural language) it accepts? Will developers have to do it manually? Will Apple provide a series of automated tools to associate specific features (say, creating a task in OmniFocus) with common expressions and words? And how is Apple going to look into the natural language processing developers will implement in their apps?

Of course, the Siri API is still at the speculation stage, but it does make sense to greatly expand upon Siri’s capabilities as an assistant capable of working with any app. The TBA sessions at WWDC are intriguing, and Tim Cook said we’ll be pleased with the direction they’re taking with Siri. Right now, I’d say integrating with third-party software would be a fantastic direction.

Permalink

Mac App Store vs Buying Direct→

Mac App Store vs Buying Direct

Wolf Rentzsch has published a good piece outlining the pros and cons of buying software through Apple’s Mac App Store, or directly from a developer’s website.

Some developers are going out of their way to allow seamless cross-grading from Mac App Store versions of their apps to direct apps, which is commendable and helps alleviate somewhat the situation Apple has created. Sandboxing is just the latest App Store rule change, I’m sure there’s more to come. All things being equal, it’s safer to buy directly instead of being cut off from your own software based on an arbitrary Apple policy change.

Sandboxing may be the latest requirement to get apps on the Mac App Store, but the trade-off involved with selling software through Apple’s channel has stayed the same since 2011: exposure vs. risk of change due to Apple’s policy. Because the environment is controlled and actively promoted by Apple, a developer gets all the perks of a store pre-installed on every Mac: millions of potential customers whose buying decision is just a click away, and nicely designed sections to showcase new apps (though Apple has to do more). On the other hand, because Apple gets to decide which apps and which functionalities are safe for the App Store, changes happen, like Sandboxing.

For the user, the convenience of the Mac App Store is obvious. Purchases are tied to an Apple ID, updates are easy, and the ecosystem is integrated with an existing structure (iTunes). Unlike John Gruber, I don’t think Sandboxing will be compelling for typical users, as I don’t see Apple showcasing Sandboxing-enabled apps the way they did for iCloud-enabled apps or apps updated with Lion features. It’s too technical, but Apple may figure out a way to market it (perhaps again the “Apps Enhanced for OS X Lion” section with new additions).

For developers, the Mac App Store means exposure to millions of eyeballs but also to Apple’s ever-changing strategies and technologies. The problem with Sandboxing, I believe, is that it introduced a change that is forcing developers of existing apps to reconsider functionalities that are not compatible with the Mac App Store anymore. If this will lead to serious fragmentation of Mac software with a proliferation of deeply different Mac App Store and “website versions” of the same apps, we’ll see.

Also worth reading: Lex Friedman’s story at Macworld on the first day of Sandboxing in the Mac App Store.

Permalink

Apple Confirms Sandboxing Deadline For Mac App Store Apps on June 1

In an email sent to registered Mac developers earlier today, Apple has confirmed it will begin enforcing a deadline on Sandboxing for Mac App Store apps on June 1, 2012.

As a reminder, the deadline for sandboxing your apps on the Mac App Store is June 1. We’ve made the process easier with new sandboxing entitlements and APIs now available in OS X 10.7.3 or later and Xcode 4.3.2.

If you have an existing app on the Mac App Store that is not sandboxed, you may still submit bug fix updates after June 1. If you have technical issues that prevent you from sandboxing your app by June 1, let us know.

Previously pushed back from November 2011 to March 2012, and then again from March to June 1, 2012, sandboxing is a new technology aimed at limiting an application’s access to certain areas of OS X through a system based on entitlements. As we wrote in February:

Sandboxing is a new technology in OS X Lion that limits the functionalities of Mac App Store applications to a list of “entitlements” that cover various areas of the operating system an app can access, such as networking, printing, or a user’s files. A sandboxed application would be unable to harm the system outside of its operational scope (managed by the entitlements), and this has caused some concerns as apps would lose access to the Mac’s entire filesystem, which is required by some functionalities of certain applications that aren’t necessary malicious or “compromised”. Similarly, inter-app communication would be a technical issue with sandboxing, as apps like TextExpander, Keyboard Maestro and CoverSutra — utilities that perform actions in the background without asking for user’s interaction in some cases (user-initiated actions can override the sandbox) — couldn’t get past the sandboxing requirement for the Mac App Store.

With today’s reminder, Apple has confirmed that new apps submitted to the Mac App Store after June 1 must adopt sandboxing, whilst existing apps that are not sandboxed will still be available to receive bug fix updates. Earlier this week, a report suggested that, in relation to the upcoming sandboxing deadline, Apple was also looking into “banning” new apps with “hotkey” functionality, though it appears that such policy won’t take effect, according to several sources. Recently, several OS X developers expressed their wish for Apple to further delay the sandboxing deadline to the end of June in order to better explain the ramifications of the technology at the upcoming WWDC. Unfortunately for those developers who were hoping for a revised deadline for apps that have proven to be incompatible with sandboxing, WWDC kicks off on June 11 – 10 days after the sandboxing deadline.

A number of Mac applications using Sandboxing are already available on the Mac App Store. Most notably, 1Password by AgileBits implemented the technology back in September 2011, and others like Edovia’s Screens for Mac and, recently, Pixelmator were updated with support for sandboxing as well.