3 ms·
As annoying as this is - and I agree that they should provide an option to charge for upgrades - the problem can be alleviated to a large extent by in-app purch
by peterkelly 13y ago
As annoying as this is - and I agree that they should provide an option to charge for upgrades - the problem can be alleviated to a large extent by in-app purchases.
Suppose for example you have FooApp 1.x, and you later want to release a major update, FooApp 2. You release FooApp 2 as a separate app for new customers, and provide an update to FooApp 1.x which lets existing customers update.
This is admittedly awkward, and can only really work for upgrades where the main new things in the new version are additional features. For apps which have major architectural changes it would be problematic. To the best of my knowledge though this is the best we can do in the context of the current policies.
- adjwilli 13y agoAgreed, and the subscription model provides incentives for developers to update apps too.
- rbritton 13y agoI have not personally tried this out, so I can't verify if the necessary info is accessible or not. Could you extract the purchase date from the receipt and use that as a basis to determine which features to enable, providing IAPs to unlock the rest? At a certain level it may be too cumbersome under the hood, especially when compared to the traditional update method of providing an entirely separate binary, but it could work by also providing a means for bug fixes on "older" versions without additional labor.
- hrabago 13y agoThis doesn't scale though. By the time you have FooApp 5 then you have 5 binaries you have to maintain.