“restore purchases”

Thank @richThe major problem is that after restore purchased transactions, the receipt in the macOS app bundle will not be updated (checked manually and using code).The code works well on the iOS device (the receipt will be updated correctly)For the macOS app, I have to write code to save the transaction date (monitor by transactionObserver) in safe area, and write code to validate if the purchase expired. This problem was reported at beginging of this year at https://forums.developer.apple.com/message/290288#290288 and a year ago at https://forums.developer.apple.com/message/258440#258440 by other users. I thought I may made a mistake, it's hard to believe it's a bug as it's so important and so basic for the local verification of auto-renewal subscriptions. Thanks,

This is what the documentation says about Transaction.all: This sequence returns the user’s transaction history current to the moment you access the sequence. The sequence emits a finite number of transactions. If the App Store processes new transactions for the user while you’re accessing this sequence, the new transactions appear in the transaction listener, updates. The transaction history doesn’t include finished consumable products or finished non-renewing subscriptions, repurchased non-consumable products or subscriptions, or restored purchases. Even after reading this, I'm not 100% sure if paid apps transactions should show up in the transaction history or not.

I have faced the same issue and I haven't found solution so far. The steps I follow in order to reproduce: I buy a non-consumable. I check my local transactions by navigating to Debug - StoreKit - Manage Transactions. The transaction is there. I remove the application. I do install the application again, I click into my button for restoring purchases - this button triggers restoreCompletedTransactions() from the StoreKit framework - but I receive zero transactions. If I navigate again to Debug - StoreKit - Manage Transactions, I can see there are no transactions. Apparently those transactions are linked to a specific build so as soon as you remove the application the transactions will be gone. It would be great to get any feedback from Apple. Thank you in advance.

It is essential because there are a massive amount of users out there trying to purchase IAPs with invalid receipts. So this is not a theoretical issue, it is a real problem. For example **** broken devices are often already modified to automatically send a, let's call it a recycled iTunes receipt. In practice, many users of **** broken devices are not even aware that their devices are doing this by default. So even when they try to restore IAPs that they really bought before, their device would often use a bogus receipt instead by default.Also this is not solely about piracy, you are talking about subscriptions. And when you decode a receipt it also contains the information for which time frame the user purchased the subscription, and also whether the subscription has already been terminated by the user via Apple's iTunes support (think about restoring purchases for instance).And no, these issues are not soley limited to **** broken devices. There are also tools out there

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