Our iOS app update has been in "Waiting for Review" since Oct 5. On Oct 3, promptly after initial App Review submission on Oct 2, App Review sent an automated message asking us to confirm the intended prices of several in-app purchase products (subscriptions). We confirmed (via sending 2 messages back) within a few hours of the automated message on Oct 3. Early last week, not understanding if I should resubmit the app for review or not (since I had not heard anything from Apple yet), I waited 48 hours and submitted the app for review on Oct 5th morning. I still have not heard anything since (almost a full calendar week). We've opened a Developer Support case (102989025859) on Oct 7 and submitted an expedite request (on Oct 9). Is there anything else we should be doing, or is a delay like this expected after an automated pricing verification? Submission ID: 7919390f-9e10-4b16-84bc-aa74c9f40300 Thank you for any guidance or help. Best Regards, DH

Hello everyone, I am currently refining our server-side transaction verification and purchase tracking using StoreKit 2 and the App Store Server API. We are looking into how our backend can accurately track the specific App Store commission rate applied to each individual transaction. With potential future regulatory changes in various markets that might introduce different fee structures between device types, it is becoming crucial for our system to distinguish these details at the transaction level. I contacted Apple Support regarding this but couldn't get a technical clarification, so I would like to ask the community and Apple engineers here: (1) Commission Rate: Is there any standard field in the StoreKit 2 Transaction payload or the JWS payload from the App Store Server API (V2) that explicitly indicates the applied commission rate (e.g., 15%, 30%) or a specific commission tier for that transaction? (2) Device Type: If the commission rate is not directly included, is there a native field in the real-time transaction payload to identify whether the purchase was made on an iPhone or an iPad? (I understand we can use appAccountToken as a workaround to link client-side device info to our backend, but I am wondering if there is a built-in identifier.) (3) Official Verification Method: If real-time API payloads contain neither, would using the App Store Connect API to retrieve the "Summary Sales Report" or "Subscriber Report"—and deriving the commission rate from Customer Price and Developer Proceeds—be the recommended approach? Are there any other best practices for handling this at scale? Any insights from Apple engineers or developers who have implemented similar tracking would be highly appreciated. Thank you in advance!

We are seeing a consistently reproducible StoreKit Sandbox issue involving Apple’s refund request sheet. Our app uses: Transaction.beginRefundRequest(for:) The refund sheet is successfully presented, but instead of loading the refund reason form, the Apple-provided sheet consistently displays: “Cannot Connect” This prevents the Sandbox refund request from being submitted. Environment: App: BTY Norebang Admin iOS: 26.6.1 Physical iPhone StoreKit environment: Sandbox Product type: Consumable Product: BTY Room – 1 Hour Development-signed build We have confirmed: Normal consumable purchase succeeds Transaction retrieval succeeds beginRefundRequest successfully presents Apple’s refund sheet App Store Server API calls succeed App Store Server Notifications V2 TEST delivery succeeds Get Test Notification Status reports sendAttemptResult = SUCCESS The problem persists after rebooting the device The problem persists after signing out and back into the Sandbox Apple Account Different network conditions have been tested The issue reproduces in an isolated Xcode/StoreKit test project with no BTY backend, authentication, or app networking dependency Expected behavior: The Sandbox refund request sheet should load the refund reason selection and allow the refund request to be submitted. Actual behavior: The Apple-provided refund sheet opens but displays “Cannot Connect.” No refund is submitted and no App Store Server Notification V2 REFUND event is generated. Feedback Assistant report: FB24527792 The Feedback Assistant report includes sysdiagnose and relevant diagnostic logs. This is currently the only remaining external blocker preventing us from completing full and prorated Sandbox refund end-to-end validation before enabling Production App Store Server Notifications. Could an Apple StoreKit / App Store Commerce engineer confirm whether this is a known Sandbox issue or advise whether any additional configuration or diagnostic information is required? We can provide a focused reproduction Xcode project, additional sysdiagnose logs, and Sandbox transaction details if needed.

Is there any way to activate Storekit External Purchase Entitlements in Russian region currently? External Purchase documentation's form link for this specific region is not working. Is there a workaround to register for it?

Live App Store app. Since 2026-09-01 PDT, StoreKit no longer returns our approved auto-renewable subscriptions on signed builds. The same SKUs load normally in Xcode when using a local StoreKit configuration file. New purchases are blocked. Monthly auto-renewals that were collecting normally through August 31 began failing their renewal attempts starting September 1, with all observed attempts entering Billing Grace / Billing Retry. App Name: Moonlit Bundle ID: moonlit.reading Versions affected: 1.1.1 — App Store version that was already live and working normally before September 1 1.1.2 — subsequently released to the App Store specifically to test whether a fresh production release would restore StoreKit behavior. It did not. Approved auto-renewable subscriptions, both in the same subscription group: moonlit.monthly.subscription moonlit.yearly.subscription Paid Apps Agreement, banking, and tax are Active in App Store Connect. We use an explicit App ID with the In-App Purchase capability enabled. Distribution builds do not contain a StoreKit Configuration file. The local .storekit file is used only for Xcode Run. Through August 31, 2026, Product.products(for:) and SubscriptionStoreView returned both SKUs and their prices correctly on production builds. Beginning September 1, 2026, and continuing through at least September 11: Every production paywall we can measure receives an empty StoreKit catalog with no product IDs, no prices, and no thrown StoreKit error. SubscriptionStoreView remains on its loading state. Our Terms / Privacy footer still renders because it does not depend on StoreKit. showManageSubscriptions / manageSubscriptionsSheet also hangs or fails to connect on the same signed builds. App Store Connect subscription events for the monthly SKU show a complete reversal beginning September 1. All observed renewal attempts in the affected window entered Grace from Paid, with no successful renewals, whereas the comparable August window showed normal successful renewals. Sales reports show no IAP proceeds for the affected September window. App downloads continue to appear normally, so the app itself remains available for sale. What still works Xcode + local StoreKit Configuration: Both products load Prices display The purchase sheet presents normally Analytics and logging continue to function, so this is not an app crash or missing paywall UI. The subscriptions are not Rejected and are not in Developer Action Needed. TN3186 / TN3188 checks have already been completed. This appears similar to other recent reports where App Store Connect contains a valid product catalog but StoreKit does not serve the products to signed builds: https://developer.apple.com/forums/thread/838171 https://developer.apple.com/forums/thread/841722 https://developer.apple.com/forums/thread/838773 https://developer.apple.com/forums/thread/836183 Developer Support case: 102959783559 Request Could an App Store Commerce or StoreKit engineer verify whether the app-to-IAP catalog association for moonlit.reading is populated and being served correctly on Apple’s side, and refresh or reprocess the production catalog if appropriate?

Hello everyone, In our iOS app, we offer multiple auto-renewable subscription tiers within the same subscription group: Lite (Monthly / Yearly) Basic (Monthly / Yearly) Plus (Monthly / Yearly) Pro (Monthly / Yearly) We are using Apple's native Offer Code redemption sheet (SKPaymentQueue.default().presentCodeRedemptionSheet() / AppStore.presentOfferCodeRedeemSheet). The Issue We Are Facing: The user navigates to our subscription screen and selects the Pro Plan. The user taps our in-app "Redeem Offer Code" button, which presents Apple’s native redemption sheet. The user inputs an offer code that was created in App Store Connect specifically for the Basic Plan. When the user taps "Continue", Apple accepts the code and immediately presents the Apple Pay / Face ID confirmation to charge/subscribe the user to the Basic Plan. Because presentCodeRedemptionSheet() does not take any product ID parameter, Apple accepts the code for whichever product it was created for, regardless of the tier the user had selected on our paywall. By the time our transaction observer receives the transaction callback (paymentQueue(_:updatedTransactions:)), the payment/purchase has already been finalized by Apple. Questions: Can we restrict the native sheet to a specific Product ID? Is there any way with StoreKit 1 or StoreKit 2 to pass an expected productID to the redemption sheet so Apple only accepts codes eligible for that specific product? Can we intercept or validate the code before payment? Is there any delegate callback or hook when the user taps the "Continue" button on the "Redeem Offer" sheet so we can validate if the code matches the selected plan before the transaction is charged? What is Apple's recommended best practice? If a user redeems a code for a different tier (e.g., Basic instead of Pro), is the recommended approach to automatically switch and activate the redeemed plan on our backend since Apple has already completed the purchase, rather than rejecting it? Any guidance from Apple engineers or developers who have handled this multi-tier scenario would be greatly appreciated!

Hello, I am trying to submit my In-App Purchase subscriptions for review, but App Store Connect is preventing the submission. I have already created: A subscription group ("Piscineiros Pro") Two auto-renewable subscriptions All required metadata and review screenshots When I open the draft submission, I receive the following message: "Unable to Submit for Review. To submit your items for review, add an app version for the selected platform." However, my app version (iOS 4.8.3) already exists in App Store Connect and was previously submitted for review. I would like to understand: Do I need to create a new app version and upload a new binary before I can submit these subscriptions for review? Is it possible to associate the existing subscriptions with the currently rejected app version? What specific steps are required to submit these In-App Purchase products together with my app review? Thank you for your assistance. Best regards, Luiz Maueski

To learn best practices for before and after submitting your app for review, visit App Review Help.

Hello, I would like to clarify the exact technical behavior of the App Store Server API (V2) and StoreKit under the following two specific scenarios: Case A (Production Account on Sandbox Endpoint): If a user with a production Apple Account attempts to purchase through a build pointing to the Apple Sandbox environment (or Sandbox API), how does the Apple server handle this transaction and its data lifecycle? (Does StoreKit block this at the client-side, or does the API return a specific error code?) Case B (Restoring Cleared Sandbox Data): If a Sandbox tester's purchase history is cleared/deleted on the Apple server, and the app subsequently requests a "Restore Purchase" or queries the App Store Server API using a previously valid transactionID from that account, what specific error code (such as 4040010 TransactionNotFound) or empty response does the Apple server return? I would highly appreciate your confirmation or any technical insights on these behaviors. Thank you!

Feedback: FB25016556 (includes sysdiagnose and device log archives) Since our Apple Developer Program membership lapsed on Sep 26, 2026 (renewed Sep 27), Product.products(for:) returns an empty array for every In-App Purchase of our app, in both production and sandbox. No error is thrown. Customers can't subscribe. App: bundle ID com.thefuntasty.gastromapa, live version 2.2.1 (worked fine until Sep 26, no code changes since). Products (both Approved, available in all countries, priced, localized): com.thefuntasty.gastromapa.subscription.premium (auto-renewable) com.thefuntasty.gastromapa.donation (non-consumable) Verified against TN3186 / TN3188: Membership active, latest Program License Agreement accepted (Account Holder checked) Paid Apps Agreement Active (effective Sep 29, 2026), nothing left to sign Bank account and tax forms Active Product IDs and bundle ID match the app record, In-App Purchase capability enabled on the explicit App ID Sandbox test build signed with a freshly regenerated development profile Apple Developer Support (phone) confirmed account, agreements and products look correct and referred us here storekitd log, identical in production and sandbox: Requesting Media API product batch ["com.thefuntasty.gastromapa.subscription.premium"] ... response_status=200 Media request MediaAPIProductRequest correlation key: KKP646ABIQJTWR5GGC3UBLBJDU Ignoring empty product response Correlation keys: Oct 1, 2026, 14:15 CEST, production, iOS 27.0.1 (24A446): KKP646ABIQJTWR5GGC3UBLBJDU Sep 30, 2026, 15:30 CEST, production, iOS 27.0: 3VRU2QHLFRRMP2UBTYG4ZSIBPQ Sep 30, 2026, 15:45 and 15:51 CEST, sandbox: VF6Y3XNFTZXPBRKX6VCKSJNB3U, V7Q3K5JTJ46PB6D2HGKCY5RINU This looks similar to https://developer.apple.com/forums/thread/845526. Could someone from Apple check whether our In-App Purchases were deactivated in the store catalogue when the agreement expired, and reactivate them? It's blocking all revenue for the app.

Hello, We are troubleshooting product discovery for three consumable In-App Purchases in our first iOS game, ION RUSH. All three remain unavailable in TestFlight. Environment and result: Physical iPhone 13, iOS 27.0.1 (24A446). App version 1.0 (80), installed through TestFlight. Direct native StoreKit 2; no RevenueCat or other purchase SDK. Product.products(for:) returns zero products before application filtering, without throwing an error. Earlier independent development-build diagnostics also returned zero products for batch and individual StoreKit 2 requests; SKProductsRequest reported all three identifiers as invalid. Checks completed: Product IDs exactly match App Store Connect: nova_pack_5, nova_pack_15, nova_pack_40. The explicit bundle identifier matches the app record and code; In-App Purchase is enabled for the App ID. All three consumables show Ready for Review, have prices and localizations, and are available in all 175 configured territories, including the US. Developer membership, Paid Apps Agreement, bank account and tax forms are active. The Account Holder checked the Developer account for outstanding agreement signatures; none were visible. The Developer Program agreement was accepted September 29. Tax forms were submitted October 3 and now show Active. The financial setup was only recently completed, so delayed activation remains a possibility. The release scheme has no local StoreKit Configuration override. TestFlight reinstallation, device restart and repeated product refreshes did not restore the products. A re-export of the exact build 80 archive with the original App Store Connect signing settings selected an explicit App Store profile with beta-reports-active=true and get-task-allow=false. This checks the signing configuration; the original uploaded IPA was not available for direct inspection. Selected storekitd messages from October 4, 2026 (UTC+3): 09:59:22.963356 Requesting Media API product batch ["nova_pack_15", "nova_pack_40", "nova_pack_5"] 09:59:22.990339 summary for task success {transaction_duration_ms=1, response_status=200, cache_hit=true} 09:59:22.991595 Ignoring empty product response The request targets amp-api.sandbox.apple.com/v1/catalog/us/in-app-purchasables with the correct bundle and product IDs. Its account mediaType is com.apple.AppleMediaServices.accountmediatype.appstore.beta. A second request one second later produced the same HTTP status, cache flag and empty-product message. We did not capture the raw HTTP response body. Local StoreKit configuration tests work, but we understand this does not validate the live Sandbox catalog. We also understand that prior IAP review approval is not required for Sandbox testing. Questions: What additional developer-side check would distinguish incomplete account activation, product configuration or cached catalog state in this situation? Has anyone resolved this after completing agreements/banking/tax, especially when the products were created before financial activation? What exact action or elapsed time resolved it? If all TN3186 checks pass, what evidence and official escalation route should we use to request investigation of the app-to-product catalog association? Related reports: https://developer.apple.com/forums/thread/849165 (same storekitd messages, but after membership lapse/renewal; our situation differs) https://developer.apple.com/forums/thread/844545 (zero StoreKit 2 products and invalid StoreKit 1 identifiers after TN3186 checks) We can provide further redacted diagnostics and account details privately to Apple. Thank you.

Hi everyone, I'm a new iOS developer, and my first app has been rejected twice because of In-App Purchase issues. Setup: Flutter, in_app_purchase 3.3.0, in_app_purchase_storekit 0.4.10 (StoreKit 1) One auto-renewable subscription and one non-consumable lifetime purchase Both products show "Ready for Review" in App Store Connect. Paid Apps Agreement is active. First review: The prices were visible on an iPad, but the subscription purchase failed (Guideline 2.1(b)). Second review: Neither product showed a price on an iPhone (Guideline 2.1(b)). Apple also noted missing subscription information (Guideline 3.1.2(c)). On my iPhone 15, both products load correctly and test purchases work in TestFlight using my regular Apple Account. Product IDs, pricing, availability, and localizations appear correct. My question: What could cause queryProductDetails / SKProductsRequest to return no products during App Review when everything works in TestFlight? Any suggestions would be greatly appreciated. Thanks! :)

Hey, we're stuck in a loop and need help from App Review. App: Latent: Focus Camera (Apple ID 6788947658) Submission: 302fb800-e336-4f51-afef-6bdffdc59320, version 1.0.1 (30) Latent is free. Build 30 has no in-app purchases, no paywall, and no purchase code. We keep getting rejected under 2.1(b) because the reviewer can't find "Latent Pro Yearly" (6813310670) and "Latent Pro Monthly" (6813311816) in the binary. That's correct, they aren't in it. They're leftovers from before we went free. The rejection says to remove them from App Store Connect. We can't: They were never approved. Both show Developer Rejected, with 0 territories, and they aren't part of the submission. There's no Delete button in App Store Connect. DELETE /v1/subscriptions/{id} returns 409 SUBSCRIPTION_DELETE_NOT_ALLOWED. The subscription group can't be deleted while those two are in it. We replied in Resolution Center on Sept 29 and resubmitted. Can someone remove these two subscriptions on your side, or let the reviewer know they aren't part of this version? Thanks, Malcolm

We just got a rejection on our VoIP calling app (think Boss Revolution / Rebtel style/Yolla — prepaid credits, app-to-app calls free, calls to real landline/mobile numbers charged per minute). Apple's rejection (Guideline 3.1.1.1): "We noticed that the app includes or accesses paid digital content, services, or functionality by means other than In-App Purchase... The credits for VoIP calls can be purchased in the app using payment mechanisms other than In-App Purchase... The app includes intermediary currencies, such as points, coins, or gems, without using In-App Purchase." Our current setup: Users buy "credits" (shown in real USD, e.g. $10 = stored balance) Credits are spent calling real phone numbers (landline/mobile) over standard internet data (SIP/WebRTC) — not the device's native cellular dialer Payment was happening in an in-app webview (likely the actual issue) rather than opening external Safari Questions: Has anyone successfully shipped a prepaid VoIP/calling-credit app using ONLY external browser links (Safari, not webview) under the post-May-2025 US storefront ruling (3.1.1/3.1.1(a))? Or does Apple still reject "stored balance" models even with proper external links? Does anyone know HOW Rebtel, Boss Revolution, Dingtone, or similar apps are technically structured to avoid this? Is it because they trigger the native cellular dialer for the local access number leg of the call (qualifying under a different guideline) rather than using pure data/SIP the whole way through? Is "intermediary currency" purely about NAMING (coins/points) or does ANY stored prepaid balance — even shown in real currency — count, regardless of payment method used to acquire it? Does 3.1.3(f) ("Free Stand-alone Apps" for VoIP) actually prohibit ANY in-app call-to-action for purchase (even an external link), forcing us to have NO purchase flow in the app at all, with credits only purchasable via a fully separate website experience the user finds on their own? Has anyone gotten clarity from Apple directly (App Review Board call, or written response) on where VoIP termination minutes fall — "real-world service" (3.1.3 exception) vs "digital content consumed in-app" (requires IAP)? Any war stories, links to Apple's actual decisions, or technical breakdowns would be hugely appreciated. We're a small Canadian startup and don't want to burn anot

Hello, Our first app submission has been in "Waiting for Review" since September 26, 2026 (5 days now). The submission includes the first app version, our first subscription group with 4 auto-renewable subscriptions, and 3 consumable in-app purchases. We have already contacted App Review through the Contact Us form (Case ID: 102980881885). The demo account in the Review Notes is ready and active. Is there anything we can do from our side to help the review move forward? Thank you.

Hi everyone, I’m stuck with some auto-renewable subscriptions in App Store Connect. I can’t submit them for review, remove them from the submission, or get them out of the “Ready for Review” state. I’m hoping someone has experienced this before. Here’s what happened: I submitted a new app with 4 auto-renewable subscriptions. The app was rejected because 2 of the subscriptions were not being used in the app. I removed those 2 subscriptions from the submission and submitted the app again. The app was eventually approved by Apple. However, I now have the following problem: The 2 subscriptions that were submitted and approved are showing an “Accepted” status instead of “Approved”, so they are not available in my app. The other 2 subscriptions that I removed from the submission are now stuck in “Ready for Review”. I cannot submit those subscriptions for review. I also tried creating new subscriptions, but I ran into the same issue. When I try to add them to the submission, App Store Connect shows this error: "There are errors with one or more of your items. To fix them, you need to remove the items and add them again to your submission." After that, the new subscriptions also become stuck in :Ready for Review", and the "Add for Review" button is disabled. At this point, I have no way to submit the subscriptions for review, which means I cannot get In-App Purchases working in my app. It seems like something may be wrong on the App Store Connect side. Has anyone experienced this issue before? If so, is there a workaround or anything I can do to resolve it? And if there is an Apple engineer or App Store Connect specialist here, I would really appreciate any help. Thanks!

App Store Server API: Sandbox returns 200, Production returns 401 with the same JWT We are seeing a reproducible authentication issue with the App Store Server API for our app FYRT. Bundle ID: com.fyrt.Fyrt We performed a fresh read-only test on September 29, 2026 using our In-App Purchase key BJ5HR5GSY6. Both requests used: the same In-App Purchase key the same Issuer ID the same Bundle ID ES256 the same JWT structure 300-second token lifetime correct system time with no relevant clock skew Only the environment changed. Sandbox: HTTP 200 Apple Request ID: 458b3b32-8e0d-1404-19fe-6c92ba2ccd27 Production: HTTP 401 Apple Request ID: 193406ac-80d2-d135-8cc8-34e4ebe76fc5 The Production response does not include an additional Apple error code. The request is read-only and requests notification history. No purchase is triggered and no Production data is changed. We verified: correct Key ID correct Issuer ID correct Bundle ID ES256 signing current iat valid exp correct Sandbox and Production endpoints no environment mixing fresh JWT generation for each request no clock skew The same behavior was already reproduced on September 11, 2026. Our existing Apple Support case is: 102960057430 Has anyone seen Sandbox accept the same authentication while Production returns 401? Could this be related to Production-side provisioning, app status, team/account authorization, or the fact that the app has not yet had a version released on the App Store? Any guidance from Apple engineers would be greatly appreciated.

For an In-App Purchase made by a customer whose App Store account is in the Saudi Arabia storefront, where Apple acts as commissionaire and remits VAT, does Apple issue the customer any tax document (a VAT invoice or a tax receipt), or is the customer's purchase history the only record available? Apple's support article 'View your purchase history for the App Store and other Apple media services' (support.apple.com/en-us/118212) documents viewing purchase history only — the words 'receipt', 'invoice' and 'tax' do not appear on that page.

Does App Review accept multiple In-App Purchases in the same app sharing an identical display name (for example ten non-renewing subscriptions all named 'Example Digital', differing only in price and duration)? The purchase sheet always shows the price alongside the name. App Store Connect Help documents a 2–30 character limit for the display name but states no uniqueness rule.

Can an In-App Purchase that has reached the 'Approved' state ever be deleted from App Store Connect, either in the UI or through the App Store Connect API? App Store Connect Help documents no deletion procedure and no 'deleted' status. If deletion is possible, is it blocked while the product has existing purchases, or while it is still available for sale?