Advice on merging two apps, Free and Paid?

I've got two apps, Upwords and UpwordsFree. I created them in a pre-InApp world. Upwords is paid up front and UpwordsFree is Ad supported. About a year ago I added an in-app option to remove ads in the free version.. essentally upgrading it to the full version. So I've got 2 sets of users and I'd love to migrate everyone over to just the Free version. I don't see a good mechanism to do this. I'd love to get the users who paid up front to move over to my Free version and grant them the In-App Ad Free option. Any advice on how to do this? Things I've thought about


-Present an alert message in the Full version alerting users to move over. Provide some sort of custom UUID token they can enter into the free version to remove ads.. sort of my own coupon code. This competley bypasses the store and things like restore purchases won't work for those users. I fear this will be a support nightmare trying to identify these paid users and waling them though removing ads if they re-install the app.. etc.


-Maybe there's a way to save a token in icloud? Both my apps share an icloud storage area.. but if you delete both apps I think that is wiped as well.


-Keychain token? my understanding is the keychain data remains even if you delete an app. Can I have a shared area where I can dump a token which the free version can read in the keychain? something that persists even when the apps are deleted.


Any other thoughts? Someone's got to have done this sucessfully. Would be great if apple could provide a way where in one of my apps I could query if a user had bought another one of my apps. Knowing that woudl solve the issue


Thanks


Daniel

Replies

The standard approach is to replace the paid version with a free version using a different 'build' number. Then inspect the receipt for the original_application_version which is the build number. If that indicates the user purchased the app before it was free then grant them the IAP. After this, add an alert to the old free version telling them to switch. ..,...You can also 'enable a URL scheme' (that does nothing) in the paid version and query canOpenURL from the free version to detect the presence of the paid version and upgrade itself.

Right I thought about the "canOpenURL" option which would work but I fear that in the distant future when they delete both apps for some reason and re-install they won't have a good way to re-instate the IAP (without re-downloading the orig paid version). If there's a way to offically grant an IAP for free to a user rather then just upgrade outside of apple store then a simple restore purchaces would work for them in the future. Does that make sense?

Yes, that is why the standard approach is to convert the paid app to a free app with an IAP upgrade and a check on originsl_application_version as stated above.

Ah, I didn't quite understand that. I got it, that's interesting and makes sense. Sadly it's a bit more complicated as I have users on the Free app who have paid to remove ads there (esentially making it a paid app equivalent). So I'd have my free users move to the new free app and then I'd have a similar issue tyring to figure out if they had paid before. I've painted myself in a corner it seems.

Did you end up merging the two apps into one freemium app?


Are you happy you did it?


Did you learn anything along the way?


Thanks for sharing!

I didn't. I put a few of the pieces in place but haven't made the transition. My app is a word game (Upwords) and my userbase trends to an older audiance. I find myself doing a lot of support for users who aren't computer savy. I'm concerned that I'll loose a large portion of my audiance if the upgrade/transition isn't that smooth.


What I have put in place is a shared keychain storage area between my two apps, paid and free. In there I have bools to indicate if a user has installed the paid version, if they bought any inapp purchaces etc. I do the same with the free app, just list all the features they've enabled etc. I added a new 'Free' in-app purchace item that upgrades the free version to the paid version.. this new in-app item only appears in the free app if I see the user has installed the paid version (by inspeciting the keychain).


My thought was I'd then direct my paid customers to the free version and they'd then "purchace" the free upgrade to honor their previous purchace. There are probably a bunch of cases where this would fail, or feel cumbersom, and I'd have to talk the users though the process. I want them to "buy" the free upgrade so I have a record down the line that they bought the app, long after my paid version has been depreciated.


I'm just not looking forward to the support nightmare this may spur.. so I've chickened out so far.


Daniel

Hello again. I never made this transition but I'm planning on trying it soon. Currently I offer a Facebook login and in ios13 I'll be required to support "Sign in with Apple".. I wonder if it will be able to handle the 2 apps with a consitent login credental. Just another thing tipping the scales to move in this direciton.


My current plan:

-My apps have a shared keychain storage.. I save a string for if the user has opened the full paid up front version as well as any in-app purchaces they've made.

-My free app can see these keychain strings. If it sees the paid up front has been opened it offers a FREE in-app purchace to remove ads.. otherwise it displays the normal paid in-app purchace for the same.

-I have similar Free in-app purchases for other features bought in the full version.

When a user opens my free app it displays a notification if it see's that user is also a paid up front app user and directs them to the store for the free in-app.


Before I orphan the full version I will add an alert that the app will be going away in favor of a newer app and provide a download link.


It's not great but I am tired of supporting to versions of my app.


I'll update if I hit any snags or observations that might help others.


Daniel

Can this be done from appStore side? I mean just make both the bundles into one unique bundle which can be an existing one or a new one.