The problem is getting customers of version 1 onto version 2. There is no way to do this with MAS. I have a mechanism built into Shave so I can push "news", but it's annoying and bad user experience.
Why not a "fat" app? Always include two major versions in one binary, instead of putting the new features behind a paywall. Have an IAP purchase that just configures the app to run "Side B" from then on.
I think the following set-up avoids that problem: app is always the same price to download and has a few basic features unlocked. App has an upgrade view or screen where users can unlock additional features via in-app-purchase.
It works like this: developer releases the app for, say, $10. People buy it and use the basic features for a while. So far there's no upgrades available. Developer codes up a premium feature and updates the app in the store. Existing users can use the app as-is with the basic features that came with the $10 price tag. Existing users can also make an in-app-purchase for, say, $5 that unlocks the premium feature. When new users download the app for $10 they just get the basic features. Since another "version" of the app is available the new users can just buy the premium features if they so choose.
Fast forward to version 5 of the app. Now there's 4 upgrades available via in-app-purchase. However users are only prompted to purchase the next version based on their in-app-purchase history.
I don't think there's a problem for new users who purchase the updated app.
This does away with everyone-is-on-newest-version paradigm of automatic updates that makes support easy - in fact, it makes it much worse. Instead of five old versions of the app, you might have 1 base + 12 permutations = 13 different combinations of functionality to support.
Good point. This approach probably wouldn't work for some apps. However if the app lent itself to a very modular design it could work. Certainly would take some creativity on the developer's part. For example premium features that are troublesome if only some people have them could be included in a free bug-fix update to make things easier.
I suspect it would be much nicer for both the dev and the users if there was just a single "Upgrade to the latest version for $5" option. Don't try to splinter the upgrade path into features or sub-steps. So, as a consumer story: you buy v3 for $10. Over the next year, v4,5,6 come out and you pass on them. V7 finally convinces you to upgrade and you shell out $5 to go from 3->7 with a single click. Meanwhile, if you were a power-user, you might have been impatient and shelled out $5 each for v4,5,6 along the way. But, I think that's a pretty reasonable way do perform price discrimination.
If a developer is going to offer a version upgrade, it's the fact of a previous version purchase that signifies eligibility. The app store clearly has this purchase information. So why not give the developer the option to set previous versions to act as "coupons" reducing the price of the new version by a developer specified amount? When version 5 is released at $20, let old versions be set so they can no longer be purchased anew. Let the developer set owners of version 4 as seeing the price of version 5 as $10. If you own version 3, then perhaps 5 is $15. Let previous versions themselves be upgrade coupons.
In-app purchases are left as orthogonal to these upgrades. The developer could perhaps be allowed to continue to push out bug fixes for older versions, or even old version DLC.
How would this work? I mean, even assuming Apple let you get away with it:
If you store the version on the device, the user would simply have to delete the app (which wipes all data the app has stored on the device) and re-download from the app store (which is free) to get the latest version. It's not going to take long for users to notice that and then you'll never sell an upgrade again.
So you'd need to move away from a straight app and also create a server component. But to store it on the server, you need something that uniquely identifies the user.
You can't get access to the UDID any more (and besides, people would catch on when upgrading their phone got them new version of everything for free).
You can't generate some kind of GUID, because that has the same problem as just tracking it on the device. Upgrades are just a reinstall away.
And you can't force them to sign up for your site on first launch: App Store reviewers won't approve apps that make users register solely to store information about them. So you'd need to push content through the site, at which point you've moved well beyond the purview of most apps, and you ought to just give up the game and sell access to the content itself.
Anyone who has purchased any IAP content at all has an IAP receipt that you have access to even across installs.
This leaves the problem that v>1 first time buyers will have to IAP something immediately after buying the app, kind of pushes you to have a free trial mode.
Hopefully apple will eventually introduce time-limited free trials and upgrade options. If their history with iOS and Mac versioning is any hint, the current simple system is not a religious thing for them and they will listen if they see enough negative feedback. Which we should provide.
Is that necessary? For some reason I can't think of any problems with the freemium-like approach. Basic app has a fixed price and basic features. It's what everyone gets initially. "Versions" are really just premium features available via in-app-purchase. Bug-fix updates just affect the basic version of the app. And they're available for free to anyone who has the app just like the iOS store.
