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.
I 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.
One issue: how to move data from old app to new - and separate - app? On a Mac it's easy, because everything has access to the full file system. On iOS, apps are blocked from anything outside their "sandbox". I gave up on one desirable iOS app because I'd entered a pile of data in the free version, and couldn't move any of it to the new/paid version.
With iCloud this is super easy (or the new dropbox apis), but if the developer has set it up properly, there are a few ways to migrate data. It can be encoded and opened up as a url is the easiest way that I can think of.
Btw, I've now dropped over $1,700+tax on Logic. From my original purchase of 4.0 from EMagic that I ran on Windows, Logic 6 post Apple acquisition, Logic Studio 9, and now Logic Pro X.
I am totally fine with the $200 pricing which is less than the cost of the previous upgrades. Everyone seems to be forgetting that there was a point when Logic cost $999.
Yes, this is a head-scratcher for those that complain there is no 'upgrade' pricing when the cost of the full app is what the upgrade price /used/ to be.
Same could be said for FCP X: Used to sell for $1600 and new price is $300, and then complaining that there's no upgrade price.
Used for example only, I realize that it wasn't so much an upgrade as a step backwards for functionality.
I’d say that this is the best indication of Apple’s intentions and expectations for the App Stores going forward.
a lot of assumptions made for this one niche product, only on the mac app store, for a product that is receiving an update 4 years after the last version was released.
maybe, it's just the fair market value price for a new version of an application?
Another possible factor is that Apple is made up of lots of different teams. It's possible that the Logic Pro X team wanted to provide upgrade pricing, but the app store team (or higher-ups) did not want to permit this.
Without any further information (which we're almost certainly not going to get) it's difficult to tell if this is the case.
We did the same a few months ago with one of our products. No one complained yet so I guess people seem to accept it.
Though we left the old version in the app store (with a warning in the description for new would-be customers) so people can re-download their old version.
I think it would be better to move your older version to free or very discounted, and put up some alerts when they start the app (and before they purchase) telling them about the new version. Tell them how to migrate their data, if they have any. And be on your way.
You can do this, but I'd advise against it. I did this with one of my apps and have received quite a few complaints from people who can no longer find it by searching.
It seems to me that quite a few people don't know about the the Purchased list.
Upgrades are confusing for novice users. Version numbers aren't. While upgrade pricing has been nice in the past, I fully understand wanting to get more revenue from existing users, it just means that the price per version should drop. If customers are truly "loyal" they should have no problems paying full price for an app.
Being loyal is a two way street to me. If you are going to support a product over an extended period of time then I believe there should be some sort of incentive to continue buying the new version - especially when the new version only has X new features added to it. Those new features are really the only thing existing users are paying for, while new users are paying for every feature.
It doesn't have to be approached in the typical upgrade fashion either, the companies can treat the program as a completely new one but I would like to see some form of promo codes that only existing users can take advantage of in order to show appreciation for their support of your product.
In this new model of app upgrades, where they offer new versions of the app as a separate download, you pretty much have to buy all of the features again. This is not unlike buying hardware -- and I think this new model is bringing software more in line with hardware.
Suppose I bought a lawnmower from Honda in 2000. After 13 years, I move to a home with a bigger yard, and I decide that I'd like a bigger mower. Should I reasonably expect to get a discount from Honda on my next mower just because I bought one of their products before?
Wait. So if I'm reading this correctly, Apple's answer is being silent? There are much better alternatives here
1. Point the old app to the new app, so people know there is an upgrade. Also address the concern of moving data to the newer upgraded app.
2. Provide an subscription model
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.