I can't tell what the status of FB7829889 is, but the two example threads are visible in 2022 in their entirety without being logged in. However, the issue persists to some degree. After posting 18 hours ago from a Monterey mac I notice: Replies posted to an existing thread are not immediately visible on my devices unless logged in. A new thread is immediately visible on my devices. Within minutes of posting from a Catalina mac, I noticed that the first draft of this reply was visible on my devices.

Update: Using a TestFlight app on a fresh install, I reproduced the crash twice on a specific iPad that runs 15.1: once 6 months ago, and once last week. The app was able to run normally on subsequent launches (after access permissions somehow got resolved).  In hindsight, I was unable to reproduce the crash in sequential tests that were under 15min apart, even with fresh app installs. It seemed like access permissions were being cached between app installs.

Update: Number of crashes relative to new installations: iOS 15.1: 64%. No crashes for iOS 15.0 and 14.x. This is a real problem. Most 15.1 users have deleted the app.

@Spads: At what point in the app’s lifecycle do you call authorizationStatus? Which devices are crashing?

@Gops90 : No, the IAP code has not been tested in the production environment.  The validation logic for each IAP receipt is as follows: if the cancellation date (1712) is newer than its purchase date (1704), then the content is blocked. For the purchase-refund-purchase scenario (in the Xcode test environment), there is no second IAP receipt. I would expect the original IAP receipt to be updated to something like: • 1703 (transaction ID): Shows the ID of the second purchase • 1704 (purchase date): Shows the date of the second purchase • 1712 (cancellation date field): Shows the refund date This may well be an Xcode test issue. I also found that Ask-to-Buy can trigger multiple IAP receipts - https://developer.apple.com/forums/thread/676580 (and customer charges?) for the same non-consumable.