In response to your questions -
Q1. If iOS app is free and user has purchase nothing, can I fetch receipt data in production app?
Response - A production app will be installed from the App Store - in which case there will always be an appStoreReceipt to check. In the pre-order case, you can validate the appStoreReceipt with the production verifyReceipt endpoint and there should be the preorder_date field for the preordered app.
There is presently no support for checking for a pre-ordered app in the sandbox. There is never an appStoreReceipt present for any iOS application installed via Xcode, TestFlight, nor in App Review.
I'd verify this functionality once the iOS application is released on the App Store.
Rich Kubota -
Developer Technical Support
Post not yet marked as solved
In the documentation which you refer to, there is
Important
An applicationUsername property that isn’t a UUID isn’t guaranteed to persist between the time when you add the payment transaction to the queue and when the queue updates the transaction.
This also applies to the renewal notification when the transactionObserver is called later on. The discussion also states
Consider assigning a UUID to the applicationUsername property. When this value is a UUID, the App Store server stores it as an appAccountToken. In this scenario, the following happens:
In the App Store Server API, the JWSTransactionDecodedPayload object returns the applicationUsername value in the appAccountToken field.
In App Store Server Notifications, the JWSTransactionDecodedPayload object returns the applicationUsername value in the appAccountToken field.
When you call the verifyReceipt endpoint to verify an App Store receipt, the App Store server returns the applicationUsername value in the app_account_token field of the responseBody.Latest_receipt_info.
If you set the applicationUsername field with a valid UUID string, then call addPayment, the App Store Server saves that UUID with the auto-renewing subscription information and will return that value as a field "in the app_account_token field of the responseBody.Latest_receipt_info." This means that when the renewal occurs, send the appStoreReceipt to the verifyReceipt endpoint with the shared-secret, then review the contents of responseBody.Latest_receipt_info to find the appropriate auto-renewing subscription record with the app_account_token.
As I understand, this works now. If it doesn't this would be a bug report issue.
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
Per App Store Connect Help, there is the following
Q. What is the difference between introductory offer limits and customer eligibility limits?
A. App Store Connect allows you to set an introductory offer for each subscription product in App Store Connect. You can have multiple offers in each subscription group. New and returning customers are only eligible to use one introductory offer per subscription group. For example, if a customer uses a free trial and then upgrades to a subscription product in the same group that also has a free trial, they are not eligible for the second offer.
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
What information are you looking to obtain from app store connect. I support the StoreKit API's and there is the "App Store Server API". It would help to have an example of the information you are looking for.
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
it occurs to me that the solution is - test the current version of macOS. If 11 or greater, then implement DCAppAttestService. Let's move forward with the times.
rich kubota
Post not yet marked as solved
the document on local receipt validation is still valid. There is an important distinction with the issue here and what the document states. - note the overview -
When users install apps from the App Store, the app contains a cryptographically signed receipt created by Apple that’s stored inside the application bundle, which you can then validate. This statement is 100% correct. There is always an appStoreReceipt present when the app is installed from the App Store. This is not the case when the app is installed via Xcode, TestFlight or other sandbox mechanism. The use of exit (173) has been documented to trigger a "temporary" appStoreReceipt to be written to the app
when none is present. If there is a bug report issue, it's with this call. As macOS has evolved, the exit (173) mechanism has demonstrated it's fragility.
I understand that the obstacle which this issue creates - that of getting the app through App Review. I wish there was a simple solution.
rich kubota
Post not yet marked as solved
When I responded, I was thinking only of StoreKit 1 API's. Actually, one can implement a StoreKit2 app which makes use of the beginRefundRequest(in:) call. In the sandbox, this will trigger a REFUND notification.
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
I'd submit a bug report and provide a base64 encoded appStoreReceipt with shared-secret along with the iTunes user account of the user. This issue can then be investigated by the App Store Server team.
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
inTrialPeriod set to true indicates that the user has purchased a subscription item where a trial purchase is offered to new users. The account is currently in the trial period. When the trial period is over, and the user has not cancelled the auto-renewing subscription - the App Store will attempt to bill the user's credit card to renew the standard subscription associated with the free trial. If there is a billing issue preventing the charge, the transaction goes into billing retry. For more information I refer you to the Apple Developer article "Reducing Involuntary Subscriber Churn"
rich kubota
developer technical support CoreOS/Hardware/MFI
see my response to this same question in the post "In-app purchase fail to get receipts and macos says application damaged"
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
The Finder is presenting this message after a macOS StoreKit app calls exit (173) a second time. The macOS StoreKit app is being run in the sandbox. The app on launch detects that the appStoreReceiptURL is nil and calls exit (173). The Finder detects this exit result and issue a request to the App Store to write a receipt to the app. This causes the app to present an authentication dialog in which you enter the test user account and password. Normally, the appStoreReceipt is refreshed in the app, but not in this failure case - such that the Finder presents the alert to the effect that "the app is damaged".
For the longest time it was recommended that on launch, the macOS StoreKit app check for the presence of the appStoreReceipt. If not present the app calls exist (173). This is no longer recommended as it rises the Authentication dialog which can be confusing to a user. Instead the advise now is to have the app continue along with the assumption that the user has no access to first time in-app purchase support, or to support for restoring previous purchases.
The fact that the appStoreReceiptURL is a sandbox issue only. In the production environment, when the app is installed from the App Store, there is always an appStoreReceipt. Once a test user makes an in-app purchase the sandbox App Store will write an appStoreReceipt to the app for the app to validate and verify the transaction.
If the goal is to restore purchases on a new launch of the app, and there is no appStoreReceipt, just move along and have the user press a "Restore" button which makes the restoreCompletedTransactions call. On a successful restore of a previous purchase, the appStoreReceipt is also updated.
The StoreKit team asks that macOS StoreKit apps no longer rely on the use of exit(173).
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
The recommended means to obtain the most current record for an auto-renewing subscription is to validate the appStoreReceipt and include the "exclude-old-transactions":true key in the outbound JSON request - along with the base64 encoded appStoreReceipt and the shared-secret. If the response status is 0, then access the items in the "latest_receipt_info" section of the receipt. Only the most recent auto-renewing subscription item will be returned (or most current items is the user is subscribed to multiple subscription group items).
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
It turns out that if the mac StoreKit app detects that the appStoreReceipt is missing, don't call exit (173) just keep on going. This is a sandbox only issue. When a successful in-app purchase is made, the App Store always updates the appStoreReceipt which the app process can use to validate the purchase.
I can think of a couple of reasons for wanting the appStoreReceipt to be present:
to determine if the user is eligible for promotional or first time purchase access. In this case, assume that the user has no free trial access and move on.
to determine if the user purchased an earlier version of the app - so as to implement paid-to-freemium support - if the receipt is missing assume this is a new user that must pay to access premium content. If you need to check the app logic to check the value of original_application_version, do so after making a successful in-app purchase, when there will be an appStoreReceipt to validate.
as a convenience method to update (restore) services to a user. In the production case this will work without issue. In the sandbox environment, rely instead on the user pressing a "Restore" button which triggers the app to make the restoreCompletedTransactions call.
there are those apps which use the presence and validation of the appStoreReceipt to verify that the app was installed from the App Store. For this use case, the App Attest service is recommended.
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
In reviewing the second and third screenshot, the second alerts asking the user to sign in typically occurs when a macOS StoreKit app calls exit(173). This step normally occurs when the app checks for the presence of the appStoreReceiptURL and finds that it's nil. In the past, the recommendation has been for a macOS app to call exit (173). The third alert typically occurs after authenticating the user password request, then the StoreKit process is unable to find a matching record for the applications bundle identifier in the AppStoreConnect records. Normally if a matching app bundle identifier is found, the App Store Server generates an appStoreReceipt and installs it to the app. The app is relaunched, and this time the app detects the presence of the receipt. In case that there was no AppStoreConnect app match was found, the appStoreReceiptURL remains nil, the app again makes the exit (173) call. But this time the Finder detects the second attempt by the app and raises the alert.
You indicate that there is no need for an appStoreReceipt on startup - "I would like for the distributed app to be runnable by customers without requiring an App Store receipt." as such, if there is no appStoreReceipt, then don't make the exit (173) call.
If the app needs to validate the appStoreReceipt following a successful transaction, it can do so when the .purchased transactionState is returned to the updatedTransactions delegate. If the desire is to use receipt validation as a means to validate the app, the App Attest mechanism is the preferred means to do so.
rich kubota
developer technical support CoreOS/Hardware/MFI
Post not yet marked as solved
Can you narrow down what StoreKit function is not working. Is your app using StoreKit 1 API's or StoreKit 2 API's? Please provide more details as to the problem.
rich kubota
developer technical support CoreOS/Hardware/MFI
