Detect previous paid version of app

Scenario: A commercial app becomes free. The new free version would like to know if the user had purchased the previous commercial version (eg. to unlock things from the get-go). This should work even if the user had uninstalled the previous version (and is now installing the new version.)


Is this possible in any way? In other words, is it possible to find out, for example by quering the App Store, if the user had already purchased the commercial version of the app previously? (The new version can't rely on any data from the old version existing on the device, because it could have been uninstalled. This also wouldn't be the safest way.)

Post not yet marked as solved Up vote post of WarpRulez Down vote post of WarpRulez
6.0k views

Replies

You have to inspect the application receipt. That contains the original purchased version number. If that number is before the switch to freemium, then you unlock the desired features. Refreshing the app receipt can generate an authentication prompt to the user, I think, so you should use it judiciously. I recommend doing a search for "freemium" on the old (archived) dev forums - there was quite a bit of discussion there. There are also some WWDC videos on the topic. I think maybe the StoreKit videos from 2013. Sorry I can't remember exactly which but I do know converting to freemium was a hot topic a while back. (Personally I think paid is the way to go, but that's based on my personal experience so YMMV of course.)

The specific WWDC Session on this topic is WWDC 2013

<https://developer.apple.com/videos/wwdc/2013/>

session 308 "Using Receipts to Protoect Your Digital Sales"


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI

This thread talks about the exact same question:


https://forums.developer.apple.com/thread/5638


However, I do not understand the "correct" answer: "The technique is pretty simple. All you do is check the 'original_application_version' of the receipt when the user first runs the updated app."


There's text on how to check a receipt locally here: https://developer.apple.com/library/ios/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateLocally.html


However, it's quite complex, and it doesn't clarify where exactly that "original_application_version" is found, or how to check it. (Incidentally, there is no such text anywhere in that page...)

decoding it in the app is fairly complex - I haven/t figured it out yet. But it is fairly easy to send the receipt to the Apple servers and get back a decoded version. Try that.

I was able to decode the receipt data using a third-party library.


There is one very big question, though: How would I test that my code works correctly?


This project is intended to replace an existing (paid) app. I do not have access to said old project itself. I'm not 100% certain of what the bundle version of the old app is.


Also, when I tested the receipt data by running this project on an iPad, I got an "original version" of "1.0", even though the bundle version of this project is "3.0". Thus this makes be wary of whether the correct bundle version will be in the receipt data for someone who gets this version of the app as the first version they ever "purchase".


So how could I test this? How can I make sure that someone who has purchased the old app, when they run this new version, the "original version" in the receipt data is indeed correct? How can I make sure that if someone has not purchased the old app, and is getting this new version for the first time, that the "original version" in the receipt data is "3.0" and not something else? (As said, this project is currently returning "1.0" as the "original version", when I run it on an iPad from Xcode.)

In the sandbox the original version will always be 1.0. In production the original version will be correct. Your new version will be, let us say, 3.1. The logic is then....if original version is "less than 3.1" give the IAP to the user. You can test this in the sandbox because all original versions will be less than 3.1. You can test to be sure you are not giving it to people who don't deserve it by changing "less than 3.1" to "less than 1.0" and verifying that the iap is not granted - then change it back to "less than 3.1"

Could TestFlight be used to test the functionality in practice?


In other words, if someone who has bought the existing version of the game would receive a new beta version of the game through TestFlight, would the receipt data work properly (or would it also show just a version of "1.0" regardless of whether he has bought the old version or not)?

I just came across this thread as I am trying to convert a paid app to the freemium model.


I would like to know the definitive answer to WarpRules question as my tests tell me that that using TestFlight does NOT correctly test this functionality. (i.e., I am always seeing a receipt of 1.0 whether the user has purchased the original version or not).


But perhaps there is something wrong with my receipt-checking logic so don't want to release the app without knowing the real answer.

To my knowledge, TestFlight operates in the sandbox environment where there is no previous knowledge as to existing production versions of the application.As such, the original_application_version field will always be 1.0. I suggest that everyon reading this submit an enhancement request using the Apple Developer Bug Report web page - http://bugreport.apple.com to suggest that iTunesConnect provide a means that the original_application_version field can be set per test user account so as to realistically test this process. In the bug report please make sure to include the following statement


"please assign this bug report to component "iTunes Production Support", version "P3 Issue"


The above description will help the bug report triage engineer assign the bug report to the group that can support such functionality.


rich kubota - rkubota@apple.com

developer technical support CoreOS/Hardware/MFI