Thanks @DTS Engineer ! That's the first workable solution I've seen. moc.object(with:) shouldn't cause a fetch unless I read properties (as opposed to writing them, as above) right?

Aha I was confused because the renewal info distinguishes between productId ("The product identifier of the In-App Purchase.") and autoRenewProductId ("The identifier of the product that renews at the next billing period."); from that I assumed offerType ("The type of subscription offer.") was the current offer and that a similar autoRenewOfferType property was missing. Thank you very much for your help!

Aha, that's great. I'll check the isUpgraded field then. The trick with status for us is that our backend wants to know details like next subscription expiration/renewal date so that it can hand our shorter or longer credentials for downloaded content. So we can't just rely on status. E.g. a person with a 1 week free trial might be able to download content for offline use up to 7 days & a person with an annual subscription might be able to download content for offline use up to 365 days.

Thank you! Does that mean that (at a minimum) SUBSCRIBED, DID_RENEW, and OFFER_REDEEMED notifications always contain the latest transaction for the subscription identified by originalTransactionId? Or must I always call "Get All Subscription Statuses" when receiving a notification?

Ah OK thanks!

Just to clarify, when you say this: Your app sets the data protection level to .complete... that would be us manually setting the data protection level on the .shm file? That's almost definitely not it. Your app is launched into the background ... This doesn't seem like an impossible situation since we do use BGProcessingTaskRequest in some places. Thanks @DTS Engineer ! I'll look into these avenues.

Thanks!

You should be able to look up the item in question in the "Keychain Access" app on your mac. If you double click the item & click on "Access Control" it should list your full bundle ID (with team ID prefix).

I found no solution. But we've seen no one else reproduce it. I do think that your issue might be a different thing, as our error has a different status code than yours. Also our code as posted above does work for everyone but this one user. You may wish to check that (1) the item in question is actually in the keychain; and that (2) the item in question was inserted by your app.

Yep, looking back we received from June 7 to June 10 as well. It would be very helpful if Apple's services kept a public log of incidents/temporary bugs like this so that we could determine definitively that we correctly understand the expected behavior. I guess it must have been unintentional. So I've closed our internal issue about it.