MacOS App Receipt Validate a non-in-app purchase?

Every thing I'm reading about receipt validation is only for in-app purchases, but how does the Apple Store then prevent someone from putting the app on a torrent network?

If you search "receipt" in WWDC2020 here:
https://developer.apple.com/videos/wwdc2020
it's all "in-app" receipt validation.

SwiftyStoreKit docs says this:

When an app is first installed, the app receipt is missing.
As soon as a user completes a purchase or restores purchases, StoreKit creates and stores the receipt locally as a file, located by Bundle.main.appStoreReceiptURL.

https://github.com/bizz84/SwiftyStoreKit#receipt-verification


Which makes it sound like the MacOS app can't actually be receipt validated when it's freshly installed from the Apple Store...  🤷🏻‍♂️

So then back to the top, how's it protected from the ".app" file becoming torrented?


Accepted Reply

The SwiftyStoreKit documentation is only correct with regards to any macOS (as well as iOS) application installed to a device or macOS system in the sandbox. For a macOS system, the recommendation is that the app check for the presence of the appStoreReceiptURL and if it is nil, then call

exit (173)

An example of this is in the StoreKit sample code available at <https://developer.apple.com/documentation/storekit/in-app_purchase/offering_completing_and_restoring_in-app_purchases?language=objc>

Again, this is only an issue in the sandbox environment. For ALL production apps installed from the App Store and Mac App Store, there is always a appStoreReceipt included. For non-StoreKit apps or those where the user has never made a successful transaction, the in_app array of the receipt is empty.

The question then becomes - whether to implement local receipt validation or work with the verifyReceipt endpoint available at the App Store Server. Today's documentation covers the use of the verifyReceipt endpoint as there is additional support provided for StoreKit apps which offer auto-renewing subscriptions.

There is mention of local validation for both iOS and macOS apps - which applies to all apps such as yours where you want to protect the app distribution process. For macOS, our older documentation has been removed. However, if you submit for a DTS incident <https://developer.apple.com/support/technical/>, I'll provide what I have of the previous documentation. I can't promise - but I'll try to have the incident re-credited.

rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI

Replies

The SwiftyStoreKit documentation is only correct with regards to any macOS (as well as iOS) application installed to a device or macOS system in the sandbox. For a macOS system, the recommendation is that the app check for the presence of the appStoreReceiptURL and if it is nil, then call

exit (173)

An example of this is in the StoreKit sample code available at <https://developer.apple.com/documentation/storekit/in-app_purchase/offering_completing_and_restoring_in-app_purchases?language=objc>

Again, this is only an issue in the sandbox environment. For ALL production apps installed from the App Store and Mac App Store, there is always a appStoreReceipt included. For non-StoreKit apps or those where the user has never made a successful transaction, the in_app array of the receipt is empty.

The question then becomes - whether to implement local receipt validation or work with the verifyReceipt endpoint available at the App Store Server. Today's documentation covers the use of the verifyReceipt endpoint as there is additional support provided for StoreKit apps which offer auto-renewing subscriptions.

There is mention of local validation for both iOS and macOS apps - which applies to all apps such as yours where you want to protect the app distribution process. For macOS, our older documentation has been removed. However, if you submit for a DTS incident <https://developer.apple.com/support/technical/>, I'll provide what I have of the previous documentation. I can't promise - but I'll try to have the incident re-credited.

rich kubota - rkubota@apple.com
developer technical support CoreOS/Hardware/MFI
Thank you for the explanation Rich. I understand now and can track it down but I also went ahead and submitted a ticket in the Apple Dev Support form.