Expose original_purchase_date

[fotiDim]

For many apps using the originalApplicationVersion is no good since it returns the build number instead of the version number. The scope of this PR is to:

• Clearly indicate that originalApplicationVersion is the build number
• Expose originalPurchaseDate to be used as an alternative for migrating paid apps to freemium

Edit: Added tests
Edit 2: Fixed the naming mixup in the PR description

[aboedo]

Hi! 👋 Thanks for posting the PR. I'm a bit confused about it, though:

For many apps using the originalPurchaseDate is no good since it returns the build number instead of the version number. The scope of this PR is to:

Clearly indicate that originalPurchaseDate is the build number

Did you mean originalApplicationVersion instead of originalPurchaseDate?
The originalApplicationVersion value comes from the receipt's original_application_version.

See Original Application Version in https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html.

It's supposed to correspond to CFBundleVersion (iOS) or CFBundleShortVersionString (MacOS), and 1.0 in Sandbox.
Have you not found this to be the case for you?

[fotiDim]

Hi @aboedo ,
my bad, I did mix up the names in the description. I fixed it now.

Yes, CFBundleVersion is exactly the problem. For all of my builds I use "1" as a value and increment that only if necessary. So my releases look like:

• 1.0 (1)
• 1.1 (1)
• 1.2 (1)
• 2.0 (1)
  and so on...

The right thing to be exposed (from Apple) would be CFBundleShortVersionString but since this is not exposed, for my case (and I guess also for others) I have to resort to originalPurchaseDate.

[aboedo]

Ohh, I see, thanks for clarifying. Yeah, this will be a problem for developers who don't have distinct build numbers for all releases.
exposing the originalPurchaseDate in that case makes sense.

[aboedo]

This might be confusing for some developers, since it will be the marketing version number on Mac, and the build version number on iOS.
from the docs:
This corresponds to the value of CFBundleVersion (in iOS) or CFBundleShortVersionString (in macOS) in the Info.plist file when the purchase was originally made.

See "Original Application Version" in (https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html)

maybe we could replace this line with:

Returns the value of CFBundleVersion (in iOS) or CFBundleShortVersionString (in macOS) 
in the Info.plist file when the purchase was originally made.
See "Original Application Version" in 
https://developer.apple.com/library/archive/releasenotes/General/ValidateAppStoreReceipt/Chapters/ReceiptFields.html 
for more details.

[fotiDim]

@aboedo I updated it keeping the old pattern (before my PR) and using the human friendly and widely known names for those properties in the first row of the description. CFBundleVersion while being the right technical term, it can easily be mistaken for the app version and create confusion.

The new description is:

Returns the build number (in iOS) or the marketing version (in macOS) for the version of the application when the user bought the app.
This corresponds to the value of CFBundleVersion (in iOS) or CFBundleShortVersionString (in macOS) in the Info.plist file when the purchase was originally made.
Use this for grandfathering users when migrating to subscriptions.

[aboedo]

changes look good! thanks again for opening the PR! Hopefully it'll help other devs who run into the same issue

[om-ha]

Please port this to Flutter when you get to 🙏🏻😻

[aboedo]

will do!