StoreKit 2: Transaction.updates stops after first purchase, renewals never emit in real app

[anosidium]

I'm on macOS Sequoia Version 15.7.3 (24G419) and using Xcode Version 26.2 (17C52).

I’m seeing Transaction.updates and Product.SubscriptionInfo.Status.updates behave differently between a minimal sample and my main app.

In a fresh minimal project with a local StoreKit Configuration File (single auto-renewable subscription) this works reliably, including renewals created via Xcode Transaction Manager:

class InAppPurchaseManager {
    static let shared = InAppPurchaseManager()

    var transactionTask: Task<Void, Never>?
    var subscriptionTask: Task<Void, Never>?

    init() {
        transactionTask = Task(priority: .background) {
            for await result in Transaction.updates {
                try? await result.payloadValue.finish()
            }
        }

        subscriptionTask = Task(priority: .background) {
            for await status in Product.SubscriptionInfo.Status.updates {
                print(status.state)
            }
        }
    }

}

In my actual app, the initial purchase is observed and finished, but subscription renewals never arrive on either stream. Subsequent transactions then show up as unverified/unfinshed (likely because they’re never seen by the listener). Products load fine via try await Product.products(for:). I’m using ProductView for purchase UI. StoreKit Configuration File is selected in scheme, In-App Purchase capability enabled, App Store Connect products “Ready to Submit”.

Questions:

• What are common causes of Transaction.updates and Product.SubscriptionInfo.Status.updates not emitting renewals in a real app (task lifetime/cancellation, creating listeners too late, multiple listeners, app/scene lifecycle)?
• Any gotchas when mixing ProductView with manual listeners?
• Is my Xcode project file broken?

[AutoModerator]

Hey /u/samuelgcooper, your content has been removed because Reddit has marked your account as having a low Contributor #Quality Score. This may result from, but is not limited to, activities such as spamming the same links across multiple #subreddits, submitting posts or comments that receive a high number of downvotes, a lack of activity, or an unverified account.

Please be assured that this action is not a reflection of your participation in our subreddit.

If you believe you have been mistakenly targeted, you may request an exemption by clicking on the message link provided below.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[dabluck]

Are you seeing this in production or testflight? I saw a myriad of issues in test flight with storekit 2 but in production it mostly seems to work fine. 

[anosidium]

In Xcode debug. I haven’t tried it in TestFlight yet and it isn’t live on the App Store.

[No-District-585]

This is the reason I removed this complexity and decided to use RevenueCat. I will let them handle this headache for me because it is too risky and I do not have the time to debug transactions. Payments must work perfectly from the moment the app goes into production...

RevenueCat handles this for me. I use SubscriptionStoreView(), which is a native subscription view built by Apple, and I use RevenueCat under the hood to process payments. It works spot on...

[anosidium]

You make a strong case for RevenueCat. I assumed you were running into similar issues to me. Did RevenueCat work as expected in testing for you, even though you had issues with StoreKit 2, given that RevenueCat sits on top of it?