Skip to content

August 17, 2012

Paid Upgrades on iOS – The Greedy Developer Guide

by Russell Ivanovic

So you’re a full-time independent developer, and you’ve had an app in the store for four years, for which you’ve released regular free updates. Revenue for the app has dried up, because everyone who has ever bought a copy can’t buy it again. You have ongoing costs; servers to run, mouths to feed. You decide it’s time to be ‘greedy’ and ask your customers for more money. This is exactly where we at Shifty Jelly found ourselves with our flagship product ‘Pocket Weather AU’. First released in 2008, it’s been the lifeblood of our company, oustripping the earnings of all our other apps by a large amount. It’s basically keeping the lights on here at the 3 man Shifty Jelly Office.

At this point you have two choices: release new features via an in-app purchase, or create an entirely new app to sell. To us, an in-app purchase was not really feasible because we wanted to start again on the application, hooking it up to a brand new server, use brand new code, write brand new controls and frameworks for it. Offering this update as an in-app purchase would mean trying to ship the old code and old image assets along side the new code and new images. If you’re not a developer, you’ll have to trust us when we tell you this is nigh-on impossible.

So we were left with only one choice: release a paid update, as a brand new app. The problem is Apple don’t give you a way to do this, and if I’m being cynical I’d say they don’t want you to do this. Their goal is to sell iPhones, and I think that deep down they know that if people feel apps are free or cheap and updated forever, Apple will sell more iPhones.

So what do you do? Well here’s what we did, hopefully you can learn from it.

Initial Transition:

  • We created our new application and submitted that to Apple for approval, setting the release date to the future so it wouldn’t go live in the store until we were ready.
  • Once it was approved we removed our old app from sale and left things for a few hours. This is because the App Store takes a while for changes like that to propagate.
  • When we were ready to release the new one, we set the release date to now. Again we didn’t promote it straight away giving it a few hours to propagate through the store. Even when you see it in the store, you still might not be able to download it, we’d recommend 4 hours minimum here. Even after 4 hours a small amount of people still couldn’t download the app, but eventually that sorted itself out.

Now we had to figure out phase 2 of our master plan, how to tell people beyond those who read our blog and follow us on Twitter? In the past it appears like you may have been able to update apps that are not for sale in any country (see this blog post, which has since been updated after the author and I chatted on twitter). Unfortunately this is no longer the case. So let me explain how we found this out, and what other tests we did. In our case we had 2 existing free versions (one for iPad and iPhone) that we could play with (both removed from sale about a week before our new app went live), so here’s what we did:

  • Created an update for these apps, linking to the new paid version and also telling our customers there was an update.
  • Released the update to Apple which they approved.
  • We waited 2 days to see if it became available as an update to people’s phones. 2 days later it still hadn’t.
  • Then we tried putting the free Apps back in the store (by ticking the countries in iTunes Connect) and bam, an hour later they became available as updates.
  • To test another theory, we un-ticked the countries again the next day, and an hour later the update once again disappeared.

The simple conclusion: The ONLY way to update apps not for sale in the App Store, is to put them back into the App Store until everyone that wants to update to them has. The one minor exception to this is that when a customer tries to re-download an app from their ‘Purchased’ section, they will get the most up to date version, regardless of whether you’ve put it back in the store or not. It should be noted that the ‘Purchased’ section of the App Store is horribly broken. The search feature in it simply doesn’t work. If you’ve bought 500 apps like I have, scrolling through it while it lags, jitters, and keeps jumping back to the top will make you want to poke your eyes out.

Update: A helpful developer on Twitter pointed out that you can actually still link to apps in the purchased section, like this (this confused us at first, because it only works on the device, not on a desktop):

http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftwareRedownload?id=APP_ID_GOES_HERE&mt=8

So yes, paid updates are possible, but you’ll have to work hard to get it to happen, and there’s no such thing as a perfect transition. As a developer I can’t tell you how much I’d like Apple to support this, because if they did it would be better for us and users alike. Imagine having your favourite app release a massive update, offer you an upgrade price, and you having the option to accept or decline. Imagine if you decline still getting bug fixes for your current app, and one day rewarding the developer by buying the app.

So finally to show that I’m young and hip, here is my TL;DR:

  • There’s no way to release a paid update on the iOS App Store, you have to release a new app.
  • You can’t pull the old app from the store, and provide future updates for it. If you want to update it, the old version must also be in the store, and remain in the store.
  • Apple will probably never support this, and it’s time as developers we stopped this crazy ‘race to the bottom free updates for ever’ mentality, and start restoring the notion that developers also need to get paid, and there’s no inherent weirdness or shame in that.

Comments are closed.