Hello everyone, I'm facing a very frustrating situation with App Review for my indie app, CoffeePomodoro, and I'm hoping someone here or an Apple engineer can help shed some light on how to escalate and resolve this. My recent update (Version 1.3.1, Submission ID: 59763b52-7c14-4b27-a2cf-2799d2bafe35) was rejected under Guideline 3.1.1 - In-App Purchase. The rejection message states: "We found that the app includes a feature to restore previously purchased In-App Purchase products by entering the user's Apple Account and password. However, In-App Purchases cannot be restored in this manner." The Reality: There is absolutely zero custom UI, form, or TextField in my app that asks for an Apple ID or password. When a user taps "Restore Purchases", the app simply calls Purchases.shared.restorePurchases() via the RevenueCat SDK, which directly wraps Apple's native SKPaymentQueue.restoreCompletedTransactions(). The credential prompt the reviewer saw is the native iOS system-level authentication dialog that appears automatically in the sandbox/TestFlight environment. This usually happens if the device or simulator being used for the review doesn't have an active Sandbox Apple ID already logged in. I have explained this in the App Store Connect Resolution Center. I provided screen recordings showing it's the system dialog, and I attached code snippets proving the app only calls native APIs. Unfortunately, my explanations seem to be ignored, and I keep facing the same roadblock. It feels like the reviewers are mistaking their own OS's native prompt for a custom credential-harvesting screen. Meanwhile, my users are waiting for this update to resolve their subscription issues, and I am stuck in a rejection loop for using Apple's own native API exactly as intended. Has anyone else experienced this specific misunderstanding by the review team? How can I escalate this so someone actually reviews the screen recording and code snippets I provided? Thank you for your time.

Hello, My Paid Apps Agreement has been stuck in "In Process" status since May 16, 2026 — now 9 days with no resolution. I have received no emails from Apple regarding this The agreement has not been rejected The system does not allow me to make any edits I have contacted Apple Developer Support twice with no real response

Hello, I am experiencing an App Store Connect issue where my In-App Purchases are not attaching to the app review submission. Current situation: The IAP products are fully configured. Status is currently "Waiting for Review". Product IDs match the app code correctly. Sandbox testing works correctly. However, the app version page does not display the "In-App Purchases and Subscriptions" section at all. App Review repeatedly responds that they cannot locate the IAPs during review. It appears the IAP submission linkage between the binary and App Store Connect may be corrupted or missing. App: Phantom Spy I would appreciate any guidance or escalation assistance. Thank you.

I'm hoping someone from the App Review team can help. My App ID: 6743341470 is Ready for Distribution, but both auto-renewable subscriptions have been stuck in "In Review" since May 10 with no update. Subscriptions: Subscription Group ID: 22039292 Account status: Paid Apps Agreement: Active Banking and tax: Complete Localization: Approved (Since 11 May) Resolution Center: No outstanding items What I've tried: Apple Developer Support case 20000114086909 — escalated thrice, support confirmed nothing is concerning but no movement. All they said was wait with no definite timeline. This is my first app and these subscriptions are blocking my launch. Any help from the App Review team would be greatly appreciated.

Hello, I am trying to ship the first auto-renewable subscription for my iOS app and I am facing what seems to be a workflow / availability issue involving App Store Connect and TestFlight. Product ID: seka_premium_yearly_ Current situation: The subscription exists in App Store Connect. Its status remains “Waiting for Review”. The subscription page says that the first subscription must be submitted with a new app version and attached through the “In-App Purchases and Subscriptions” section on the app version page. 4. However, this section does not appear on my iOS app version page in App Store Connect. 5. In TestFlight, when tapping “Subscribe”, the app shows: “The offer is not available yet. Please try again in a moment.” Additional context: Paid Apps Agreement is active The app uses expo-iap The product ID configured in the app is seka_premium_yearly_ We are not restricting access by storefront, region, or device configuration Sandbox testing has been attempted, but the issue remains reproducible in TestFlight Question: Is it expected that the subscription is unavailable in TestFlight while the first subscription is still in “Waiting for Review”? Does the missing “In-App Purchases and Subscriptions” section on the app version page indicate an App Store Connect issue? Has anyone encountered this specific first-subscription workflow problem? Any guidance would be appreciated.

I'm hoping someone from the App Review team can help. My App ID: 6743341470 is Ready for Distribution, but both auto-renewable subscriptions have been stuck in "In Review" since May 10 with no update. Subscriptions: Subscription Group ID: 22039292 Account status: Paid Apps Agreement: Active Banking and tax: Complete Localization: Approved Resolution Center: No outstanding items What I've tried: Expedited review request submitted Apple Developer Support case 20000114086909 — escalated thrice, support confirmed nothing is concerning but no movement. All they said was wait with no definite timeline. This is my first app and these subscriptions are blocking my launch. Any help from the App Review team would be greatly appreciated.

My app was rejected based on in app purchase requirement. it is an SaaS with nothing to sell on my part and no subscription payment for the parents who use the app. Some users of my app have the option of collecting cash for their services or set payment plans for parents to pay vial stripe link. Why is apple asking me to set up in-app-purchase.

I'm preparing my first App Store submission and have hit a chain of issues that appear to be backend state problems I can't resolve from the App Store Connect UI. I've already opened a DTS case but wanted to ask here in case anyone has seen this combination before. Setup: iOS app with first-time subscriptions (auto-renewable, 7-day free trial) Two products: bitcoinhq_pro_monthly and bitcoinhq_pro_annual Both in the same subscription group "Bitcoin HQ Pro" Paid Apps Agreement is Active Bundle ID, prices (all 175 territories including United States), intro offers ("Free for the first week" in all territories), localizations all configured Important context: On my own iPad (TestFlight build, signed into my normal sandbox account), the full flow works perfectly — paywall loads on first launch after install, both products show with correct prices, tapping Subscribe opens the StoreKit sheet, purchase completes, the entitlement grants, and Pro features unlock. So the app code and RevenueCat configuration are working. The issues below appear to be App Store Connect backend state problems. The issues, in the order I hit them: bitcoinhq_pro_monthly is stuck in "Developer Action Needed." I cannot identify which field is flagged — all required sections (price, availability, localization, screenshot, review notes, tax category) appear complete. Cannot save edits to the English (U.S.) localization for the monthly subscription. The localization editor returns: "There was an error with editing your App Store localization. Try again later." This has persisted across multiple browsers (Safari, Chrome, incognito), sign-out/sign-in cycles, multiple days, with Apple System Status reporting all services green, and with the description retyped manually rather than pasted. Cannot submit the monthly subscription standalone. Clicking "Submit for Review" returns: "Your subscription cannot be submitted for review. Your first subscription must be submitted with a new app version." The annual subscription is in "Waiting for Review" — saved successfully when first created. The "In-App Purchases and Subscriptions" section is missing from my App Version 1.0 page. Per ASC's own messaging, this is where I'm supposed to attach my first subscriptions before submitting the version. The section is not present anywhere on the version page. Reviewer rejection with "The product is not available for purchase." App Review Guideline 2.1(b). Tapping Subscribe in the reviewer's environment results in this StoreKit error on iPad Air 11" M3 / iPadOS 26.4.2 — but the same build on my own devices completes the purchase without issue. My read: issues 1–4 appear to be a single backend state problem with the monthly product or subscription group. Issue 5 appears to be downstream — sandbox returns the products for fetch but refuses the purchase from the reviewer's clean environment because the product isn't in a properly submittable state. Has anyone seen this combination? Any way to surface the "In-App Purchases and Subscriptions" section, or work around the localization save error? Or is the only path through DTS? Thanks in advance.

Hello everyone, I'm encountering a blocking issue with my first-time Non-Consumable In-App Purchase​ after a rejection. Here is the exact workflow: Initial State: My App and IAP (com.marryflow.app.premium.lifetime) were linked and submitted together for the first time. Rejection: The IAP was rejected, and the App was consequently rejected as well (metadata rejection). Resubmission: I fixed the IAP issues and submitted it again. Its status is now "In Review". The Block: When I uploaded a new binary and went to the App Version page (under the "In-App Purchases" or "Subscriptions" section), the IAP that is "In Review" does not appear in the list. The interface only seems to allow selecting IAPs with "Ready to Submit" status. My Questions: Is this an expected system restriction? Meaning, once a first-time IAP enters a standalone review cycle, it cannot be manually re-attached to an App version? If so, is the correct resolution to ask the App Review team to reset the IAP's status back to "Ready to Submit"​ so that I can select it on the App Version page and submit them together? Currently, my App is submitted (without the IAP attached) and the IAP is stuck in "In Review". Any guidance on the proper workflow would be greatly appreciated. Thank you!

Hi everyone, I am working on an iOS app with a subscription-based model, and I need some clarification regarding App Store Review Guideline. The app allows one account holder to manage access for multiple people under the same account. Each person may need subscription-based access to certain digital features within the app. In this scenario, the subscription requirement is not limited to a single user under one Apple ID. The account holder may add multiple members/dependents, and access may vary based on the subscription status associated with those people. My question is: If the subscription is managed through our backend and the app locks or unlocks digital features based on that subscription status, would Apple consider this a violation for not using In-App Purchase? I would like to understand whether Apple expects In-App Purchase to be implemented in this type of multi-person subscription model, even when the subscription is managed at the account/member level rather than as a simple single-user plan. Any guidance or experience with similar review scenarios would be helpful. Thanks.

I have Subscription and In-app purchases product ids [Waiting in Review status] created on app store , when i send the product ids from the app to store for purchase , its returning sku-not-found code in Sandbox/Testflight envirionment , I tried multiple times the result is same. Please guide me on this

I'm hitting a persistent build/upload failure when trying to submit my first app for review. Hoping someone has seen this specific issue. Setup App: ShiftSelf (an AI-guided self-coaching app) Bundle ID: app.shiftself.mobile Apple Developer account: active, paid, fully verified (Switzerland) App Store Connect: app created, Version 1.0 in "Prepare for Submission" Build pipeline: Expo-based (using a hosted Expo build service for the IPA upload) The error Every upload attempt fails with: exportArchive Error: Downloading App Information This has now occurred 14 times over the past 5 days, with no configuration changes between attempts. What is already configured correctly Two auto-renewable subscriptions (Monthly $9.99, Annual $59.99) — both in "Ready to Submit" state Subscription Group with English localization ("ShiftSelf Pro") created Both subscriptions attached to Version 1.0 under In-App Purchases and Subscriptions Privacy Policy URL, Terms URL, and Account Deletion URL all live and reachable DSA verified, Banking and Tax information active App icon, screenshots, and metadata all uploaded Age rating questionnaire completed (4+) App Privacy answers fully submitted No pending agreements in Account → Agreements, Tax, and Banking What I have already tried Recreated the subscription group localization Detached and reattached subscriptions to the version Multiple rebuild attempts at different times of day and across multiple days Verified all metadata fields are filled Apple Support engagement Currently working with Apple Developer Support (Case #102880953484). Guidance so far: Subscriptions must be "Ready to Submit" → done Subscriptions must be attached to the version → done Both confirmed. Builds still fail with the same error. Questions for the community Has anyone else seen "exportArchive Error: Downloading App Information" specifically during the metadata fetch step of an automated upload? Is there a known App Store Connect API issue that causes the metadata download to fail silently for first submissions? Would uploading the IPA manually via Apple Transporter bypass this step entirely, or does Transporter rely on the same metadata fetch? Is there any way to get more verbose logs on what specific "App Information" the export step is attempting to download? Any pointers from anyone who has hit this would be hugely appreciated. Happy to share more details if useful. Thanks 🙏

I am aware of the following in the App Review Guidelines; 3.1.1 If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc. The app itself operates normally, but imposes limits after a limited time of use. Purchasing the full version removes these limits. This is a one-time IAP, not a subscription. My app is aimed at professionals within the entertainment industry, and will only ever be used within a theatre or other similar venue. I do not intend to provide any other paid route to the full version than via the App Store. However, what I would like to do is provide free use at certain events and to students in their educational venues (e.g. college theatres etc)- is it acceptable to use an external mechanism (e.g. a server based API) to temporarily remove the limitations whilst in that venue? Or, likewise, provide an extension to the free trial period for specific uses. Note this is not a purchase, as there is no payment. Therefore there is no revenue outside of the App Store (which surely is the point of the mandate to use IAP for this purpose) Also, it's not fully 'unlocking' the app (the user doesn't get the full version, they just aren't bound by the trial limit timer when within that venue or for a limited time) I'm aware that another route would be to put a different version of the app in the store that requires a username and password for use (for example) and then provide those credentials to log in - as there's lots of apps that follow that model, but it seems clunky to require the user to download a different app.

Hi all, I've been observing what appears to be a timing mismatch in how Apple handles Korea trial-to-paid consent, and I wanted to see if other developers are seeing the same thing. Per Korean regulations effective Feb 14, 2025, Apple must obtain explicit user consent before converting a free trial to a paid subscription. Apple handles this via email, push notifications, and an in-app consent option accessible from Settings > Subscriptions. For a 7-day trial in the Republic of Korea storefront, I'm observing: Consent push notifications (Agree to continue your subscription without interruption) start arriving ~1 day after trial redemption, at roughly hourly frequency. However, when the user taps the push and navigates to Settings > Subscriptions, there is no consent option available. The only visible action is "Cancel Free Trial". The consent option only becomes available around day 4 of the trial (i.e., 3 days before renewal, matching Apple's documented messaging cadence [1]). For the first ~3 days, users receive hourly push notifications they cannot act on. The only way to stop them is to cancel the subscription entirely. This is happening across multiple apps in the Korean App Store, so it appears to be a platform-level behavior rather than an app-specific issue. Is anyone else observing this behavior? Any insight from Apple engineers or other developers would be greatly appreciated. [1] https://developer.apple.com/help/app-store-connect/reference/in-app-purchases-and-subscriptions/consent-for-subscription-offer-conversions

Our live production app Padel Club Pro (Apple ID 6763061435, Bundle ID com.padelclubpro.app) has been blocked from all new installs since launch due to StoreKit incorrectly displaying our auto-renewable subscription as a "One-time charge" on the App Store install sheet. The issue: Tapping the install button on the App Store opens the StoreKit purchase confirmation sheet showing "R499.99 / One-time charge" instead of presenting the app as a free download with the subscription available in-app. The app's base price is set to Free in App Store Connect. The subscription is approved and configured correctly as auto-renewable. Subscription details: Product ID: com.padelclubpro.app.monthly Status: Approved Subscription Duration: 1 month Introductory Offer: Free for the first week (active across 175 countries) What I've verified: App base price is set to Free Paid Applications Agreement is fully signed and active (tax forms, banking complete) No phantom non-consumable IAPs exist (In-App Purchases section is empty) RevenueCat App-Specific Shared Secret is set correctly RevenueCat product mapping correctly points $rc_monthly to the subscription product Reproduced on multiple physical devices using multiple different Apple IDs (none had previously interacted with the app) Issue has persisted for 6+ days, ruling out CDN propagation delay Apple Support case: Filed case 102883643138 six days ago — only received automated confirmation, no response since despite two follow-up emails. Suspected cause: The auto-renewable subscription appears to be approved as a standalone product but is not properly bound to the live build/version on Apple's StoreKit servers, causing StoreKit to fall back to a default "One-time charge" display. Question: Has anyone encountered this before? Is there a known fix on the developer side, or does this require Apple engineering to re-bind the subscription server-side? Any guidance on how to escalate the support case would be appreciated — this is a critical production-blocking issue and we have not been able to acquire a single user since launch. Thank you in advance.

Hello, I have an app on the App Store that offers in-app purchases (consumable, non-consumable) and auto-renewable subscriptions. My goal is to verify the validity of purchase receipts on my own backend server, to prevent fraudulent transactions. My questions: Does Apple provide an API that allows my server to validate a receipt (the one generated after a purchase) and confirm whether it is genuine? For auto-renewable subscriptions, can I retrieve renewal dates, expiration dates, and current renewal status using that same API? From reading the documentation, I understand that Apple provides the App Store Server API and the App Store Server Notifications. Is this the correct approach for receipt validation and subscription status checking? Any clarification or code example would be greatly appreciated. Thank you.

I'm trying to distribute one-time use offer codes for a non-consumable IAP, but every redemption attempt fails at the App Store with the error: Unable to Purchase This promotional offer is not available. My setup: the app is in Ready for Distribution state, the IAP is Non-Consumable and Approved, and the offer is a Free one-time use offer available in all 175 territories. I generated a batch of 500 production codes which are active and were created more than 24 hours ago. I've already ruled out the usual suspects: the app is installed from the public App Store (not TestFlight), the test Apple IDs have never purchased this IAP before, the storefront is included in the offer's territories, and the IAP works correctly when purchased at regular price. The error reproduces across multiple users, devices, and Apple IDs, and each failing code is still unredeemed. Has anyone successfully shipped non-consumable offer codes since the October 2025 rollout? Thanks!

Dear all, This is my first post in this forum - and, in fact, my first app, too! I'm glad to be here, and thanks in advance for your help. I'm looking to offer an app for a one-time payment. I'd also like people to be able to try the app for a week. It seems that the "Pricing and Availability" section in App Store Connect is not the right place to configure this kind of offer. It does allow me to set a one-time price, but I cannot find a trial-period there (or am I missing something?) Two different strategies seem possible here: Using in-app-purchases: make the actual app free, but ask users after a week to buy a non-consumable IAP. The problem with that: I need to verify that the app has been installed for seven days ... even if it has been uninstalled at some point. Using subscriptions: There is a "free trial" option for subscriptions. But after that free trial, subscriptions are being payed periodically. I'd rather have the user only pay once for lifetime-access. Some apps seem to use strategy 1 - I believe the "Lap swim" app does. But still it seems like a bit of a hack - is there a more elegant way to achieve this?

Hello Apple Developer Support / StoreKit Team, We recently observed a behavior regarding the appAccountToken in App Store Server Notifications v2 that seems to completely contradict the official documentation. According to the Set App Account Token documentation: The same appAccountToken continues to apply to renewal transactions if the customer upgrades, downgrades, or cross-grades the subscription. However, we encountered a scenario where an active in-app crossgrade resulted in an updated/overwritten appAccountToken inside the subsequent JWSRenewalInfoDecodedPayload, despite our backend never calling the Set App Account Token REST API. Our Observation: A user subscribes to our 1-month plan (Product A). Apple generates an originalTransactionId bound to their initial appAccountToken (Token A). Later, a crossgrade to a 1-year plan (Product B) is initiated from within the app while the user is logged into a different account in our system (Token B), but using the same underlying Apple ID on the device. When the crossgrade takes effect at the next renewal date, we receive a DID_RENEW webhook. The Anomaly (See Attached Screenshots): Upon decoding the JWSRenewalInfoDecodedPayload from the webhook, we noticed that the appAccountToken had unexpectedly changed to the new token (Token B). As shown in the attached redacted screenshots: Screenshot 1 (Before/Original): JWSRenewalInfoDecodedPayload for Product 00001 shows the appAccountToken ending in ...e9a. Screenshot 2 (After Crossgrade): JWSRenewalInfoDecodedPayload for Product yearly_saver shows the appAccountToken has mutated to ending in ...507, even though the originalTransactionId remains exactly the same. To reiterate, our server did not call the POST /inApps/v1/subscriptions/appAccountToken/{originalTransactionId} endpoint to manually overwrite this token at any point. Our Questions: Is this the intended StoreKit 2 behavior? Does Apple automatically overwrite the base appAccountToken in the RenewalInfo if a new token is somehow associated during an active in-app crossgrade transaction? If this is intended, could the documentation be clarified? The current phrasing strongly suggests the token is permanently locked to the initial purchase and will never change during crossgrades unless the REST API is explicitly called. While this behavior is actually quite helpful for our backend to track multi-account users, we want to ensure we aren't relying on an undocumented bug that might be patched unexpectedly. Any insights from the StoreKit engineering team would be highly appreciated. Thank you!

I’m trying to manage pricing for auto-renewable subscriptions using the App Store Connect API (JWT). For In-App Purchases (non-consumable / consumable), I can: list price points set pricing using pricePointId However, for subscriptions: I can create subscription groups and subscriptions but I cannot find a clear way to: read current pricing (e.g. US price) set pricing via API I also tried using the asc-cli tool (v0.17.2), but it does not expose subscription pricing commands. Questions: Is subscription pricing accessible via the App Store Connect API? If yes, which endpoint should be used? If not, is this intentionally limited compared to IAP pricing? Any guidance or examples would be very helpful.