Is subscription autoRenewStatus in StoreKit2 working correctly with Sandbox testing?

+1 on this issue and I'm also seeing very erratic behavior on these status changes.

Similarly, shouldn't a change in auto-renew status trigger a change via the subscription info's status updates stream? static var updates: Product.SubscriptionInfo.Status.Statuses { get } (https://developer.apple.com/documentation/storekit/product/subscriptioninfo/status/3851115-updates)

@eskimo wondered if you could weigh in on this status change for auto-renew? Thanks in advance.

I see exactly the same problem with "renewalInfo.willAutoRenew" in Sandbox, it doesn't update it's value to false when you cancel the subscription. Has anybody done a product release, does it work there (maybe only sandbox issue)?

try await AppStore.showManageSubscriptions(in: windowScene)
#if DEBUG
try await AppStore.sync()       // brute force fix (sync) to emulate behavior how it should be for debugging, don't do that in the release build
#endif
await storeKit2Service.updateSubscriptionStatus()

This state miss-match appears to be a result of StoreKit2 cacheing subscription info in a local database at: ../app_container/Library/Caches/StoreKit/receipts.db.

I was able to improve my flow by doing the following after displaying the manage subscriptions sheet.

1. Clear the caches directory
2. Fetch either the entitlement via Transaction.currentEntitlements or refresh a specific subscription group via Product.SubscriptionInfo.status(for:).

Example cache clear:

public func clearStoreKitReceiptsCache() throws {
    let fileManger = FileManager.default
    guard let cachesDir = fileManger.urls(for: .cachesDirectory, in: .userDomainMask).first else { return }
    guard let storeKitPath = try fileManger.contentsOfDirectory(
        at: cachesDir, 
        includingPropertiesForKeys: nil, 
        options: []).first(where: { $0.lastPathComponent == "StoreKit" }) else { return }
    try fileManger.removeItem(at: storeKitPath)
}

My experience with Sandbox testing is that subscription changes are sometimes significantly delayed. For example, sometimes if I cancel a subscription the cancellation doesn't take effect until much later than the subscription expiration time. If I just wait several minutes then the cancellation takes effect. I thought this might be due to Storekit caching so I've tried signing out and back in, removing the app, etc. but that doesn't seem to help.

So one suggestion: if the subscription status doesn't seem right, give it some more time and see if that fixes it.

Is there any news on this issue?

Any development in 2024? renewalInfo.willAutoRenew does not seem to get cleared (after 2-3 hours (with accelerated timing in sandbox) ; is that long enough?). I really hope to see expected values in sandbox before launch.

The only hint I could find so far is that the expirationDate in the latestTransaction for the product identified by renewalInfo.currentProductID is in the past (but renewal state remains .subscribed, willAutoRenew remains true, etc.).

If this issue cannot be fixed, is checking the latest transaction expiration date a valid approach? Should I look at this date check as a hack for sandbox, or is it necessary outside the sandbox too?

It looks like renewal state does change to .expired after some time; I'm not sure when or if it is load dependent (I checked one hour after expected expiration time (e.g., 3 * 3 * 12 = 108 minutes for a quarterly subscription on an accelerated time basis of 1 month = 3 minutes, and 12 renewals). Maybe this shows possible delays need to be handled.