Converting a paid app to in app purchase

Question

SierraLima OP

Created Feb ’20

Replies 5

Boosts 1

Views 4.1k

Participants 5

Hey guys,

So I've had an iOS game out for years as a side hustle. I initially released it before in app purchase existed. The monetization model was a full paid app and a seperate free version of the app with only the first few levels which links you to the app store page of the full version once you complete all levels. I finally have time to switch it over to the more modern free app with an premium in app purchase model where you make a one time non consumable purchase to unlock the advanced levels and features.

Does anybody know if it's possible to seamlessly switch the app with a new release to this monetization model? Ideally I'd like to unpublish the existing free version, update the paid version to now be free and add a new in app purchase non consumable product that all existing customers get for free. If I simply add a new non consumable in app purchase product, my existing customers will be ticked off that they paid for the app when they purchased it a while back and the premium features no longer work after the update. On the flip side, if I have to create a brand new app because this is not possible it wipes out my app's ratings, comments and app store "momentum".

Thoughts?
Thanks,
Omri

Boost

Answer 1

PBK OP

Feb ’20

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

1

Answer 2

SierraLima OP

Feb ’20

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

0

Answer 3

joeallenpro OP

Feb ’20

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.

0

Answer 4

lumpazy OP

Dec ’20

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.

0

Answer 5

insats OP

Apr ’23

@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.

0