Subscription State Persistence with new StoreKit SwiftUI API

App Purchase Validation and In-App Purchase Persistence with the older StoreKit APIs is complicated. I’m curious to learn whether the new StoreKit SwiftUI views and .subscriptionStatusTask modifier simplify the process — or ideally eliminates the need to implement complex Validation and persistence logic using AppStorage, Keychain or App Receipts. Any thoughts on this?

Answered by Skylark in 787290022

In my experience, they don't simplify anything because they don't reliably work.

You end up with a combination of the SwiftUI modifiers and imperative StoreKit API code.

A mess.

Accepted Answer

In my experience, they don't simplify anything because they don't reliably work.

You end up with a combination of the SwiftUI modifiers and imperative StoreKit API code.

A mess.

@Skylark this seems to be the case. I’ve spent almost a week trying dozens of variations to detect subscription cancel from AppStore or other device in order to manage subscription state persistence — without success.

The challenge is due to the fact that StoreKit does not send a separate transaction when a subscription is cancelled but instead updates the subscription transaction record to expired.

From my reading you are supposed to be able to detect this through the absence of a particular product in CurrentEntitlements, but I cannot figure out how to do this. This is such a common use case that I believe I might be over complicating something that is already handled by the StoreKit API.

Any thoughts on how others are handling subscription cancels is appreciated.

Subscription State Persistence with new StoreKit SwiftUI API
 
 
Q