Converting a paid app into free-with-unlock

Hi,

I am considering moving my app from a "paid up-front" model to a "free-with-unlock" model, and had a couple of concerns about this:


- for exising paid app customers, I plan to put a flag in their CloudKit account saying that they are paying customers. When they download the free version, I can check the flag in their account and just unlock the full functionality for them, without even going through StoreKit. I can also put a Restore button which just checks for this flag. Would that work? Are there any use-cases that I might be missing (other than people without an iCloud account)?


- for future customers, I am thinking of letting them have unlimited entries for a week. After that, they have to purchcase a one-time nonconsumale IAP to continue. They can maybe browse their existing entries, but they cannot add new data. Is that an acceptable way to do a free-with-unlock implementation? I haven't seen anything against it in guidelines but I thought I would check.


Would love any feedback.

Regards.

Replies

I think “customers without iCloud” might be a show stopper. The “standard” way to handle such a conversion is to inspect the app receipt and look at the original purchased version. If it’s earlier than the version in which you changed to freemium, then unlock everything. Otherwise enable your IAP stuff for new customers. That way you don’t need any server side flags. I think there are cases where the receipt may not be present, so you’ll still need a Restore button somewhere to refresh the receipt.


That method of offeringing a free trial seems ok at first glance, though I don’t have any personal experience doing it that way.

Thanks for the comment! One more issue about this is that there is also a different SKU for the iPad version, which is also a paid verison that I would like to also combine with the (now universal) iPhone version that's free-to-unlock. In that case, relying on app receipts isn't going to work, since the iPad app has a separate receipt that won't be accessile to the iPhone version. In that case, I could either go through the "iCloud-required" route and unlock if the user has the same icloud account as on the iPad version, through CloudKit. OR I could create a free iAP that is only shown if you have the legacy iPad version installed on the same device, and in that case, users can get the unlock experience, as well as have it saved in their app receipt for future restoration.


Not sure which option is more resilient to odd edge-cases. Any idea?

So you want to go from a paid app 1 and a paid app 2 to a freemium app2 - correct?


The difficult edge case is the app 1 owner.

You can:

1) inspect the receipt in the new App 2 to verify that the owner purchased an earlier version (it's actually the build number - so be careful)

If you don't inspect the receipt then you can never handle the user who deletes the paid app 2 and doesn't ever reload a revised paid app 2 before finally loading the freemium app 2. If you could rely on the user downloading a revised App 2 then you could have that revised App 2 write to the keychain (or iCloud) something that the freemium App 2 could then read.

2) inspect a file that a revised app 1 and the new app 2 can both access - apps can share:

file space on the device, including the keychain, when properly constructed for sharing

NSUserDefaults, specially constructed for sharing

the iCloud key-value file - specially constructed for sharing

a simple canOpenURL in the new App 2 that can access any URLschema that was added to the revised App 1

and App 2 can detect that the revised app 1 was run either on the device (or using the same iCloud Apple ID - if you use the iCloud file). You can tell the user of the freemium app 2 to download the revised app 1 to prove they bought it.

Thanks for the comments.


"So you want to go from a paid app 1 and a paid app 2 to a freemium app2 - correct?"


- yes, the 2 paid apps will be combined into one, with probably the app1 converting to 'free-with-unlock'. So app2 owners will need to be unlocked for the premium feature when they download it. I plan to inspect the receipt in app1 for sure. For app2, I can definitely use shared keychain to unlock app1 premium feature as well (and then possibly require them to purchase a free IAP so that the record is always available in the app1 receipt, should the user delete app2).


A couple of questions remain:

- I also plan to remove app2 from sale, after doing the update to notify existing users and helping them transition by writing to the shared keychain. Once I remove it from sale, does the update stop showing up in the "Updates" tab? I believe users can still go to the App Stores's purchase history and download the app, but would they also see it in the "Updates" section (if they're on an older version)?

- can I still remove the app from sale *before* the update, and when the update becomes available, will they users see it as a normal update through the App Store updates page?


This should help clarify my execution plan for the transition.

Thanks!

Since the questions seem to be directed at me I will answer......my answer is - "I don't know."