Hacker News Reader

Comment by evgen | Hacker News Reader

Then charge for the upgrade by doing the standard major version bump (Foo2, just like Foo but now with more Bar!) and don't try to bullshit us. Companies don't need recurring revenue to survive, they need to sell product to survive. If their biz model consists of trying to bleed their current customer base one drop at a time I will look elsewhere.

-current 1password user and evangelist who will drop it in a heartbeat if forced into a subscription

View on HN

This is the correct answer. Every time I hear that a software vendor needs recurring revenue to survive, I think back to the entire history of the software industry where this was clearly not the case until every recently. Its gotten to the point now where anyone who makes some sort of software believes that are a service that must be paid for by subscription.

Don't be those guys, have a good long hard think about why you deserve that recurring revenue and if its not immediately obvious, chances are you are just chasing the dollar rather than trying to solve a problem.

You don't know much about the history of software sales. I've worked at software companies for 30 years and you are wrong. The first company i worked for folded down from 12 employees to 3 because revenues couldn't support us. We got our first upgrade out ($29 for existing customers on $99 retail) and it saved the company. Two years later we had 4 products and 30 employees.

If we had been forced to give the upgrade away for free to existing customers like iOS requires, we would have shut down.

iOS doesn't allow you to charge existing users for a version bump.

It is an entitrely new package that shares part of the name. I could provide numerous examples, but you already know about them. You keep minor version bumps for fixes and patches while major changes you plan to charge for are a part of the new package.

The whole point of paid upgrades is 1) that you charge existing users signicantly less than new users, and 2) that you get to contact existing users directly to tell them about it.

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.

Reply on news.ycombinator.com