My problem with the 1Password subscription model

First, remember that the Apple App Store doesn't give you any way to directly notify existing customers. See my other post, it's a great deal of work to induce customers to give you email addresses/etc.

But lets say you have emails for most of your users, or that you autoupdate your app to notify them that the new version is out and for a limited time available for a cheap price. Most of your users are going to miss this email, or forget about the discount, or not use the app during the discount period and never see the notice.

Those who miss the discount window are going to be pissed. That's going to be a lot of 1 star reviews. Some are going to be pissed they, as long standing users, didn't get a "real discount" since you gave it to anyone who bought it at the same time. That's more 1 star reviews.

But the worst problem is you are discounting the value of your product to new users. Your retail price should be set where it maximizes long term revenues (if you thought you would make more money by discounting you'd already be doing that).

For existing users who have already paid you for much of the value, you want to set your upgrade price at a reasonable value for the additional features of the new version. That price normally should be lots lower than retail, essentially 20-30% in any mature product.

By giving the new users a price that is the 20-30% of what they would normally pay, you are leaving a ton of money on the table. Worse, you are front-loading sales. Anyone who planned to pay full retail in the future will rush to take advantage of the discount. How do you think sales for the rest of the year will look?

Imagine you expected to sell 36,000 copies to new users this year at $10 each, or a net of $252,000 this year after Apple's 30% fee.

You announce the new version is only $3 on the store for a month, but only tell the 50,000 existing users that you have email addresses for. You get a great response from them, and sell 20,000 units to existing customers the first month, netting $40k.

But instead of selling your typical 3,000 units to new users the month, you instead sell 12,000 units to new users. What happened? Well, anyone who was likely to purchase this year and found out about the huge temporary discount, bought now. And lots found out, either by checking the store, or hearing from existing users (50k people have lots of friends), or from bloggers, or one of the hundreds of discount alert services, etc, etc.

And by front loading their purchases, your sales will be lower over the remainder of the year, by the 9,000 extra new users who took advantage of the discount. So instead of netting $292k this year, you are going to net less. How much less? Your 36k in new users now net you only $168k, for a total of $208k, costing you $84k or 25% of revenues.

The problem with discounting for everyone is that the shorter the discount period, the angrier your existing users will be. And the longer the discount period the more money it will cost you. It's a no win approach. You absolutely need a way to qualify existing users to provide the upgrade price, or it can't work. You'd be better off never discounting and forcing existing users to pay full price to re-buy a slightly better version of the app they already own.

Creating an entirely new "package" on iOS is an entirely new app. Which means unless you use App Groups, that your users will lose all the data they've created in your app, which for some categories of apps is a terrible user experience. And implementing App Groups to transfer old data is a bunch of extra work that you should have gotten for free by using Coredata.

Worse, your existing users won't be told about it by the App Store. The App Store won't provide email or physical addresses to let you inform them about it. So to reach them, you have to do something like

1) Update existing app with a notice and a link to the new app on the store for the user to buy it. This doesn't work for apps that users typically don't use often, for example my most successful app is a "fire and forget" type app the once a user sets up, they rarely ever need to open it again.

2) Get existing users to give you email addresses. Forcing them to do so is against App Store rules, so you need a strategy to induce a high percentage to do so during install/signup, that's hard. It also requires prescience. If you don't start this in an early release of your app you'll miss out on most of your installed base.

3) Use push notifications. That's hard too. You have to convince users to authorize your app to allow push notifications. Again have to do this from early versions, or again lose most of your installed base. Many users won't authorize notifications for your app.

That's just the problem of being able to reach your installed base. Actually giving them a discounted price is another hurdle that's difficult. There is no App Store option to have two different purchase prices for different user groups for a new app. So you have to do it by hand

1) Generate a custom code in the existing app, and link to the new app and tell your existing user to use the code when they launch the app to purchase it at the upgrade price instead of the retail price. This means your new app can't be a paid app! It can only be free with in-app purchase, so an in-app purchase business model has to work for your app. And it's extra work, you need reasonably secure code generation, and good UI so users understand it, or to use App Groups to automate it.

Also, you probably need to determine whether a user of the existing app qualifies for a discounted upgrade price. For example, let's say your old app is $10, the new app is $20, and you want to offer existing users a $5 upgrade price as a thank you. You need to make sure new users don't just download the old app and upgrade instead of buying the new app directly. Or you keep the price at $10, but make the old version free as a trial product for people to use before upgrading. You want existing users to pay $5 to upgrade, and new users to pay $10. So how do you tell new from old?

If they never deleted the app since install, you can use installation date. But if they deleted the app, then read about the 2.0 release and it's new features and re-installed, their install date is now post 2.0 release. Unless your app has email registration and the deleted/reinstalled user actually used it, there is no way to determine if they are existing users or not. Apple doesn't allow developers to fingerprint devices (the last loophole was Keychain, which they recently closed).

2) One way to do via your existing app is to make new features an in-app purchase. That means you don't lose existing data, and you can reach all existing users. But it also makes the purchase process for new users shitty. They buy the app on the store, then they realize it doesn't have the shiny new 2.0 features, it's really the old 1.0 features and they have to pay again to get the latest, best features. That's hard to explain in the limited space the App Store gives you, and is just a fantastic inducement to get a ton of terrible 1 star reviews.

You can make the 2.0 version free on the store with the 1.0 features already activated for free, and the 2.0 features an in-app purchase, this is straightforward for new users. Again in this case you need to automatically determine if the user purchased before 2.0 was released or after, and charge different prices based on that, and you'll have a ton of edge cases where existing users look like new users because of install dates. You'll get a ton of 1 star reviews from that. And it's not even a reasonable path if your 1.0 features still have too much value to give away for free.

So creating a paid upgrade path is difficult on iOS, it's hard to reach existing users to market your upgrade, and all of the ways to emulate paid upgrades have significant shortcomings. I don't know of any examples that work well, if you do, please share them. I'll thank you, and admit that I'm wrong.