Converting a paid app to in app purchase

There are two approaches.

1) just convert the free app to a freemium - it remains free and you add an IAP to upgrade it to the full app.

2) eliminate the free version - or perhaps upgrade it to say - 'buy the freemium version'. Then convert the paid app to a freemium version - free with limited levels and an IAP to upgrade. BUT - use the 'original_application_version' field in the receipt to see if the user has purchased the app or gotten it for free. This field will be "1.0" in the sandbox and in production it will be, for an iOS app, the Build* value of the version of the app that the user downloaded.

* yes - the CFBundleVersion number not the CFBundleShortVersionString - go figure. Hopefully there are a limited number of them for your app. Or, just give the new app a wierd Build number like "7.3" and check for not that

Hi PBK,

Thanks!!!! Option 1 seems very reasonable. The bundle ID and SKU will stay stuck with the word "lite" in them but I supposed that doesn't matter because it's not user visible. It looks like I can change the app title to remove the word "lite" from it from one version to the next so everything that will be user visible will change over nicely.
Thanks again,

Omri

You can check the App Store receipt to see which version the user originally purchased, this is a robust way to unlock the full app for customers who paid for it when it was a paid app. This will elimitate any customers needing to pay again.

joeallenpro  's answer would be so great.
unfortunately you cannot just 'check the app receipt' as simple as it is made out to be here.
The receipt is base64 encoded and on the docs it says : DO NOT try to validate anywhere but on a secure server.
see here :
https://developer.apple.com/documentation/storekit/in-app_purchase/validating_receipts_with_the_app_store

So. Does anyone else have any other 'robust' and secure way to do this.
Otherwise it basically looks for me like i have to go with PBK's option nr one. That's quite a shame though.

@lumpazy the only reason why you should validate receipts on a secure server is because it's the only way to prevent users from tricking the system and faking a receipt - but that's not likely to happen. In the end, it depends on cost of setting up the server solution vs cost of having a very small number of users attempting to circumvent the required IAP.