Marco Arment, writing about iOS’ Auto-Renewable subscriptions, which appear to be exclusive to apps that deliver “new content” during each renewal period:
Ultimately, I had to ship Instapaper 4.0 with non-renewing subscriptions, I was able to delete all of the clunky auto-renewing server code, nobody sees that terrible dialog in my app, and I need to ship an update soon that will annoy my best customers with manual-renewal notifications.
But this is a great example, like Newsstand Kit’s background downloads, of Apple adding a capability to iOS that’s potentially useful to thousands of developers, and then restricting it so that only a handful of players (usually big companies) can actually use it.
I hope that, in time, they unbundle some of these myopically targeted enhancements and make them potentially useful to all developers. But Apple’s record on this isn’t great so far.
Marco is right – auto-renewable subscriptions are easy to use (and understand) and more developers should get access to it. Imagine being able to subscribe to Instapaper through iTunes, or getting your Evernote Premium account billed automatically every year or month, instead of having to purchase it manually (as it happens now). But I could argue that, at the same time, new technologies like Newsstand Kit’s background downloads (described here) and auto-renewable subscriptions are more of a conceptual and technical issue for Apple rather than a “limitation” imposed to developers. Imagine if every app in the Store went free, and started billing users periodically for “usage”. That would create an unrealistic ecosystem of free apps with in-app subscriptions for all kinds of content. I’m not saying apps like Instapaper shouldn’t get access to auto-renewable subscriptions – it actually seems like a perfect fit to me – but I believe that instead of going on a case-by-case basis, Apple decided to roll out the feature for “publishers of new content” first. That’s easier to scale.
It gets murkier with the background downloads of Newsstand. Periodicals and newspapers get this neat implementation of automatic downloads of new issues. Would a third-party app like Instapaper benefit from it? Sure. Imagine being able to have your Instapaper queue delivered to you wirelessly, each morning, instead of having to download it manually (which takes seconds but it’s still a manual action). That’d be great. Or the aforementioned Evernote, which could, in theory, figure out a way to push changes from its remote database once per day without a user’s direct action (case in point: I add a lot of items to Evernote on my Mac overnight, I see all the changes automatically pushed to my iPad the next morning). Again, I believe some apps should get this functionality for increased usability and overall enjoyment of the user, but there are exceptions I’m fairly certain Apple considered. What if every developer of every app starts implementing background downloads for remote content? Even once per day, for every app, it can be a lot of data. And when you add data caps to the mix and start imagining games that can download new levels remotely on 3G…not good.
Obviously, if we follow this argument – that every developer should get access to the latest technologies used by Apple, or that at least some developers should be able to – we could say that Apple did figure out solutions in the past to avoid problems with, say, data caps and 3G downloads. Granular controls, like “Use Cellular Data” in the Store’s Settings, or the common limit of 20 MB for App Store downloads on 3G. But again, imagine a scenario where every developer gets to implement subscriptions or background downloads. Is the user supposed to go through a list of 100+ apps and switch every single one of them to “off” for background downloads? And if the list is a bad idea, and we argue again that only some apps should get these features – why, say, just Instapaper or Evernote? Why not Infinity Blade II?
Last, it is true Apple doesn’t have a great record for bringing iOS’ enhancements to third-party developers in a short period of time – but keep in mind that the iPhone launched without multitasking and background applications and eventually got one of the best implementations of multitasking out there and background tasks (for some apps) up to 10 minutes. The other side of the coin, obviously, is that third-party apps can’t run in the background all the time like Apple’s Music app - but the same question rises again: can you imagine every single developer doing that? (Speaking of enhancements in Apple’s apps: I expect Mail’s rich text controls to be opened up next to developers for integration. And did anyone mention Siri?)
In the past four (almost five now) years, Apple has taught us (and the industry) that iOS isn’t about big press releases and revolutions as much as it’s about incremental progress, iterative improvements and refinements. Apple rolls in its very own way, and looking back at the differences between iPhone OS 1 and iOS 5, it’s clear that a lot of work went into all the updates and fixes and changes that got us this.
Developers rightfully want access to cool new features as soon as they’re available (especially when they seem such a good fit) and users are always eager to see the latest software functionalities implemented in delightful new ways, but the App Store’s ecosystem is so variegate and unique that sometimes waiting is the best option.