Hello, I am blocked on the first auto-renewable subscription submission for my iOS app and I would like to know if anyone has seen this exact App Store Connect behavior. App: SEKA Money Subscription product ID: seka_premium_yearly_ Subscription Apple ID: 6760082026 Current issue: the auto-renewable subscription exists in App Store Connect I am on the correct iOS app version page the “In-App Purchases and Subscriptions” section is visible but my auto-renewable subscription does not appear in the selector only a consumable IAP appears there Important detail: the issue happens directly inside App Store Connect on the app version page this is why I do not think the missing subscription in that selector is caused by the runtime StoreKit code in the app itself I understand app code can affect UI price display, but it should not control whether a subscription appears in the App Store Connect submission selector Other details: this is my first subscription the subscription has already gone through “Waiting for Review” and is now “Developer Action Needed” metadata, screenshot, and localizations have been filled Apple Support already confirmed that I do not need a consumable for this case sandbox / TestFlight purchase behavior has been partially reproducible, but the submission workflow remains blocked because the subscription is not selectable on the app version page My question: Has anyone seen a case where the first auto-renewable subscription exists but does not appear in the app version selector, while another IAP type does appear? If yes, what was the real cause and how did you resolve it? Thank you.

Hi everyone, My app has been rejected twice under Guideline 2.1(b) - App Completeness because the reviewer says the In-App Purchase does not trigger a purchase flow when tapping the purchase button. However, I have tested it on a physical iPhone (iOS 18.6.2) and the StoreKit purchase dialog appears and completes successfully. I have confirmed: Paid Apps Agreement is active In-App Purchase product (non-consumable) is configured correctly Sandbox test account works fine Purchase flow works on physical device with screen recording as proof The reviewer tested on iPad Air 11-inch (M3) with iPadOS 26.4. My app uses Flutter with the in_app_purchase package (v3.2.0). The purchase implementation: Calls InAppPurchase.instance.isAvailable() Queries product details with queryProductDetails() Calls buyNonConsumable() when user taps purchase button I found and fixed a potential null reference issue in the purchase completer that could cause the purchase to fail silently, but I'm not sure if this was the exact cause since I cannot reproduce the issue. Has anyone experienced a similar situation where IAP works on device but fails during App Review? Any suggestions on what might be different in the review environment? Thank you.

I’m trying to submit the first release of my iOS app together with the app’s first consumable in-app purchases, and I’m stuck in what looks like an App Store Connect state issue. My app was already rejected by App Review because the in-app purchases did not appear inside the app when the reviewer opened the paywall. Current setup: First app release Current app version page: iOS App Version 1.0.2 Current attached build: 5 App has never been released before 4 consumable IAPs: com.glowup.credits.100 com.glowup.credits.500 com.glowup.credits.1000 com.glowup.credits.2500 What I see in App Store Connect: All 4 IAPs show Waiting for Review On the iOS App Version 1.0.2 page, the In-App Purchases and Subscriptions section does not appear at all Because of that, I cannot explicitly select or attach the IAPs from the version page What I’ve already done: Uploaded a new build and attached build 5 to version 1.0.2 Removed my local StoreKit configuration file so the app now uses live App Store / StoreKit only Confirmed RevenueCat is configured correctly and sees the offering/packages RevenueCat logs show the products exist remotely, but StoreKit cannot fetch any live products and returns an “offerings empty / none of the products could be fetched” type error RevenueCat also reports the products are still in WAITING_FOR_REVIEW My questions: If the IAPs already show Waiting for Review, are they automatically linked to the current app submission? Is it expected that the In-App Purchases and Subscriptions section can disappear from the app version page in this state? For a first-release app that was already rejected, is attaching a new build and clicking Update Review enough, or is there another step required to associate the IAPs with the resubmission? Has anyone seen App Review reject an app for missing IAPs while the IAPs were still pending review and not yet fetchable from StoreKit? Any guidance from someone who has dealt with this exact first-release + first-IAP submission flow would help a lot.

Hi everyone, I’m currently developing an iOS app using React Native and implementing consumable In-App Purchases (IAP). I'm facing an issue where getProducts returns an empty array without any error messages when testing on a TestFlight build. I have already completed the following setup: Agreements, Tax, and Banking: All forms are signed and the status is "Active" in App Store Connect. Product Configuration: The Consumable product is created in App Store Connect with the status "Ready to Submit". App Store Connect Integration: The product is correctly linked under the "In-App Purchases and Subscriptions" section of the App version. Xcode Capability: The "In-App Purchase" capability has been added to the project. Implementation: The Product ID in my React Native code (using react-native-iap) matches the ID in App Store Connect exactly. Despite these steps, the product list remains empty. Are there any hidden requirements or specific configurations for TestFlight that I might have missed? Any guidance would be greatly appreciated. Thanks!

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!

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

Prerequisites We plan to sell non-consumable items via in-app purchases. The app includes a restore button. We understand that after a payment is completed on a smartphone, the server must verify the receipt and activate the item in the database, and the app must then execute the transaction finish process. Due to our app’s constraints, there are specific cases where we must execute the transaction finish process on the app side without first performing the item activation process in the database. We do not know exactly what the transaction finish process entails. Questions What are the implications in the following cases? The payment was completed, but the product activation process in our database failed, and the transaction finish process was not executed on the app side. After restarting the app, an OS notification indicating an incomplete transaction appeared, and only the finish process was executed. In this scenario, we assume that the OS notification will not appear next time, and the user can simply activate the purchase by starting a transaction recovery. Are there any potential concerns or bugs that might occur? What are the implications if the product activation process in our database succeeds, but the finish operation fails to complete normally due to the user exiting the app or similar circumstances? Our assumption is that since the product is activated in our database, we can provide value for the charge without issue, and there is no deterioration in UX, such as the inability to process refunds in the app store. Are there any potential concerns or bugs that might arise? Regarding this inquiry, if you have any information—such as whether this scenario would result in a rejection during the app review process—we would appreciate it if you could share it with us.

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.

how to disable streamline purchasing, when I click turn off, it show error Streamlined purchasing cannot be turned off because your latest approved binary doesn’t include the required StoreKit APIs My app has subscribe button to click before start to use though not need to login, chatgpt had done the store kit and subscription part, do not understand why it can not turn off streamlined purchasing

I have a $4 USD, one-time-purchase app (Dash Calc) and sales have been rough. In a crowded category, an paid-upfront app feels like a tough sell without a way to try it first. I’d like to offer a simple 7-day free trial followed by a single lifetime purchase, but App Store Connect still doesn’t officially support trials for paid apps. In Jan 2023, an App Store Commerce Engineer recommended the $0 non-consumable IAP + paid non-consumable IAP workaround: https://developer.apple.com/forums/thread/722874 I haven’t implemented it yet, but the subsequent discussion suggests the approach is overly complex. Handling refunds, reinstalls, activation timing, and purchase history requires non-obvious logic, and some developers report customer confusion and drop-off when presented with a $0 trial IAP. Has anything improved since 2023? Any new StoreKit APIs or App Store Connect changes that make this simpler or less error-prone? Is the $0 non-consumable IAP still the recommended approach in 2026? Any updated guidance for time-limited access on one-time purchases? I’m happy to use the workaround if it’s still the official path—I just want to confirm there isn’t a better option now.

how to disable streamline purchasing, when I click turn off, it show error Streamlined purchasing cannot be turned off because your latest approved binary doesn’t include the required StoreKit APIs My app has subscribe button to click before start to use though not need to login, chatgpt had done the store kit and subscription part, do not understand why it can not turn off streamlined purchasing

Hello, I got Purchase Error Couldn’t communicate with a helper application. when button 'Buy Pro' clicked in my app it uses storekit subscription created (correct id in configuration.storekit) got this error in console: Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=5115 "Received failure in response from Xcode" UserInfo={NSDebugDescription=Received failure in response from Xcode, NSUnderlyingError=0xc5bc1c510 {Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service created from an endpoint was invalidated from this process." UserInfo={AMSDescription=An unknown error occurred. Please try again., AMSURL=http://localhost:49913/WebObjects/MZBuy.woa/wa/inAppBuy, NSDebugDescription=The connection to service created from an endpoint was invalidated from this process., AMSStatusCode=200, AMSServerPayload={ "app-list" = ( Thx for any help : )

**Environment Platform:** iOS Distribution: TestFlight Product type: Consumable In-App Purchase Account used for testing: Real Apple ID (not Sandbox) StoreKit: StoreKit 1 iOS version: iOS 17+ (also reproduced on earlier versions) Issue Description We are encountering an issue when testing consumable in-app purchases in a TestFlight build using a real Apple ID. Under normal circumstances, consumable products should be purchasable repeatedly. However, in TestFlight, after a successful purchase flow, the same product may become unavailable for repurchase, and the transaction appears to be stuck, even though: • finishTransaction: is correctly called • The transaction state is .purchased • No pending transactions are left in the payment queue Once this happens, subsequent purchase attempts result in behavior similar to a non-consumable product (e.g. “already purchased” or no purchase UI shown).

Environment OS: iOS 26.2 ~ 26.3 SDK: Xcode 16.4 (Target: iOS 17.6) Framework: StoreKit 2 Environment: Production (Cannot reproduce in Sandbox or Xcode Configuration) Issue Description We are encountering a critical purchase failure that occurs exclusively in the Production environment. When a user who has a "Pending Downgrade" (scheduled for the next renewal date) attempts to re-purchase their current higher-tier product to cancel the downgrade, StoreKit 2 returns an error. Steps to Reproduce User is currently on "Product A" (Higher Tier). User schedules a downgrade to "Product B" (Lower Tier). The status changes to "Pending Downgrade". User attempts to purchase "Product A" again via Product.purchase(). The system purchase sheet appears, and the user confirms the purchase. Immediately after authentication, a system alert from StoreKit appears saying: "Cannot process request at this time. Please try again later." (現在リクエストを一時的に処理できません。しばらくしてからもう一度お試しください。) After dismissing the alert, the app receives StoreKitError code 2 (unknown) with the localized message: "Request could not be completed" (リクエストを完了できません). Technical Observations Transaction.currentEntitlements: Does not change. App Store Server Notifications (V2): No notifications are sent to our server. Sandbox Behavior: Works perfectly. Re-purchasing Product A successfully cancels the downgrade and the subscription remains at the Higher Tier. AppStore.sync(): Running a manual sync does not resolve the pending state after the error. Question Since we cannot debug production-level logs, we are stuck. Is this a known regression in the StoreKit 2 commerce engine regarding state synchronization for downgrades? Has anyone found a workaround for this specific scenario? Any insights would be greatly appreciated.

In iOS 26.4 beta 4, the receipt returned by StoreKit payments via [[NSBundle mainBundle] appStoreReceiptURL] corresponds to the previous transaction; the content only becomes correct after restarting the app.

Hello, I am investigating a case where two different transaction IDs appear to refer to the same purchase, and I would like clarification on whether this behavior is expected. Additional context StoreKit version: StoreKit 1 (SKPaymentTransaction) Environment: Production Product type: Auto-renewable subscription Transaction sources The values are obtained from the following APIs: transaction_id from SKPaymentTransaction https://developer.apple.com/documentation/storekit/skpaymentqueue receipt_data from the App Store receipt https://developer.apple.com/documentation/foundation/bundle/appstorereceipturl Observed behavior After an In-App Purchase completes, the app receives: a transaction_id from SKPaymentTransaction the corresponding receipt_data for the purchase When inspecting the receipt, the transaction_id inside latest_receipt_info differs from the transaction_id received directly from the purchase transaction. For clarity: A = transaction_id received from the purchase flow (SKPaymentTransaction) A' = transaction_id found in receipt_data.latest_receipt_info The two values are different, but they differ only by 1. Additional observation The original_transaction_id for A and A' is identical, which suggests that both transaction IDs belong to the same subscription purchase chain. Pattern observation on the ID difference We have observed that the difference between A and A' is consistently exactly 1 (i.e., A' = A + 1) across multiple transactions, not just a single case. This appears to be a reproducible pattern rather than a coincidence. This observation raises an additional question (Question 6 below). API verification When calling: GET /inApps/v1/transactions/{transactionId} Both A and A' return what appears to be the same purchase record. The response data is effectively identical except for the transactionId field. However, when calling: GET /inApps/v2/history/{transactionId} A does not appear in the transaction history only A' appears in the history response Questions If A does not appear in transaction history, where does this transaction ID originate from? Why does Get Transaction Info (/inApps/v1/transactions/{transactionId}) return a valid response for A even though it is not present in the transaction history? Why do A and A' both resolve to what appears to be the same purchase? In this situation, which transaction ID should be treated as the canonical transaction ID for server-side validation? Is this difference related to how StoreKit 1 (SKPaymentTransaction) and the App Store Server API represent transactions? Is the consistent off-by-one difference between the transaction_id from SKPaymentTransaction and the one recorded in latest_receipt_info an intentional behavior of StoreKit 1's internal transaction ID assignment? Specifically, we are wondering whether StoreKit 1 applies some form of internal offset when delivering the transaction ID to the client, while the App Store server records a different (adjacent) ID in the receipt. If so, is this documented anywhere? Note We are currently in the process of migrating to StoreKit 2, but this behavior was observed while investigating our existing StoreKit 1 implementation. Any clarification would help us better understand the correct transaction model during the migration.

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

I just spent way too many hours trying to figure out why my in-app subscription was stuck in “Missing Metadata” in App Store Connect, even though I had filled out everything. If you're here because you're in the same boat, this is the solution Apple doesn't make obvious. The Problem I created an auto-renewable subscription (Kanabloom Premium) and filled in all required fields. The subscription was still marked "Missing Metadata", preventing me from submitting it. The “In-App Purchases” section wasn’t showing up in my App Store version submission, which meant I couldn't even attach the subscription to my app version. I triple-checked the metadata, pricing, tax settings, review screenshot, and even resaved everything, but nothing worked. What I Tried (Before Finding the Fix) Checked that pricing was set up correctly for all countries. Uploaded the required review screenshot for the subscription. Made sure the subscription group existed and was linked properly. Refreshed, logged out/in, and tried different browsers. Read every Stack Overflow, Reddit, and Apple Developer Forum post I could find. Even tried creating a dummy subscription to see if that would reset the system. The Solution: Localizing the Subscription Group Here’s the stupidly hidden requirement that finally fixed it: ✅ Your subscription group itself (not just the subscription) needs a localized display name. App Store Connect requires each subscription group to have at least one localized display name for it to be valid. If this is missing, all subscriptions inside that group will stay stuck in “Missing Metadata” no matter how complete they are. How to Fix It: Go to App Store Connect > Subscriptions > Subscription Group Click on your subscription group (not the individual subscription). Check if there's a localization added under "Group Reference Name." If missing, add a localization (e.g., English) and save. Refresh the page and boom – the subscription will finally be "Ready to Submit." Conclusion Apple really needs to make this requirement clearer. Now that I’ve finally figured it out, hopefully, this post helps someone else avoid losing hours of their life to the same issue. If you're still stuck, double-check that: You’ve set pricing and enabled "Cleared for Sale." You’ve uploaded a review screenshot for the subscription. You’ve signed all App Store agreements and banking/tax documents. Your app's In-App Purchase capability is enabled in Xcode. Let me know if this helped you! I wish I had found a post like this sooner. 😂 This should make for a useful and searchable post in case other devs run into the same headache. Let me know if you want any tweaks before posting! 🚀

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

I have a bunch of Audio Unit v3 plugins that are approaching release, and I was considering using subscription-model pricing, as I have done in a soon to be released iOS app. However, whether this is possible or not is not at all obvious. Specifically: The plugin can, depending on the host app, be loaded in-process or out-of-process - yes, I know, Logic Pro and Garage Band will not load a plug-in in-process anymore, but I am not going to rule that out for other audio apps and force on them the overhead of IPC (I spent two solid weeks deciphering the process to actually make it possible for an AUv3 to run in-process - see this - https://github.com/timboudreau/audio_unit_rust_demo - example with notes) Depending on how it is loaded, the value of Bundle.main.bundleIdentifier will vary. If I use the StoreKit API, will that return product results for my bundle identifier when being called as a library from a foreign application? I would expect it would be a major security hole if random apps could query about purchases of other random apps, so I assume not. Even if I restricted the plugins to running out-of-process, I have to set up the in-app purchases on the app store for the App container's ID, not the extension's ID, and the extension is what run - the outer app that is what you purchase is just a toy demo that exists solely to register the audio unit. I have similar questions with regard to MetricKit, which I would similarly like to use, but which may be running inside some random app. If there were some sort of signed token, or similar mechanism, that could be bundled or acquired by the running plugin extension that could be used to ensure both StoreKit and MetricKit operate under the assumption that purchases and metrics should be accessed as if called from the container app, that would be very helpful. This is the difference between having a one-and-done sales model and something that provides ongoing revenue to maintain these products - I am a one-person shop - if I price these products where they would need to be to pay the bills assuming a single sale per customer ever, the price will be too high for anyone to want to try products from a small vendor they've never heard of. So, being able to do a free trial period and then subscription is the difference between this being a viable business or not.