13

I'm trying a new market strategy so I'm gonna put my 0,79€ App now for free, with an in-App purchase that unlock ALL the contents. I also do not want to betray the users which already has bought it, so I thought to implement a check where who already have bought the App, don't need to purchase the in-App payment to unlock all.

My problem is... can I check when the App has been purchased? Or maybe there is a simple way?

tc.
  • 32,896
  • 5
  • 73
  • 95
Alberto Schiariti
  • 1,407
  • 2
  • 14
  • 28
  • Thanks for answers, but I need something that won't mess up after that the user delete the App. I need something like make the in-App purchase "free" for who already have the App, so that I can restore it if the App is being deleted. – Alberto Schiariti Jun 11 '12 at 15:33
  • It *ought* to be possible (and not a privacy violation) to be able to access the previously purchased app versions/purchase prices, but the App Store is sorely lacking in this regard (it doesn't even support paid upgrades, though the original "You've already bought a previous version of this app" message suggested the possibility of reduced-price upgrades). The best advice I have is to [file an enhancement request](https://bugreport.apple.com/). – tc. Jun 11 '12 at 15:39

5 Answers5

7

just to update this, it IS possible. Take a look at the answer to this question -- one of the fields in the receipt is "original purchase date"

A complete solution to LOCALLY validate an in-app receipts and bundle receipts on iOS 7

Community
  • 1
  • 1
software evolved
  • 4,144
  • 32
  • 45
  • 3
    Original purchase date is only a field for IAP entries, it doesn't exist for the app itself. The app purchase date is also in the receipt of an app but it isn't documented. – Mecki Jun 03 '15 at 17:45
  • Ooops! I think I was confusing "Original Application Version" (which is at the app level) with "Original Purchase Date" which (as you pointed out) is inside the IAP data – software evolved Jun 03 '15 at 17:56
  • @Mecki what about "Receipt Creation Date"? One can use it as date when app was purchased – derpoliuk Apr 08 '16 at 11:18
5

You can't do this with any certainty, since there is no way to check if the user bought the app because there is no way to ask the OS about the install/purchase date.

As suggested, you could save it in the NSUserDefaults, but if the user deletes the app, this information is lost.

One could save it in the keychain, which is not cleared if you delete the app, but the problem is still there, because if the iOS device gets restored, these settings could be lost.

ja'
  • 438
  • 6
  • 14
rckoenes
  • 68,081
  • 8
  • 130
  • 162
  • 1
    At least with iOS 7 this is no longer correct. See [below](http://stackoverflow.com/a/23119397/1534401) for the correct answer. – Frederik Oct 14 '14 at 11:10
  • @Frederik That is true, but when this answer was written it was correct. – rckoenes Oct 14 '14 at 11:34
  • 1
    @rckoenes It still is correct, since officially the purchase date only exists for in-app purchases, not for the app itself. – Mecki Jun 03 '15 at 17:46
  • @Mecki Not true. A receipt is generated for both the original app purchase and IAPs. – dwlz Aug 18 '17 at 15:23
  • @DanLoewenherz First of all, there is not a recipe for ... and a recipe for ..., an app has exactly one recipe and this recipe contains all the purchases you've ever made (a recipe is the book that contains the bookkeeping of your purchase history). And 2nd you need to pay attention to the word "officially". As I wrote in another comment: **Original purchase date is only a field for IAP entries, it doesn't exist for the app itself. The app purchase date is also in the receipt of an app but it isn't documented.** Parsing undocumented data is the best way to make a non-future-proof app. – Mecki Aug 18 '17 at 19:08
  • @Mecki Not sure what documentation you're seeing, but it is documented and officially supported. Perhaps this was changed since you made your original comment. Link: https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html#//apple_ref/doc/uid/TP40010573-CH106-SW2 – dwlz Aug 18 '17 at 20:13
  • @mecki "The receipt for *an application* or in-app purchase is a record of *the sale of the application* and of any in-app purchases made from within the application." Source: https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Introduction.html#//apple_ref/doc/uid/TP40010573-CH105-SW1 – dwlz Aug 18 '17 at 20:14
  • 1
    @DanLoewenherz Yes, I know that page. And here is the documentation of the fields: https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html#//apple_ref/doc/uid/TP40010573-CH106-SW1 And as you can see, there is no purchase date for apps according to this documentation. Where under **App Receipt Fields** do you see a purchase date? `Receipt Creation Date` is no purchase date! And the field `Purchase Date` only exists for **In-App Purchase Receipt Fields**. – Mecki Aug 22 '17 at 12:06
  • @Mecki Yes, I did read the docs. I quoted from them directly. First line stated unequivocally that the receipt is a record of the "sale of the application". So the `Receipt Creation Date` should refer to the purchase date. Is there a link from Apple's documentation that states that is not so? – dwlz Aug 22 '17 at 14:22
  • @DanLoewenherz Yes, there is a link, it's the link from my comment: `Receipt Creation Date: The date when the app receipt was created.` If that is the app purchase date, why is it different when I delete the app and then re-install the app? Just try it out yourself. When you originally purchase an app for the very first time, this date is the purchase date but every time you re-install an app to the same or a different device, a new receipt is created and the current date will be there (the date the recipe was created) and this is not the purchase date of the app. – Mecki Aug 22 '17 at 15:19
1

rckoenes explanation is correct. I've been through such scenario lately and I've considered the options mentioned in the answers here. The option I end up with is to release another extension of app (like 'pro' or 'lite' etc.) instead of a version of existing app. That would cut off all the hassles of handling the purchase status of your app. Then you'd have a full paid version of app with all premium content and one free version with In-App purchases to unlock the content. Hope that'll help.

Ahmed
  • 772
  • 1
  • 9
  • 26
  • I already tried the 2 App way, but the App got rejected because "you can't do anymore that way but you have to implement the in-App purchase". And by the way I don't like a lot having 2 Apps that needs both the same updates... – Alberto Schiariti Jun 11 '12 at 15:43
  • There might be something left out. There should be difference in the name. 2 App model is just a matter of choice, I guess. If you browse the store around a bit you get to know that almost all popular games/apps use the same model. and for the updates you can handle it by developing the app as single, not two, project and implement your logic on the basis of some sorta define-directives. Anyways, that's the way I'd handled things, would be keen to know how would you do it eventually. – Ahmed Jun 11 '12 at 15:50
  • Yeah... I'm thinking of an easy and more friendly way. Thanks anyway for the tip :-) – Alberto Schiariti Jun 11 '12 at 15:52
0

Assuming your current version of the application saves state, on the first launch of the next version of the application, you can check for any saved state (e.g. a key in NSUserDefaults, a file in the documents directory, etc.)

You should only do this once though, so you need to have another flag somewhere else to tell you that the check has been performed.

Richard J. Ross III
  • 53,315
  • 24
  • 127
  • 192
-1

This should be pretty straightforward. If you know when your new app comes online, you just check for the installation date/time (store the date/time in the keychain upon first run). Users that installed the app before the date/time your free app came online can access content. If you are worried about new users messing with the date/time, use an online time service to get the actual time.

Joris Weimar
  • 3,966
  • 3
  • 29
  • 48