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 Apple team, We would like to access the user's available purchases from the keyboard extension. Making purchases directly from the keyboard is a great benefit, but we assume it is intentionally disabled to prevent abuse or fraudulent purchase attempts. What we care about the most is determining if the user has an item that contains a discount or a free trial to personalize messaging when we suggest the user go to the app and make a purchase. We hope you'd consider revising your policy around StoreKit usage.

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.

One of our apps has 85% stuck in Billing Retry -- We are so confused. All the users are from the US, and have a one-week free trial. We had 1,000 subscriptions expire from this issue. So any help would be so appreciated.

Hello Apple Developer Community, We are currently facing an authentication issue when calling the App Store Server API for subscription validation. Despite following Apple’s documentation and verifying all credentials, we consistently receive a NOT_AUTHORIZED error response. GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/transactions/appTransactions/{transactionId} Environment: Sandbox and Production (both tested, same result) Our Setup: Key ID: {Your Key ID} Issuer ID: {Your Issuer ID} Bundle ID: {Your Bundle ID} JWT Header: { "alg": "ES256", "kid": "" } JWT Payload: { "iss": "", "iat": , "exp": <timestamp + 5 minutes>, "aud": "appstoreconnect-v1", "bid": "" } Authorization Header: Authorization: Bearer Troubleshooting Steps Already Taken: Verified that .p8 key, Key ID, Issuer ID, and Bundle ID are all correctly configured and match the App Store Connect details. Confirmed that the system clock is accurate (UTC). Used appropriate endpoint (sandbox or production) based on environment. Ensured that the JWT is short-lived (under 5 minutes). Added the “Bearer” prefix correctly in the header. Tested JWT generations using Python. Issue: All requests return: { "errorCode": "NOT_AUTHORIZED" } Questions: Are there any additional claims or headers required for the subscriptions endpoint? Are there specific permissions or roles needed for the API key in App Store Connect? Is there a way to get more detailed logs or diagnostics for this NOT_AUTHORIZED response? Does the App Store Server API require a different aud or bid structure for certain endpoints? We already contacted Apple Developer Support, but they suggested posting here for engineering-level guidance. Any insight or examples of a working JWT + request for this endpoint would be greatly appreciated.

Hello everyone I'm implementing age verification in my app to comply with upcoming age assurance laws (Utah, etc.), and I'm using AppStore.ageRatingCode from StoreKit to retrieve my app's current age rating. According to the documentation: extension AppStore { @available(iOS 26.2, macOS 26.2, tvOS 26.2, watchOS 26.2, *) public static var ageRatingCode: Int? { get async } } "Use this property to fetch the age rating for your app and compare it with the last known age rating to check if it has changed." However, calling this always returns 0 in my environment. Environment: Device: Real physical device (not simulator) iOS version: 26.4 Sandbox Apple Account: signed in via Settings → Developer → Sandbox Apple Account App Store Connect: app is registered and age rating is configured Xcode Scheme → Run → Options → StoreKit Configuration: None Code: func getAgeRatingCode() async -> Int? { guard let ageRatingCode = await AppStore.ageRatingCode else { print("Age rating code unavailable") return nil } print("ageRatingCode: \(ageRatingCode)") // always prints 0 return ageRatingCode } Questions: What integer values does ageRatingCode map to? (e.g., does 4+ = 4, 9+ = 9, 13+ = 13, etc.? Or is it a different internal code?) This mapping is not documented anywhere I can find. Is 0 a valid return value, and if so, what does it represent? Is there a known issue with this API returning 0 even when all conditions appear to be correctly configured? Any guidance from Apple engineers or developers who have successfully used this API would be greatly appreciated.

Hello, I’m having an issue with my first subscription for my app WealthSlices, where the subscription appears correctly when testing locally from Xcode, but App Store reviewers appear unable to retrieve the product. Symptoms When I run the app from Xcode on my iPhone using the Sandbox environment: The subscription loads successfully. The purchase sheet appears. I can complete a sandbox purchase. However, when App Review tests the app, the paywall fails to load products and the app shows the following message: "No Products found. Purchases are temporarily unavailable on this device." Environment App: WealthSlices Platform: iOS Testing locally via Xcode → Sandbox Apple ID Subscription type: Auto-renewable subscription Product: WealthSlices Basic ($9.99/month) StoreKit: StoreKit 2 Current build: 1.0.7 (Build 32) What works locally When running via Xcode: StoreKit successfully fetches products. The subscription sheet appears with the correct pricing. Sandbox purchase flow completes normally. What appears to happen during App Review It appears that Product.products(for:) returns an empty list when the reviewers test the app. Things I have already verified The subscription is created in App Store Connect. It is attached to the current app version under In-App Purchases and Subscriptions. The subscription has pricing and localization configured. The subscription is in Ready to Submit status. The bundle ID and product ID match the code. Paid Apps Agreement is active. I uploaded a new build after creating the subscription. Question Is there something specific required for first-time subscription submissions that might cause the product not to appear during App Review but still work in local sandbox testing? Is there a known delay or propagation requirement for subscriptions before they can be fetched by Product.products(for:) in TestFlight/App Review environments? Any guidance would be greatly appreciated. also there doesn't seem to be an option to select the subscription over at https://appstoreconnect.apple.com/apps/6754225986/distribution/ios/version/inflight but there is no option to add 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.

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, 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!

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

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.

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.

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! 🚀

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.