General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

My app is live on the App Store and all three auto-renewable subscriptions are Approved, but StoreKit 2 never answers on device. Product.products(for:) does not settle — no products, no error, no throw. I let it run 30 seconds. Storefront.current behaves the same way, so this is not a product-id or catalogue problem. StoreKit is not reaching a store at all. Already ruled out: Product ids app.steady.pro.weekly / .monthly / .yearly, all Approved; subscription group Approved Bundle id app.steady.calm, matches App Store Connect exactly Paid Applications Agreement Active, bank and tax forms Active In-App Purchase capability enabled on the App ID and present on the App Store provisioning profile Two iPhones, two Apple Accounts, storefronts AZ and TR, three networks A clean build run directly from Xcode on a different Mac — identical silence Also reproduced through a third-party purchases SDK before reverting to plain StoreKit 2, so it is not my bridge layer This has never worked once, on any device or account, since launch. It is not intermittent. Open with Apple: Developer Support case 20000143122321, Feedback FB24488724 with sysdiagnose attached. Has anyone seen Storefront.current hang like this? Is there an account-level state that can stop StoreKit from resolving a storefront even when the app and products are approved?

I'm looking for clarification on how the new EU business terms apply to a code-redemption flow. My app sells self-guided digital audio tours via Apple In-App Purchase. I would also like to sell the same tours independently through third-party travel marketplaces (general tour and activity booking platforms). The proposed flow: The app would not advertise, mention, or link to these marketplaces in any way. After purchasing a tour externally, an EU customer receives a booking code. In the app, the customer taps "Enter a booking code," types the code, and taps "Fetch Tour." The app verifies the booking against our server and unlocks the purchased tour, with no additional payment taken. The same tours remain available for direct purchase through Apple In-App Purchase. App Review has previously rejected this type of code-redemption functionality under the In-App Purchase rules. Two questions: Is this exact flow now permitted on EU storefronts under Attachment 14, using the StoreKit External Purchase or External Purchase Link entitlement? Do these externally initiated sales need to be reported to Apple, or incur an Apple commission, given that the app contains no external offer, marketplace name, purchase instructions, or actionable link? Thanks in advance for any guidance.

Hi, Overview I have an app for which I have created a sandbox account. When I try to clear purchase history it doesn't work, it still shows the in-app purchase items (non-consumable in-app purchases) as purchased. I have tied tried the following ways, but none of them work. Any help on this would be much appreciated! Attempt 1: Go to https://appstoreconnect.apple.com/ Users and Access > Sandbox Check sandbox account > Tap Clear Purchase History button Attempt 2: Go to the iPhone > Settings > Developer > Sandbox Apple Account Tap on account > Manage > Clear Purchase History Attempt 3: Sign out of Sandbox account and sign back in Attempt 4: Delete app and re-run app from Xcode

Hello, I am investigating an intermittent In-App Purchase failure that occurred during App Review for the first release of my app. Environment Review device: iPad Air 11-inch (M3) OS: iPadOS 26.6 Environment: App Review sandbox Product type: Consumable StoreKit integration: RevenueCat through react-native-purchases 10.4.3 Observed behavior StoreKit successfully returned the products, localized names, and prices. The reviewer could see the credit packs and initiate the native purchase flow. My diagnostics show this sequence: Purchase initiated PURCHASE_CANCELLED; no transaction evidence Purchase initiated again RevenueCat code 2: STORE_PROBLEM elapsed: 9.4 seconds no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE elapsed: 0.6 seconds no transaction evidence code-block The relevant sanitized logs are: { "occurredAt": "2026-08-25T12:52:59.733Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "2", "providerReadableCode": "STORE_PROBLEM", "transactionEvidence": false, "elapsedMs": 9417 } code-block { "occurredAt": "2026-08-25T12:55:42.752Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "5", "providerReadableCode": "PRODUCT_NOT_AVAILABLE_FOR_PURCHASE", "transactionEvidence": false, "elapsedMs": 637 } code-block No App Store transaction was created, and therefore RevenueCat received no transaction or webhook for these attempts. Configuration verified I confirmed that: The affected product and the other consumable products are attached to the App Review submission. Product IDs match between the app, App Store Connect, and RevenueCat. Prices and localizations are configured. The products are available in the relevant storefronts. The Paid Apps Agreement is active. Banking and tax information are active. The In-App Purchase capability is present. The distribution build does not use a local StoreKit configuration file. The same build and affected product completed successfully afterward on a physical device using Apple Sandbox. The native purchase sheet opened, the transaction completed, and the consumable content was delivered successfully in my reproduction. The product metadata clearly remained available because its localized name and price were displayed. However, after the initial STORE_PROBLEM, subsequent purchase requests were rejected almost immediately as PRODUCT_NOT_AVAILABLE_FOR_PURCHASE. I do not have the underlying Apple NSError, such as an ASDServerErrorDomain or AMSErrorDomain value, because it was not exposed in my remote diagnostic record. Questions Can a failed sandbox transaction leave the StoreKit account/session or commerce-catalog state temporarily inconsistent, causing subsequent requests for an otherwise loaded product to return storeProductNotAvailable? Does StoreKit use separate metadata and transaction-eligibility services, allowing product information to load while the same product is rejected during purchase()? Are there known sandbox or StoreKit issues on iPadOS 26.6 that could produce this sequence? Could a stale App Review sandbox account token or storefront session explain the transition from STORE_PROBLEM to PRODUCT_NOT_AVAILABLE_FOR_PURCHASE? Is there any developer-side configuration that could explain this when the same product and binary complete successfully using another sandbox session? What additional logging should I capture from RevenueCat’s React Native SDK to preserve the complete underlying Apple error chain?

I'm testing iAP in a sandbox account (as configured in App Store Connect under 'Sandbox Testers'). So the in app purchase works. Cool. But I wanted to retry it. So I cleared the purchase history (both in App Store Connect and on my iPad in the 'Developer' section in Settings). But when I relaunch my app the purchase still validates and my app displays the item as 'unlocked'. Figure the receipt must still be cached so I nuke the app and completely reinstall it but it appears StoreKit is still getting the receipt and it isn't being cleared because my app is displaying it as 'purchased.' Also tried rebooting the iPad. But the sandbox purchase doesn't clear. I just did a sandbox test since it is closer to real life than StoreKit Configuration so I just wanted to do it a few times to make sure all is good but making a burner test account for every purchase is kind of tiresome. Anyone know of a workaround? I might just declare victory and go back to StoreKit Configuration.

We are implementing in-app purchases using StoreKit 2. The issue we need guidance on is how our app should correctly handle a StoreKit 2 transaction that becomes .unverified during Apple App Review. In our local development testing, purchases work correctly. When we test the same IAP products locally, the transaction returned from Product.purchase() is .verified, and the purchase flow completes successfully. However, during Apple App Review, the reviewer appears to encounter a failure where the StoreKit 2 transaction is returned as .unverified on the client side. The original localized error message shown is in Traditional Chinese: 「資訊對裝置無效」 Our English translation of this message is: “The information is not valid for this device.” Because the message is localized, we are not sure what the exact original English StoreKit error string would be. This failure happens in the client app before our backend receipt or server-side validation flow. We are not using verifyReceipt for this step. The failure occurs at the StoreKit 2 VerificationResult level when checking the transaction returned by StoreKit. Our current implementation only accepts .verified transactions. If StoreKit 2 returns .unverified, we treat the transaction as failed and do not unlock the purchased content. We believe this is the recommended secure behavior, but we would like to confirm the correct handling, especially because this issue is appearing during App Review while our local development purchases succeed. Additional context: • Distribution/review context: App Review / IAP review • API: StoreKit 2 • Failure point: VerificationResult returned as .unverified • Localized error message: 「資訊對裝置無效」 • Rough English translation: “The information is not valid for this device.” • Local development testing: purchases return .verified and succeed • The issue occurs before backend validation • Our app currently rejects .unverified transactions and does not unlock content Questions: What are the known causes of StoreKit 2 returning .unverified with the localized error message 「資訊對裝置無效」 during App Review? Is our current behavior correct: only unlock content for .verified transactions and reject .unverified transactions? If App Review receives .unverified, what should the app do from Apple’s recommended perspective? Should we show a retry/error message, ask the reviewer to retry, refresh entitlements, or take another action? Is there any App Review environment, device configuration, Apple ID configuration, or StoreKit account state that can cause this device-related verification error? Since local development purchases succeed but App Review fails, what diagnostics or logs should we collect and provide to identify the root cause? Should we ever bypass StoreKit 2 transaction verification in App Review/TestFlight, or should .unverified always be treated as a failed transaction? We would appreciate guidance on the correct code-level handling so that our app remains secure while also passing App Review reliably. Thank you.

I'm seeing behavior similar to what was reported in this thread: https://developer.apple.com/forums/thread/816344 I read the discussion in the related thread (816320) as well, but I couldn't determine whether receiving the same transaction multiple times from Transaction.updates is considered expected behavior. In my case, I'm testing an auto-renewable subscription in the Sandbox environment. After successfully processing and calling finish() on a transaction, Transaction.updates sometimes provides another transaction with the same transactionId. I've also observed the same transactionId being delivered multiple times through Transaction.updates itself. I compared the JWS representations of these transactions. They are not byte-for-byte identical, but the transaction information appears to be the same. The only differences I've identified are: signedDate deviceVerificationNonce deviceVerification This looks as though the same transaction is being signed again at a different time. I'd like to clarify the intended way to handle this: Is it expected behavior for Transaction.updates to deliver the same transactionId multiple times in this way? If so, after an app has successfully processed and finished a transaction, is it safe to recognize subsequent transactions with the same transactionId as already processed, skip entitlement-related processing, and simply call finish() on them? In other words, can an app use transactionId to prevent duplicate processing of transactions that it has already successfully handled? I'm specifically interested in whether doing so could cause the app to miss any meaningful update that StoreKit might later deliver using the same transactionId.

I’m trying to determine the supported submission path for the first non-consumable IAP in a watchOS-only app. Configuration The app uses a standard watch-only container: Container: com.seanfu.safe Watch app: com.seanfu.safe.watchkitapp ITSWatchOnlyContainer = true WKWatchOnly = true WKApplication = true It offers one non-consumable “Full Version” unlock and uses StoreKit 2: Product.products(for:) Product.purchase(options:) Transaction.currentEntitlements Transaction.updates The product ID in the Release binary exactly matches App Store Connect. Paid Apps agreements, banking, tax, pricing, and territory availability are active. The Release archive contains no local .storekit configuration or test bundle. TestFlight works, but App Review receives no product In TestFlight, using the real App Store sandbox and App Store Connect product configuration, Product.products(for:) returns the correct product, localized price, and title. The purchase sheet can be presented. During App Review, the same request repeatedly returns an empty array without throwing an error. The reviewer sees this application-defined diagnostic: IAP-L-01(empty x5) This is not an Apple or StoreKit error code. It means: Five separate Product.products(for:) calls completed without throwing. Every call returned an empty product array. The diagnostic appears only after the initial request and limited retries are exhausted. Thrown StoreKit errors use different diagnostics. The app does not locally filter a successfully returned product. Therefore, the screenshot means StoreKit returned no matching product in five consecutive requests. This has happened in multiple review attempts, while the same Release code path works in TestFlight. An App Review representative contacted us and explicitly stated that a watchOS-only app can be reviewed and tested with IAP. They suggested investigating our StoreKit integration, but our audit found no code path that could transform a non-empty response into this diagnostic. Submission behavior changed Earlier watchOS-only builds could be submitted with both: The app version The “Full Version” IAP Those submissions reached App Review, where the product was empty: Submission accepted → Review starts → Product array is empty For build 23, we explicitly added the In-App Purchase capability to the Watch target in Xcode. The project now records the IAP capability and explicitly links StoreKit.framework. This did not add an IAP entitlement to the signed app. The bundle IDs, watch-only packaging, product ID, StoreKit code, pricing, availability, agreements, banking, and tax status remained unchanged. After uploading build 23, App Store Connect no longer allows the app version and IAP to be submitted together. The draft contains: iOS App 1.0, build 23 The “Full Version” non-consumable IAP App Store Connect blocks the submission and says IAPs and subscriptions are not supported on Apple Watch and must be removed from the submission. The behavior is now: App version + IAP selected → Submission blocked before review This timing does not prove that adding the Xcode capability caused the change. App Store Connect may have changed its validation, or the new build may have caused its watch-only classification to be reevaluated. However, the transition is notable: earlier submissions were accepted but the product was unavailable during review; the current submission is blocked entirely. Contradictory documentation StoreKit documentation says the Swift IAP API is available on watchOS 8+: https://developer.apple.com/documentation/storekit/choosing-a-storekit-api-for-in-app-purchases The documentation for purchase(options:) specifically says to use it for apps running on watchOS: https://developer.apple.com/documentation/storekit/product/purchase(options:) However, App Store Connect documentation says IAPs are not supported on Apple Watch and must be removed before submitting an Apple Watch app version: https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/submit-an-in-app-purchase/ The same page says the first non-consumable IAP must be submitted with a new app version. This creates a circular requirement: The first non-consumable IAP must accompany an app version. An Apple Watch app version cannot include an IAP. A watchOS-only app therefore appears unable to submit its first IAP. Questions What is the supported path for submitting the first non-consumable IAP of a watchOS-only app? Can Apple review the first IAP separately, or apply a backend override, despite the requirement to include it with an app version? Is an iPhone companion app required, with watchOS IAP support intended only for Watch apps associated with a regular iOS app? Could the unsupported submission association explain why TestFlight sandbox returns the product while App Review receives an empty array? Why were earlier watchOS-only submissions accepted with the IAP attached, while build 23 is blocked despite unchanged bundle IDs and watch-only packaging? Does App Store Connect use the Xcode IAP capability or explicit StoreKit linkage when validating the submission? Clarification from a StoreKit or App Store Connect engineer would be greatly appreciated. The StoreKit documentation, App Store Connect validation, and guidance from App Review currently describe different behaviors.

The in-app purchase payment function of the TestFlight package always defaults to providing products from the United States, even if I log in with an AppStore account from the Chinese region. The products obtained are still from the United States. Only when I make the purchase and am prompted to log in to the sandbox account will Chinese products be displayed. Storefront.current = USA

We're getting user reports that the App Store rating prompt appears repeatedly — one user says they're prompted roughly every day, and that they still get the prompt after they've already left a rating. This contradicts the documented behavior, so I want to check whether others are seeing the same thing or whether there's a known regression. What the docs say should happen The system limits display to 3 occurrences per app within a 365-day period. For a user who has already rated/reviewed, StoreKit should only display again if the app version is new and more than 365 days have passed since their previous review. Has anyone else experience it?

Summary: The "In-App Purchases or Subscriptions" selection section does not appear on my app version page, so I cannot attach my first In-App Purchase to my build. This has caused four consecutive Guideline 2.1(b) rejections. Setup: App: Qmetra IQ (Apple ID 6791254506, Bundle ID com.vibecode.qmetraiq.londa9) First app release, never published App version 1.0, current build 1.0.1 (2) Non-consumable IAP: com.vibecode.qmetraiq.londa9.results (Apple ID 6792799431) IAP status: Ready to Submit App Review screenshot for the IAP: uploaded (1242×2688) Paid Apps Agreement signed, banking and tax complete, no open items under Business What I see: On the version page, the "In-App Purchases or Subscriptions" heading exists, but contains only an informational message ("...add an app version to your submission so the items are reviewed together..."). There is no button, link, checkbox, or "+" to select the IAP. The submission draft panel contains only the app version, with no way to add the IAP. Opening the draft from the IAP page shows only the IAP, with the warning "Cannot be submitted for review — add an app version for the selected platform", and the "Submit for Review" button greyed out. What I have tried: Removed the previous rejected submission from review, then rechecked the version page — section still absent Assigned a fresh build (1.0.1 build 2) and saved Re-saved the IAP metadata Resubmitted the app version alone — rejected again under 2.1(b) Replied in the review thread twice — no resolution Rejection reason each time: "one or more of the In-App Purchase products have not been submitted for review." Could an Apple staff member please forward this to App Store Connect Support or engineering so the In-App Purchase can be moved to In Review manually? Several older threads describing this exact bug were only resolved that way. Happy to share more details privately if needed. Thank you.

I've been struggling to work with the Storekit framework and specifically to find the current Storefront used by the user of the app. Context : My app needs to behave differently depending on the country of the user. For me relying on Locale.current.region?.identifier does not seem very reliable, the user can change it really easily. I'm trying to use the Storekit framework like so : if let storefront = await StoreKit.Storefront.current{ return storefront.countryCode } As per Apple's Storekit documentation : Use current to determine a customer's current storefront region and offer in-app products suitable for that region. You maintain your own list of product identifiers and the storefronts in which you make them available. But I just can't find out what I need to change in my current configuration to get another country. The code keeps returning my original storefront (which is France) I've tried login in with a sandbox user defined on another country. Changed all settings on my device to another country. Changed my Apple's account region as described here. Also tried to logout from everything. The only thing that works is setting a local .storekit file as described here and changing the default storefront. Is Xcode overriding the default storefront when building on debug or TestFlight? does anyone know how can I test different storefronts with sandbox users without the local storekit file ? Thank you in advance.

I have filed Feedback Assistant report FB24182480 for this issue. On an Apple Watch Series 6 running watchOS 26.6 (23U67), a TestFlight watchOS app can successfully load a non-consumable StoreKit 2 product from Sandbox and display its localized price. However, a subsequent single call to product.purchase() can fail before, or while, the system confirmation sheet is displayed. The app itself remains alive. It receives StoreKit.StoreKitError.systemError (code 1), with an underlying NSCocoaErrorDomain error 4097, consistent with losing the XPC connection to storekitd. The affected run’s private co-sysdiagnose shows this sequence: storekitd starts processing the payment. The Sandbox purchase request returns HTTP 200. AMSPaymentSheetTask begins. The kernel reports that storekitd exceeded its ActiveSoft 5 MB limit and terminates it as the high-water process. The app receives Cocoa error 4097. A later user-initiated retry was handled by a restarted storekitd process and ended with the same result. There are no overlapping product, entitlement, or purchase operations, and the app does not automatically retry purchase(). The issue is intermittent: in other runs on the same Watch, the Sandbox purchase sheet has appeared successfully. This makes it appear to be a system purchase-service lifecycle or memory-management issue rather than a product-configuration or product-loading issue. Environment: Apple Watch Series 6 (Watch6,4) watchOS 26.6 (23U67) TestFlight build StoreKit 2 Sandbox non-consumable IAP One explicit Buy tap per attempt Has anyone seen storekitd being terminated with a high-water reason during a watchOS purchase flow, or found a supported app-side mitigation for the resulting StoreKit error 1 / Cocoa 4097? I have kept the sysdiagnose and recordings private in Feedback Assistant because they contain account, device, and network information.

Hello, I am currently implementing External Purchase Link and External Purchase Custom Link and am encountering an issue where both ExternalPurchaseLink.canOpen and ExternalPurchaseCustomLink.isEligible always return false under all test conditions. I would like to confirm whether my setup is missing any required steps or whether this behavior is expected. Below are the details of my current environment and configuration: 🔧 1. Development Environment Xcode: 16.3, 16.4, 26.0 beta 4 Devices: iPhone running iOS 26.2 beta iPhone running iOS 16.7.12 macOS 15.5 (real device testing) Simulator iOS 18.0 Build Type: Local development build using a Developer Provisioning Profile Sandbox account signed in during testing 🔑 2. Entitlements (Developer site & Xcode) In Certificates → Identifiers → App ID, both capabilities are enabled: StoreKit External Purchase StoreKit External Purchase Link The .entitlements file in Xcode includes: com.apple.developer.storekit.external-purchase = YES com.apple.developer.storekit.external-purchase-link = YES The Provisioning Profile also contains both entitlements (confirmed via codesign -d --entitlements :-). 📄 3. Info.plist Configuration Both keys are configured with correct region codes according to documentation: SKExternalPurchase SKExternalPurchaseCustomLinkRegions 🌍 4. Test Storefront Device storefront verified as United States (US) or Portugal (PT) (US = target region for External Purchase Link, PT = EU region) But despite all the above configuration, both API calls consistently return false: ExternalPurchaseLink.canOpen // false ExternalPurchaseCustomLink.isEligible // false So I cannot proceed to testing the remaining flow (token retrieval, link opening, etc.) ------ Questions ------ ❓ Q1) Local Development Build Limitation Is it expected behavior that Developer-signed local builds always return canOpen = false / isEligible = false for External Purchase Link & Custom Link? Is there a technical or policy restriction that prevents eligibility in local dev builds? ❓ Q2) App Store Connect Configuration Requirement Are there mandatory App Store Connect settings (such as external purchase URLs, support URL, disclosures, or country configuration) that must be enabled before eligibility becomes true? Currently, no External Purchase Link or Custom Link menu is visible in my App Store Connect app settings. Is this menu only available after certain approvals or under specific conditions? ❓ Q3) TestFlight Requirement Do External Purchase Link and Custom Link only return eligibility = true on: TestFlight builds, or Distribution-signed builds? Or should eligibility also work on developer builds? Formal confirmation would be helpful. ❓ Q4) Developer Account Type Limitation We are using an Individual Developer Account (not Organization). Can Individual accounts fully request, test, and ship apps using: External Purchase Link External Purchase Custom Link Or are there limitations on account type? 🙏 Request We have completed all documented setup steps (Entitlements → Provisioning → Info.plist), but eligibility remains false, blocking feature validation. Please clarify which of the following is the cause: Local development builds do not support eligibility Missing App Store Connect configuration (not visible to us) Account type restriction Region rollout or entitlement approval requirement Any additional setup not documented publicly Thank you for your assistance.

App: com.playatrium.mobile Issue: StoreKit 2's Product.products(for:) returns USD pricing regardless of account region on TestFlight builds. Account/device confirmed UK at every layer I can check: App Store Connect developer account region: UK Personal Apple ID Media & Purchases country/region: UK Device region: UK No .storekit configuration file present in the project In-App Purchase capability confirmed enabled on the App ID The native purchase sheet, for the SAME product in the SAME app session, correctly resolves and displays GBP, and purchases complete successfully with correct entitlement grants on our server. So the purchase flow itself resolves the storefront correctly — only the catalog/pricing query does not. Console.app shows the account object with storefront = (null) at the moment of the catalog query: account = <ACAccount: ... storefront = (null)> and the resulting request falls back to /catalog/us/ with locale es-MX, rather than the correct territory. I've seen a few threads here with similar symptoms (products returning empty or wrong-region data on TestFlight specifically, working fine via local StoreKit config in the simulator) but haven't found a clear explanation or fix. Anyone know why Storefront.current / the catalog query would fail to resolve correctly on TestFlight while Product.purchase() resolves fine in the same session?

I am experiencing a StoreKit issue on iOS 27 Beta with eFootball™ 11.0.0 (jp.konami.pesactionmobile). After an in-app purchase, the app becomes stuck on an infinite loading screen during login. If I manage to log in, the in-game Shop also remains stuck loading. I investigated the issue using macOS Console and found that StoreKit repeatedly attempts to finish the same production transaction every approximately 2–3 seconds. The relevant logs are: Starting request FinishTransactionRequest(...) Failed to encode request parameters NSCocoaErrorDomain Code=3840 Error finishing transaction: StoreKitServiceError StoreKitInternalError.requestEncodeFailed The same transaction is repeatedly passed to FinishTransactionRequest, but the finish operation never succeeds. What I have confirmed The purchase itself was confirmed by Apple Support as successfully completed. The transaction is a Production transaction with the JPN storefront. Reinstalling eFootball does not resolve the issue. Restarting the iPhone does not resolve the issue. Signing out and back into "Media & Purchases" with the affected Apple Account does not resolve the issue. Network requests from the app itself are succeeding with HTTP 200 responses. The issue occurs when StoreKit attempts to finish the transaction. Most importantly, if I sign out of the affected Apple Account under Media & Purchases and sign in with a different Apple Account on the same iPhone, eFootball immediately works normally again — both login and the Shop load successfully. If I switch back to the original Apple Account, the issue returns. Steps to reproduce Use the affected Apple Account for Media & Purchases. Launch eFootball. Attempt to log in. The app remains stuck loading. Observe Console logs from storekitd. The same transaction repeatedly triggers FinishTransactionRequest. Each attempt fails with StoreKitInternalError.requestEncodeFailed. Expected behavior StoreKit should successfully finish the completed transaction, remove it from the unfinished transaction queue, and allow the app to continue normally. Actual behavior FinishTransactionRequest repeatedly fails with requestEncodeFailed, causing the same transaction to be processed indefinitely and preventing normal use of the app. Has anyone encountered the same behavior on iOS 27 Beta? Is this a known StoreKit issue, or is there any way to safely clear/finish the affected production transaction without restoring the device to the current public iOS release?

Does anyone have any advice on working a way around this, or through this? My app is wrapped and WKWebView displays HTML/CSS/JAVA and StoreKit is iOS framework. I used choicely up wrap it because i don't own a mac. The only part i can't control is this. I'll likely have to wrap it myself, rent a cloud Mac and submit directly to ensure everything is attached to the binary. I can't control that from choicely. any other ideas!? I’ve been over a month trying to get this going. It’s live but with no way to transact the subscribers I’m already getting. HELP PLEASE!

Transaction.finish() doesn't clear a transaction on iOS 27 beta 5 — worked correctly through beta 4 — every repeat purchase after the first replays the same transaction with no confirmation sheet and no charge. StoreKit.Transaction.finish() does not clear a transaction on iOS 27 beta 5. The transaction remains in Transaction.unfinished indefinitely, and every subsequent Product.purchase() call for that product returns the same stale transaction instead of starting a new purchase — with no confirmation sheet, no charge, and no way for the app to tell it apart from a genuine purchase. Because the replayed result is .success carrying a VerificationResult that verifies normally, an app has no supported signal that nothing was bought. The only distinguishing traits are that the id and purchaseDate are unchanged and the call returns in ~10ms instead of making a server round-trip. Consequence: a consumable product can be purchased exactly once per device. Every later attempt silently no-ops while appearing to succeed. Steps to Reproduce On a device running iOS 27 beta 5, sign in to a newly created Sandbox Apple Account (Settings → Apps → App Store → Sandbox Account) with no prior purchase history. Install and launch a development build of an app offering a consumable IAP. Confirm Transaction.unfinished is empty. Purchase the consumable. The confirmation sheet appears and the purchase completes normally. await transaction.finish() on the returned transaction. Enumerate Transaction.unfinished again. Purchase the same consumable a second time. Expected Results Step 6: Transaction.unfinished is empty — the transaction was finished. Step 7: a confirmation sheet appears and a new transaction is created, with a new id and a current purchaseDate. Actual Results Step 6: the just-finished transaction is still listed in Transaction.unfinished. Step 7: no confirmation sheet appears. purchase() returns .success in ~0.01s carrying the same transaction — identical id and identical purchaseDate — and nothing is charged. This repeats indefinitely. Re-fetching the transaction from Transaction.unfinished and calling finish() on that instance does not clear it either, so there is no app-side way to drain the queue. Diagnostic Log Virgin sandbox account, empty queue, three consecutive taps on one product: unfinished before tip.small: [] purchase() returned after 18.10s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 --- await transaction.finish() --- unfinished after finishing 2000001221113013: [small#2000001221113013] unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 The first call is a genuine purchase (18s round-trip, sheet shown). The transaction survives its own finish(). Calls two and three are replays of it. Notes Not reproducible against a local .storekit configuration in the Simulator, which always presents the confirmation sheet. Requires Apple's sandbox. Also reproduces on a TestFlight build billed to a real Apple ID, where it is worse: TestFlight purchase history cannot be reset, so the affected products stay permanently stuck for that account. It survives deleting and reinstalling the app, and a device reboot. Possibly the same underlying issue as the unanswered report at https://developer.apple.com/forums/thread/808648 (iOS 26/18, Nov 2025). Configuration Device: iPhone 16 Pro Max OS: iOS 27 beta 5 Products: consumable in-app purchases API: StoreKit 2 (Product.purchase(), Transaction.finish(), Transaction.unfinished)

Hi, We've implemented age assurance logic in our app using the DeclaredAgeRange framework to comply with regulations in Brazil (Digital ECA, effective March 17, 2026) and Utah (App Store Accountability Act, effective May 6, 2026). Our implementation calls AgeRangeService.shared.isEligibleForAgeFeatures on app launch to determine whether the current user is subject to age assurance requirements, and proceeds to call requestAgeRange(ageGates:) accordingly. However, after monitoring in production since the Brazil enforcement date, we've consistently observed isEligibleForAgeFeatures returning false for users in regulated regions, with no age range data being returned. What we'd like to clarify: Is isEligibleForAgeFeatures currently returning true for users in Brazil in production (not sandbox)? For Utah — given that HB 498 pushed the developer compliance deadline to May 6, 2027, will isEligibleForAgeFeatures reflect the original May 6, 2026 activation date or the revised 2027 date? Is there a known rollout schedule or gradual activation plan for these regions that would explain why the flag remains false even after the legal enforcement dates have passed? We've seen similar reports from other developers on these forums, so it seems this may be a widespread issue rather than an implementation problem on our end. Any official guidance on the current status of the API in regulated regions would be greatly appreciated. Thanks.