3 ms·

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 scr

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.

jarek 14y ago
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.
- spaghetti 14y ago
  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.
  - corysama 14y ago
    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.
    - redler 14y ago
      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.

jarek 14y ago

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.

spaghetti 14y ago
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.
- corysama 14y ago
  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.
  - redler 14y ago
    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.