Implement Free & Paid Apps with in-app purchases instead of as two apps
Sep 09, 2015
Offering paid upgrades to users of a free app can be implemented either as two separate apps (Free and Paid), or within a single app that is free to download with in-app upgrades for the premium features. I have found and heard from fellow developers that a single app with in-app purchases offers multiple advantages over the two-app approach, for both developers and users.
A seamless user experience when upgrading
When a user decides to buy your app, they can simply tap a button and be upgraded instantly. With two separate apps, they must uninstall the free one and then download the paid one. Whatever progress they may have made so far (saved data, trained models) will be lost.
Preferences are maintained even after upgrading
No additional work is necessary for a user’s preferences to be shared between the free app and the paid app, because it’s the same app.
With the two-app approach, users either have to start from scratch, losing all their settings, or you, the developer, have to take additional steps to ensure that preferences are correctly migrated. And even then, the experience is not seamless, since users now have to authenticate or perform import/export steps themselves.
With a single app, this is a non-issue, and offers the smoothest user experience. If you have a server-less app, this will save you the effort of having to stand up any kind of server-side support.
Launcher clutter & icon placement
Some apps require you to have both the free and the paid version installed on the device for the whole system to work correctly in paid mode. This means that both apps appear separately in the launcher, most likely next to each other. Tapping on the wrong one elicits a message to the tune of “hey, this is just the key; go open the other one instead.” This is not a good user experience.
A single app provides a single entry point, and eliminates any user confusion stemming from duplicate apps. During the upgrade, if users take the time to place your app’s icon on their home screen, they no longer have to remove and replace that icon with the paid app’s icon. Everything just works.
Maintaining two app variants is hard
Although you can configure Gradle to build multiple flavors of your app, you have to take extra engineering steps to ensure that both build and work correctly as expected. Testing efforts are duplicated (or at least 1.5x) with two separate APKs.
Bad for SEO (Search Engine Optimization) & ASO (App Store Optimization)
There are now two listings on the Play Store, splitting the SEO juice you’re getting. Reviews, reports, and inbound links to your app get divided between the two versions.
Easier to pirate a full-featured APK
If the paid version offers all the features unlocked, users may find it easier to pirate that APK elsewhere and offer it to others unlicensed. Since in-app purchases are activated within the app, and it’s possible to require license verification with your own server, those are harder to pirate than full-featured APKs.
Also, IAPs cannot be refunded on Google Play (unlike purchased apps, which can be refunded within a 15-minute window for full price). This can cut down on piracy from users who would otherwise download the paid APK (after paying for it), then copy the APK off the device, refund it, and then reinstall from the copied APK.
Multiple price points possible with IAPs
Any more than two separate apps and the multiple-app model fails to scale well. But with a single-app-with-IAPs, it’s easy to set up per-feature prices in addition to a strict dichotomy between Free and Paid. Some features might be worth a lot more, such that even most Paid users would not care about them. It’s possible to charge only those users who are likely to need that feature, while keeping the rest of the app free/cheaper for everyone else.
Offer value, not annoyance removal
Don’t charge your users simply to remove an annoyance (such as ads). Charge them to use a feature they would love using (and love to pay for using). Offer a time-limited trial of the paid version so they’ll know what to expect. The code is in there already (since it’s a single app!), so just unlock it for the first 24 or 48 or 72 hours, and let them get a taste of what the full-featured version looks like. Keep them aware that this is a time-limited trial, and offer them incentives to upgrade even before the trial period is over. And then, if the user chooses not to purchase, just lock the feature up beyond the trial period.
What’s your experience so far?
If you’ve experimented with these issues, I’d love to hear what your experience has been! What do your users say about your app? What hypotheses have your analytics confirmed / failed to confirm?
