Hacking Paid Upgrades in the App Store

During last week’s Talk Show John and Cabel discussed the state of paid upgrades in the App Store. Around an hour into the show they hit on something that I hadn’t considered before.

Can you still support the old, replaced version of an app if you remove it from sale?

The typical scenario for doing a paid upgrade in the App Store as this stand today runs as follows:

  1. You have an existing app in the store currently for sale (let’s call it Widget).
  2. You create and submit a new version of your app (let’s call it Widget 2), setting the release date to some day in the far future.
  3. When Widget 2 gets approved you change the Rights and Pricing for Widget to remove it from sale by delisting it in all countries. This changes its state to Developer Removed from Sale.
  4. You then change Widget 2’s release date to be today. Widget 2 is now released and the old version has disappeared from the App Store.

This is the pattern used by a number of application developers who saw a need to get upgrade revenue from a major update. I believe the earliest and best known example was the transition from Tweetie to Tweetie 2 back in 2009. This process works but is fairly horrible for customers. It is especially hard on users who just bought your application the day before the update who now would have to purchase it again to get the new version.

This topic has been talked to death of the years so I don’t particularly want to address it in depth. Though I will say that I agree with Apple’s policy to not provide a mechanism for it within the store. I think that the current system is best for customers and has created the most financially successful marketplace for developers in history.

What I am interested in is what developers who choose to do a paid upgrade can do to help support and enhance their customer’s experience. After digging around in the App Store app and iTunes Connect I found two little known mechanisms that I think may help with the transition.

Linking to the old version

After pulling the Widget from the App Store one tricky question becomes what happens to users who had purchased the old copy but now want to install it again. This often happens when they get a new device. The tricky part of this question is that searching in the App Store will only turn up the new version. It turns out that if you navigate to the Updates > Purchased in the App Store app you can still get the old pulled version.

This is a terrible user experience because the list of purchased apps is likely huge and so finding the exact app in question is difficult. Thankfully it looks like you can link directly to pulled apps via the following link scheme (replacing the id with your app’s iTunes ID):

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

This link only works on device (iPhone or iPad) but provides a simple way to answer the support question of “How do I reinstall the software I purchased before?”. Just send them the link and they should be all set.

Providing Bugfix updates to the old version

I’ve heard from many people who think that this isn’t possible. That once you pull an app from the store you must essentially abandon it. __That is simply not true__. So long as you don’t actually __delete__ the old version of the app within iTunes Connect you can continue submitting updates to apps even while they are in the _Developer Removed from Sale_ state. Whether this is intentional functionality is unclear but I have verified that it does in fact work and the resulting approved updates are available for customers.

Update (Aug, 2012): It appears this App Store behavior has changed since my initial writing. The fine folks over at Shifty Jelly tried it when making an update to their Pocket Weather AU app and they were only able to get the update to be visible to users by making it also available for sale. You can still link to old versions but cannot provide bugfix updates to users.

Conclusions

Neither of these two tricks really fix the user experience when doing a paid upgrade. I would still recommend avoiding this pattern. While it might generate a bit of revenue there are better mechanisms (like In-App Purchase) that can provide follow-on revenue for continued updates. I present them here just to make sure they are known in the community. If you decide you absolutely must do a paid upgrade you can use them to ease your customer’s frustration as much as possible.

David Smith