StoreKit2 Repro Notes: the latest renewal appears in Transaction.unfinished after restore (2026-04-05) 1. Issue Summary In the current project, during a normal cold launch: Transaction.latest(for:) returns a value for the weekly subscription Transaction.all returns the full subscription history chain Transaction.unfinished is empty However, after tapping Restore Purchases and calling AppStore.sync(), one "latest renewal" transaction appears in Transaction.unfinished. This behavior looks more like a system-side replay triggered by AppStore.sync() than a consistently unfinished transaction during a normal launch. 2. Affected Product Product: do.i.iapc.vip.week Transaction chain characteristics: All transactions belong to the same auto-renewable subscription chain originalTransactionID = 2000001143446796 The transaction that appears in unfinished is usually the latest or last renewal in the chain 3. Current Code Path During app startup: loadProducts() Debug snapshot for Transaction.latest(for:) Debug snapshot for Transaction.all Scan Transaction.unfinished refreshEntitlements() During restore purchases: Call AppStore.sync() Scan Transaction.unfinished refreshEntitlements() 4. Preconditions A Sandbox test account is used The weekly subscription do.i.iapc.vip.week already has multiple historical renewal transactions The subscription is already expired, so entitlements = 0 during a normal launch The issue is easier to reproduce on an iOS 26.4 device The issue was not consistently reproduced on another iOS 18.2 device 5. Reproduction Steps Path A: Normal cold launch Launch the app Observe the logs: LatestTransaction snapshot AllTransaction snapshot summary unfinished processing result Observed result: latest has a value all contains the full history chain unfinishedHandledCount = 0 Path B: Tap Restore Purchases Launch the app Tap Restore Purchases Trigger AppStore.sync() Observe the logs: restore started unfinished processing started unfinished transaction received Observed result: After restore, one "latest renewal" transaction appears in unfinished That same transaction does not necessarily appear during a normal cold launch 6. Expected Result If a transaction has already been successfully finished in the past, it should not appear again as unfinished after Restore Purchases. A stricter expectation is: During a normal cold launch, unfinished = 0 After tapping Restore Purchases, unfinished should still remain 0 7. Actual Result Actual behavior: Normal cold launch: unfinished = 0 After Restore Purchases: one "latest renewal" transaction appears again in unfinished This suggests that AppStore.sync() may replay the most recent historical subscription transaction. 8. Current Assessment Based on the current logs, the issue is more likely to be: Related to AppStore.sync() / StoreKit / Sandbox replay behavior on the system side Easier to reproduce on iOS 26.4 Less likely to be caused by a persistent app-side bug where finish() is missed during a normal startup flow Reasons: During a normal launch, unfinished = 0 The behavior is inconsistent across devices and OS versions, even with the same Sandbox account latest, all, and unfinished can be clearly separated during a normal cold launch 9. Suggested Engineering Position Suggested wording for internal or external communication: In the iOS 26.4 + Sandbox environment, calling AppStore.sync() may cause StoreKit to replay the latest historical subscription transaction into Transaction.unfinished. Since the same transaction does not necessarily appear during a normal cold launch, the issue currently looks more like a system/environment-specific behavior difference than an app-side bug where finish() is consistently missed during the regular startup path. 10. Additional Evidence That Can Be Collected If this needs to be escalated to the team or to Apple, the following would strengthen the report: Full log comparison before and after tapping Restore Purchases The same transactionId compared between normal launch and post-restore behavior Cross-device comparison on different iOS versions A minimal reproducible sample project and Sandbox test record

Body: I'm experiencing a persistent issue that has affected multiple apps I've developed, and I'm hoping to get some guidance from the community or Apple engineers. The Problem: When testing In-App Purchases, my app never enters the sandbox environment. The payment prompt does NOT show the "[Environment: Sandbox]" indicator, and I always receive error code -100 (Invalid Product Identifier). This issue has occurred across multiple apps I've built, including a previous app that I ultimately had to release as a paid download (rather than freemium with IAP) because I couldn't resolve this same problem. Now I'm facing the identical issue with my new app, "AI Job Assistant". What I've Checked (all correct): ✅ Paid App Agreement status is "Active" in App Store Connect ✅ Bundle ID matches exactly between Xcode/HBuilderX and App Store Connect ✅ Product IDs in code match those created in App Store Connect (case-sensitive, no spaces) ✅ All IAP products have complete metadata (name, description, pricing, 640x920 screenshot) ✅ Product status is "Ready to Submit" (not "Waiting for Review") ✅ I have both iOS Development certificate and iOS Distribution certificate — I am using the Development certificate for testing ✅ My provisioning profile is explicitly for Development (named "aijobDevprofile", shows "iOS Development" type) ✅ The Development profile contains my test device UDID ✅ I have fully signed out of my real Apple ID in Settings → Media & Purchases ✅ I only log into my Sandbox Tester account through the purchase prompt (not in Settings) ✅ I test on a real device (not simulator) ✅ I have tried creating multiple new Sandbox Tester accounts ✅ I have tried toggling "Cleared for Sale" off and on for all products ✅ I have waited over 24 hours after making configuration changes What I See: When I initiate a purchase, the payment prompt comes up but there is NO "[Environment: Sandbox]" text anywhere After entering my Sandbox Tester credentials, the request fails with error code -100 (Invalid Product Identifier) My Setup: Development framework: uni-app / HBuilderX (custom debug base with Development certificate and Development provisioning profile) Backend: Cloudflare Workers (handles receipt verification) Testing device: iPhone (latest iOS version) The same issue occurred with my previous app, which I never resolved and eventually gave up on IAP entirely Question: Why does my app never enter the sandbox environment despite using the correct Development certificate and Development provisioning profile? Is it possible there is an issue at the Apple developer account level that is preventing sandbox environment activation? How can I force my debug builds to connect to sandbox instead of production? I am willing to provide any additional logs or information needed. Please help. Thank you.

Hi, I'm using AppTransaction.originalAppVersion to detect whether a user originally purchased the app under the old paid model, so I can automatically unlock the app for them as a courtesy when migrating to freemium. Background On iOS, originalAppVersion returns CFBundleVersion (the build number). When I transitioned the app from paid (v1.x) to freemium (v2.0), I defined a numeric threshold for CFBundleVersion to distinguish legacy purchasers from new users: Build number below the threshold → v1.x purchase → auto-unlock Build number at or above the threshold → v2.0+ install → requires IAP In Production, originalAppVersion correctly returns the actual build number, and the comparison works as intended. Detection logic (simplified) // Determine environment via receipt URL func detectStoreEnvironment() -> String { if let url = Bundle.main.appStoreReceiptURL, url.lastPathComponent == "sandboxReceipt" { return "Sandbox" } return "Production" } // Legacy check using numeric comparison static func isLegacyPaidUser(version: String, threshold: String) -> Bool { guard !version.isEmpty else { return false } return version.compare(threshold, options: .numeric) == .orderedAscending } // In checkLegacyPurchase(): let version = appTransaction.originalAppVersion let isLegacy = isLegacyPaidUser(version: version, threshold: legacyBuildNumberThreshold) let env = detectStoreEnvironment() let shouldAutoUnlock = isLegacy && env != "Sandbox" The problem I know that in the Sandbox environment, originalAppVersion always returns "1.0" — this is mentioned in the AppTransaction documentation. My code already suppresses the auto-unlock for Sandbox (env != "Sandbox"). However, it appears that the App Review environment also returns "1.0" for originalAppVersion. Because the receipt URL path component is "receipt" (not "sandboxReceipt"), my environment detection classifies it as "Production" — so the Sandbox suppression doesn't apply. The reviewer is incorrectly identified as a legacy paid user and the app is unlocked without a purchase. This caused our v2.0 submission to be rejected under Guideline 2.1a. Questions Is it documented that the App Review environment returns "1.0" for AppTransaction.originalAppVersion, similar to Sandbox? Is there a reliable way to detect the App Review environment specifically — separate from both Sandbox and Production? For example, does the receipt URL differ, or is there another API? Is using originalAppVersion for legacy paid-user detection a supported pattern? If so, what is the recommended approach to handle the App Review case? Any guidance would be greatly appreciated. Thank you.

Hey my app subscriptions are currently in review whilst my app has been approved 2 times, i need this to be approved to start marketing it.

I submitted my last macOS application with IAP on Oct. 23rd, 2025. I was able to test-purchase a non-consumable product with the StoreKit configuration file at that time. These days, every time I test a new macOS application with the configuration file, a purchase process fails. The thing is they all now fail if I test the store with existing applications that were once working. Xcode shows the following debugging error. Purchase failed with error: systemError(Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service created from an endpoint was invalidated from this process." UserInfo={AMSDescription=An unknown error occurred. Please try again., AMSURL=http://localhost:53272/WebObjects/MZBuy.woa/wa/inAppBuy, NSDebugDescription=The connection to service created from an endpoint was invalidated from this process., AMSStatusCode=200, AMSServerPayload={ All my iOS apps don't exhibit the same problem. This StoreKit fiasco only happens for macOS applications. And I'm thinking that it all started to occur after I began using Xcode 26. Not a single line of code has changed. But the applications that were once able to process IAP all now fail. And I'm suspecting that it's Xcode 26 that is responsible for this failure. My Xcode version is 26.2, by the way. Any macOS application developer experiencing the same problem?

Hi, I’m having an issue where my auto-renewable subscriptions keep detaching from my app version after I submit the build in App Store Connect. Details: App ID: com.growthsync.app Platform: iOS (Capacitor build) Using auto-renewable subscriptions What’s happening: I attach all subscriptions to the app version under “In-App Purchases” Everything looks correct before submission After submitting, the subscriptions become detached or require localisation to be re-entered again This happens every time I resubmit Additional issue: Subscriptions are not working in TestFlight either It feels like they are not properly linked to the binary What I’ve already checked: Product IDs match exactly in code and App Store Connect Subscriptions are in the correct group All localisation fields are filled within character limits Products show as “Ready to Submit” before attaching I reattach them before every submission Questions: Why would subscriptions repeatedly detach after submission? Is this a known App Store Connect issue? Is there a specific order required when creating, localising, and attaching subscriptions? Could this be related to the binary not recognising the products? This is currently blocking release so any help would be appreciated. Thanks.

Hey We have noticed a change in the retry behavior of Apple Server Notifications webhooks V2 starting around March 12–13, 2026. Previously, when our webhook endpoint returned an HTTP 400 response, Apple would retry the notification delivery multiple times according to the documented retry policy. However, beginning around March 12–13, it appears that Apple no longer retries the webhook when a 400 response is returned. The notification is sent only once and no further retry attempts are made. From our understanding of the documentation, retries should occur when delivery fails, and historically we observed retries even for some 4xx responses. We would like to confirm: Has Apple recently changed the retry behavior for Server Notifications? Are HTTP 4xx responses (specifically 400) now considered terminal failures that will not trigger retries? Is this change intentional or related to a rollout in the webhook delivery system? We have called the "Notification History" endpoint for some users who purchased a sub and we are only getting one attempt with the following data in it: { attemptDate: 1773469202552, (2026-03-14T06:20:02.552Z) sendAttemptResult: 'UNSUCCESSFUL_HTTP_RESPONSE_CODE', } This was 2 days ago, based on the docs, the user should have a few attempts at least. This behavior change affects systems that rely on retries to handle temporary validation issues or transient failures. Thanks!

I try to call Get Transaction Info from App Store Server API, and the transactionId is for a Non-consumable type product, but it is odd that there are so many different transactionId and they have a same originalTransactionId { "bundleId": "${bundleId}", "environment": "Production", "inAppOwnershipType": "PURCHASED", "originalPurchaseDate": 1691220528000, "originalTransactionId": "${originalTransactionId}", "productId": "${productId}", "purchaseDate": 1691220528000, "quantity": 1, "signedDate": 1692590989925, "storefront": "USA", "storefrontId": "143441", "transactionId": "${originalTransactionId}", "transactionReason": "PURCHASE", "type": "Non-Consumable" } the defination of Non-Consumable is can only purchase once for same apple account. But why there would have originalTransactionId?

Hello! I am attempting to add Subscriptions to an App that Is already published on the App Store. I cannot get Xcode to actually sync what is in my App Store Connect. When adding the Storekit configuration file, I go through the automatic linking process and select the proper bundleID. The configuration file says 'Synced @ [CurrentTime]' however there are no subscriptions listed in there. I have attempted deleting the file several times, creating a new subscription group. With no success. Do I need to publish the subscriptions without the features first? Upon attempting to write the supporting code that will enable these features within the app, I cannot get Xcode to identify that I have these subscriptions. I have also tried pushing these to TestFlight, still with no success. Thank you.

I added my first subscription to my app using StoreKit's SubscriptionStoreView. Everything worked as expected in the debug environment and also in TestFlight. So I submitted my app and subscriptions to App Store Connect, got everything Approved and released. After updating my app through App Store and checking the Subscription View, it just says "Subscription Unavailable. The subscription is unavailable in the current storefront." I waited around 3 days and still getting the same message. Now the very strange behavior starts. I went to App Store Connect, I made and edit to the subscription description, saved, removed the edit, saved, and submitted to review. 15 minutes later the subscriptions appear in my app and everything works as expected. After getting the edit approved, the Subscription View in my app again only showed the message "Subscription Unavailable. The subscription is unavailable in the current storefront." No user is able to see the subscriptions anymore, even though it worked as expected before the edit was approved. So I did the same as before. Again, make an edit to the subscription description, save, remove the edit, save, submit to review. 15 minutes later the subscriptions are again available in my app and it works as expected. This is definitely not the expected behavior and submitting the subscription edits every day is wasting the App Review Team's time as well as mine. I contacted Apple Developer Support but I didn't get any reply back (at least yet). I am not the only one experiencing this. I found a friend online who has the exact same issue, and is able to temporarily solve it by making an edit to the subscription description as well. So far it has been a huge headache, and we are losing customers this way. Please if anyone has experience with this problem, or has any suggestions, they will be greatly appreciated. Thank you so much, Tomas

On an app that was using the old API for In-App Purchases (StoreKit 1). The app is already published on the App Store. The purchase is non-consumable. While trying to migrate to StoreKit 2, I'm unable to restore purchases. Specifically displaying and purchasing products works as expected, but when deleting and reinstalling the app, and then trying to restore purchases I can't do it. I'm trying to restore them using the new APIs but it doesn't seem to be working. What I have tried so far: I'm listening for transaction updates during the whole lifetime of the app, with: Task.detached { for await result in Transaction.updates { if case let .verified(safe) = result { } } } I have a button that calls this method, but other than prompting to log in again with the Apple ID it doesn't seem to have any effect at all: try? await AppStore.sync() This doesn't return any item for await result in Transaction.currentEntitlements { if case let .verified(transaction) = result { } } This doesn't return any item for await result in Transaction.all { if case let .verified(transaction) = result { } } As mentioned before I'm trying this after purchasing the item and deleting the app. So I'm sure it should be able to restore the purchase. Am trying this both with a Configuration.storekit file on the simulator, and without it on a real device, in the Sandbox Environment. Has anyone being able to restore purchases using StoreKit 2? PD: I already filed a feedback report on Feedback Assistant, but so far the only thing that they have replied is: Because StoreKit Testing in Xcode is a local environment, and the data is tied to the app, when you delete the app you're also deleting all the transaction data for that app in the Xcode environment. The code snippets provided are correct usage of the API. So yes, using a Configuration.storekit file won't work on restoring purchases, but if I can't restore them on the Sandbox Environment I'm afraid that this won't work once released, leaving my users totally unable to restore what they have already purchased.

Hello! My subscriptions have been stuck in review for a while. I have been chasing my tail trying to get the sandbox purchases to work but the subscriptions are not returning after "sale". Is this because the subscriptions are still in review? Will the purchase ever return a product in the sandbox environment if the products are still in review? How do we get the subscriptions approved? I have submitted them with the app multiple times. The app is rejected because I can't complete it without the subscriptions but the subscriptions are never reviewed. Help!

你好： 以下是我的问题： 问题类型：苹果内功IAP相关问题 问题详情：我的应用是免费下载，内购一次性解锁。对于没有下载过应用的人使用我创建的优惠码，会直接显示花钱付费下载。这里是我设置的问题么?

Hi! I’m facing some difficulties while integrating with Apple external purchase API. I would like to clarify a few points in the documentation. Subscription Events Documentation mentions four subscription events: SUBSCRIPTION_START, SUBSCRIPTION_CHANGE, SUBSCRIPTION_PAYMENT, and RENEWAL. Could you clarify what SUBSCRIPTION_PAYMENT is used for? The examples indicate that we should send the tax and payment amounts in the SUBSCRIPTION_START and RENEWAL events. Should we also send them for SUBSCRIPTION_PAYMENT? 2. Unused Tokens Customers generate ACQUISITION and SERVICE tokens and send them to us. According to the documentation, we must report every token received. If we process balance transactions linked to an ACQUISITION token, should we send the SERVICE token with NO LINE ITEM? Should we continue sending the SERVICE token with NO LINE ITEM status in the following months? 3. Should we send reports only once a month? What should we do if, at the time a transaction is received, the token was active, but by the time the report is due, it has already expired? Do we still need to report it in that case? 4. What should we do if we receive a notification about an unreported token in the middle of the month? Should we send the report immediately, or should we take note of the token and include it in the report at the scheduled time at the beginning of the month? 5. Am I correct in understanding that if a user purchases a monthly subscription and cancels the renewals within the same month, the reports will contain only one event — SUBSCRIPTION_START with subscriptionDaysOfPaidService = 0? If a renewal for a monthly subscription fails and the payment is completed after a 7-day grace period, should we report 37 days or 30 days in subscriptionDaysOfPaidService in the RENEWAL event? Thank you in advance for your guidance!

Hi, We are facing issue with purchases on iOS 26.4. The app store receipt received is from previous transaction leading to receipt validation failures. There are some purchase success observed for pending transactions but success rate for pending transactions is also very low. We are using Unity In-App Purchasing (IAP) 4.13.0. Let us know for any more details and any fix / workaround available. Thanks.

iOS 26.4系统上，我们发现三个问题： 1.调用了finishTransaction接口，但是在App重新启动后，[SKPaymentQueue defaultQueue].transactions仍然会有这笔订单。 2.支付完成后，[[NSBundle mainBundle] appStoreReceiptURL]]，拿到的票据解析出来里面的商品是空的，需要延迟2秒钟左右在调用[[NSBundle mainBundle] appStoreReceiptURL]]才能获取有效票据。 3.支付完成后，如果用户没有点击最后弹出的确认弹框，等待5秒钟，系统会自己回调 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions; 代理方法。正常应该是用户点击了最后弹出的确认弹框，在回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions;方法。 我们在苹果开发者论坛上面找到其他开发者反馈的类似问题，链接如下： https://developer.apple.com/forums/thread/817700 https://developer.apple.com/forums/thread/792437?answerId=849557022#849557022 https://developer.apple.com/forums/thread/817834 https://developer.apple.com/forums/thread/817706 https://developer.apple.com/forums/thread/818586 我们有大量用户升级到了26.4系统，这对于我们造成了巨大的困扰，我们需要你们的帮助，感谢！

We're seeing some strange behavior of the appAccountToken when passing it to a purchase in the sandbox environment. Normally we'd expect the same account token to be set on the resulting verfication, but that's not the case. Instead the token seems to be persisted on the API side and reused for some amount of time, meaning there's a mismatch and the connection between account and purchase is lost. This happens consistently even if we send new tokens on each purchase. Has there been any updates to purchase flow in the sandbox environment on Apple's side? .purchase( options: [.appAccountToken(token)] )

Greetings fellow devs, After accepting the Alternative Terms Addendum for Apps in the EU and adding the Storekit External Purchases or Offers capability via App Store Connect in our app identifier, the entitlement showing up in xcode is com.apple.developer.storekit.custom-purchase-link.allowed-regions and has the value 'jp'. How can we change the value for that entitlement to 'gr'? We tried changing it in xcode, but we get the error <Provisioning profile "iOS Team Provisioning Profile: [app identifier]" doesn't match the entitlements file's value for the com.apple.developer.storekit.custom-purchase-link.allowed-regions entitlement.>. In Certificates, Identifiers and Profiles in the developer account there is no way to configure that capability. We sent a request to support and they only gave a link to documentation and to the forum here. We have a completed every business agreement requested and we have chosen Greece as the organisation region and the app's availability region wherever possible. We haven't found anywhere that Japan would be chosen to explain the entitlement given. So where can this entitlement about allowed regions be configured? Xcode version is 16.4 and iOS minimum deployments is 18

Need to vent a bit before relaxing for Christmas... WatchOS IAP using Storekit 2 is such a mess...is nobody actually using this or does Apple just not care for the user experience here? Lots of users experience after the purchase confirmation double tap on the side button an instant return to the purchase screen with nothing actually happening. No error message whatsoever. There is just one remedy: users need to unpair and re-pair their watch, including restoring a backup and setting up their wallet again. Nobody really wants to do this, or doesn't believe me and think this is just typical support BS, because their watch is paired and most things just work as they expect. And it turns away a customer, often leaving a bad review. And I can't do anything about it. Other errors in the purchase process are reported, but like "process interrupted" in case the payment is not setup correctly (credit car no longer valid or sth.). How should the user know? There must be better ways of letting him know what exactly the problem is. You need to implement a "Restore Purchase" function, otherwise you're not passing the review. But it really asks every time for the AppStore password, and users with crazy passwords -- that they rightfully should have! -- have almost no chance of typing them successfully on the tiny AW keyboard. Why is it not also just a side button double tap like for purchase? At the very least you would need access to the keychain PWs or allow pasting of sth. copied on the paired iPhone. Promo Codes for IAP on AW-only apps just don't work. AW has no redemption at all, and on the iPhone the AppStore will try to talk to a companion app (which AW-only doesn't have) and the end up in a dead-end installation effort. This all feels like never really tested in the field, and people are of course blaming the 3rd party dev. for all these issues. And opening a ticket is just leading nowhere -- at best it's closed after months with the hint "duplicate" but w/o any chance for me to see that one that they then actually work on and track progress. It's all so frustratingly broken...

Hello, I have an issue with In-App Purchases during App Review. In TestFlight and Sandbox, everything works correctly: Products are loaded Subscriptions are visible Purchase completes successfully However, Apple reports that the purchase fails during review. My subscriptions are: Created and active in App Store Connect Attached to the app version Paid Apps Agreement accepted I also added all required information (price, duration, EULA, privacy policy). Why would purchases work in TestFlight but fail during App Review? Thank you for your help.