If an app on the App Store still uses StoreKit 1 (a.k.a. the Original StoreKit) to handle In-App Purchases, would IAPs work for users who download such app on iOS 26.2? Would the app allow the users to purchase an IAP via StoreKit 1 or would it be impossible to buy the IAP on iOS 26? The iOS Documentation says that SKPaymentQueue (which is a part of StoreKit 1) is "Deprecated" and "No longer supported.", with the support being for iOS 3.0–18.0. Does this mean that apps using StoreKit 1 won't be able to make IAP purchases when running on iOS 26?

Why is this rejection coming? I don't understand.I can't see anything in my mailbox.

The app review prompt on iOS/iPadOS 26.1 has the "Not Now" button greyed out: On iOS/iPadOS 26.0, this was working: Before filing a radar, is there anything I'm missing? The only way to dismiss it is to tap a star rating and then a Cancel button appears which lets you dismiss it without reviewing.

Hi everyone, I’m implementing subscriptions using StoreKit v2, and I’ve noticed a behavior change starting with iOS 26.1. I’d like to ask if anyone else has experienced the same issue. ■ Issue Immediately after purchasing a new subscription, the value of auto_renew_status (or autoRenewStatus) returned in the receipt is 0 (auto-renew OFF). This issue occurs on iOS 26.1. On iOS 26.0 and earlier, the same parameter returned 1 (auto-renew ON) right after purchase. Sometimes, after executing a “restore” operation, the value changes to 1 later. Since we’ve been using this parameter to determine whether a user’s subscription is active or not, the current behavior is causing some difficulties on our end. ■ Questions Has anyone else observed this issue (where autoRenewStatus is 0 immediately after purchase on iOS 26.1 or later)? How are you handling or working around this behavior in your implementation? If autoRenewStatus is unreliable, we’re considering determining the subscription state based on receipt fields instead. Would this approach be reasonable? "status" is 1 (indicates active subscription) "expire_time" is in the future "deleted_at" is null If anyone has encountered the same behavior or knows of any Apple-recommended implementation approach, I’d really appreciate your insights. Thank you! 🙏

I'm using code similar to the following to conditionally show the SubscriptionStoreView and the .storeButton(.visible, for: .restorePurchases) modifier is used to allow the user to restore an existing subscription. How can I listen for events that would allow me to close this view once the subscription is restored? The .onInAppPurchaseCompletion closure does not handle this and it also appears that listening for results in Transaction.currentEntitlements also doesn't handle the fact that a subscription is restored. Any guidance on how to determine if the subscription has been restored would be greatly appreciated. Finally, how can this be tested effectively in both TestFlight and in Xcode with the simulator. if subscriptionManager.subscription == .none { SubscriptionStoreView(groupID: "1234567") { SubscriptionMarketingView(transparency: false) .containerBackground(for: .subscriptionStoreFullHeight) { GradientBackground() } } .backgroundStyle(.clear) .storeButton(.visible, for: .restorePurchases) .storeButton(.visible, for: .redeemCode) .onInAppPurchaseCompletion { product, result in Task { await subscriptionManager.entitlements() } } }

💬 Post Content Hello everyone, I’m currently testing In-App Purchases (auto-renewable subscriptions) for my iOS app, and I’m experiencing an issue where the product information cannot be fetched from StoreKit. ❓ Questions For sandbox testing, is it absolutely necessary to submit a new app version for review (with the in-app purchase included)? Or can I test subscriptions without submitting a new build to App Review? Under what conditions does the error IAPError(code: storekit_no_response, source: app_store, message: StoreKit: Failed to get response from platform.) 🧪 What I’ve Tried • Confirmed that the bundle identifier matches the App Store Connect record • Verified that In-App Purchase capability is enabled in Xcode • Ensured the sandbox tester account is logged in (Settings → App Store) • Removed the StoreKit configuration file to use the sandbox environment • Tried both real device and simulator (same error) • Accepted the Paid Apps Agreement in App Store Connect • Products are created but currently not yet submitted for review 🔍 Environment • App type: iOS app built with Flutter (using in_app_purchase plugin) • Build type: Archive build installed via Xcode (Run on device) and testFlight • StoreKit Configuration File: Currently removed (for sandbox test); • Status: Ready to submit in App Store Connect

Hi everyone, I'm building an iOS app using Capacitor 6 with Swift Package Manager (SPM). I have a custom native plugin (AppleIAPPlugin) for StoreKit 2 In-App Purchases that lives in the App target (not as an SPM package). Despite compiling successfully, the JavaScript bridge throws: "AppleIAP" plugin is not implemented on ios Setup AppleIAPPlugin.swift: swift import Foundation import Capacitor import StoreKit @objc(AppleIAPPlugin) public class AppleIAPPlugin: CAPPlugin, CAPBridgedPlugin { public let identifier = "AppleIAPPlugin" public let jsName = "AppleIAP" public let pluginMethods: [CAPPluginMethod] = [ CAPPluginMethod(name: "getProducts", returnType: CAPPluginReturnPromise), CAPPluginMethod(name: "purchase", returnType: CAPPluginReturnPromise), CAPPluginMethod(name: "restorePurchases", returnType: CAPPluginReturnPromise), CAPPluginMethod(name: "getCurrentEntitlements", returnType: CAPPluginReturnPromise), CAPPluginMethod(name: "openManageSubscriptions", returnType: CAPPluginReturnPromise), ] @objc func getProducts(_ call: CAPPluginCall) { /* StoreKit 2 implementation */ } @objc func purchase(_ call: CAPPluginCall) { /* ... */ } // etc. } AppleIAPPlugin.m: objc #import <Foundation/Foundation.h> #import <Capacitor/Capacitor.h> CAP_PLUGIN(AppleIAPPlugin, "AppleIAP", CAP_PLUGIN_METHOD(getProducts, CAPPluginReturnPromise); CAP_PLUGIN_METHOD(purchase, CAPPluginReturnPromise); CAP_PLUGIN_METHOD(restorePurchases, CAPPluginReturnPromise); CAP_PLUGIN_METHOD(getCurrentEntitlements, CAPPluginReturnPromise); CAP_PLUGIN_METHOD(openManageSubscriptions, CAPPluginReturnPromise); ) MyBridgeViewController.swift (custom bridge to register the plugin): swift import UIKit import Capacitor class MyBridgeViewController: CAPBridgeViewController { override open func capacitorDidLoad() { bridge?.registerPluginType(AppleIAPPlugin.self) } } Main.storyboard points to MyBridgeViewController (module: App) instead of CAPBridgeViewController. TypeScript side: typescript import { registerPlugin } from "@capacitor/core"; export const AppleIAP = registerPlugin("AppleIAP"); What I've verified Both .swift and .m files are in the Xcode project's Compile Sources build phase nm on the compiled binary confirms OBJC_CLASS_$_AppleIAPPlugin symbol exists The build succeeds with zero errors Other SPM-based Capacitor plugins (Share, Media, NativeAudio) work fine — they have pluginMethods and jsName symbols in the binary; my custom plugin does NOT A bridging header (App-Bridging-Header.h) is configured with #import <Capacitor/Capacitor.h> What I've tried (all failed) .m file with CAP_PLUGIN macro only (no CAPBridgedPlugin in Swift) Added CAPBridgedPlugin protocol conformance to Swift class Created MyBridgeViewController subclass with registerPluginType() in capacitorDidLoad() Removed/added override public func load() method Added #import <Foundation/Foundation.h> to .m file Various bridging header configurations Multiple clean builds and derived data wipes Environment Xcode 16 Capacitor 6 (via SPM, binary xcframework) iOS 17+ deployment target Physical device testing (not simulator) Question How should a custom plugin in the App target be registered with Capacitor 6 when using SPM? The SPM-based plugins from node_modules get auto-discovered, but my custom plugin in the App target does not. Is there a step I'm missing to make registerPluginType() work, or should I structure my custom plugin as a local SPM package instead? Any guidance would be greatly appreciated.

Hi everyone, I’m facing an issue where StoreKit is returning 0 products from the App Store, even though my auto-renewable subscriptions are approved in App Store Connect. When calling queryProductDetails using Flutter’s in_app_purchase package (which uses StoreKit under the hood), StoreKit reports success but returns an empty list. The logs show the following error: IAPError(code: storekit_no_response, source: app_store, message: "StoreKit: Failed to get response from platform.") InAppPurchase.isAvailable() returns true, but no product details are received. Already verified: • Subscriptions are approved in App Store Connect • Product identifiers in the app match those in App Store Connect exactly • In-App Purchase capability is enabled in Xcode • Paid Applications Agreement, banking, and tax details are active and complete • Using the latest version of the Flutter in_app_purchase package StoreKit should normally return the list of available products in the production environment, but it consistently returns an empty array along with the “storekit_no_response” error. Has anyone else encountered this issue or found any potential causes for StoreKit failing to return products in the production environment? Any insights would be greatly appreciated. Thank you.

Hi everyone, I’m seeing a strange behavior with StoreKit 2 and I’d like to know if anyone else experienced this. My subscription group “ROTA Premium” (Monthly + Annual) is currently Waiting for Review in App Store Connect. What works In Xcode’s StoreKit sandbox, everything loads correctly: Products appear Trial starts Purchases work What doesn’t work In TestFlight and App Review, StoreKit 2 returns zero products, so my paywall shows: “No subscription options found.” There are: No geo restrictions No backend No VPN/IP filtering Paid Apps Agreement is accepted App Review said the device was online, but couldn’t give technical help. My question Has anyone seen StoreKit 2 fail to load subscription products when the subscription group is still in Waiting for Review? Do subscription groups need to be reviewed together with the app version for StoreKit 2 to return them in TestFlight/App Review? Any advice would be appreciated! Thanks.

On this page: https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox It says: Start with a Sandbox account. What is a Sandbox account and how does one set one up? Just it just simply mean an Apple account id used for testing, or something else?

According to Apple's documentation, SKOverlay is designed to recommend other applications to users. I'm seeking clarification on whether it also supports displaying update prompts for the host application itself. Use case: My app (for example, HelloDeveloper) is live at version 2.0, but some users are still on version 1.0. I want to display a soft update prompt that allows users to remain in the app. Question: Is it possible to use SKOverlay with my app's App Store ID to present an update option without requiring users to leave the app?

Description SKTestSession.setSimulatedError() does not throw the configured error when testing StoreKit with the .loadProducts API in iOS 26.2. The simulated error is ignored, and products load successfully instead. Environment iOS: 26.2 (Simulator) Xcode: 26.2 beta 2 (Build 17C5038g) macOS: 15.6.1 Framework: StoreKitTest Testing Framework: Swift Testing base project: https://developer.apple.com/documentation/StoreKit/implementing-a-store-in-your-app-using-the-storekit-api Expected Behavior After calling session.setSimulatedError(.generic(.notAvailableInStorefront), forAPI: .loadProducts), the subsequent call to Product.products(for:) should throw StoreKitError.notAvailableInStorefront. Actual Behavior The error is not thrown. Products load successfully as if setSimulatedError() was never called. Steps to Reproduce Create an SKTestSession with a StoreKit configuration file Call session.setSimulatedError(.generic(.notAvailableInStorefront), forAPI: .loadProducts) Call Product.products(for:) with a valid product ID Observe that no error is thrown and the product loads successfully Sample Code import StoreKitTest import Testing struct SKDemoTests { let productID: String = "plus.standard" @Test func testSimulatedErrorForLoadProducts() async throws { let storeKitConfigURL = try Self.getStoreKitConfigurationURL() let session = try SKTestSession(contentsOf: storeKitConfigURL) try await session.setSimulatedError( .generic(.notAvailableInStorefront), forAPI: .loadProducts ) try await confirmation("StoreKitError throw") { throwStoreKitError in do { _ = try await Self.execute(productID: productID) } catch let error as StoreKitError { guard case StoreKitError.notAvailableInStorefront = error else { throw error } throwStoreKitError() } catch { Issue.record( "Expect StoreKitError. Error: \(error.localizedDescription)" ) } } #expect(session.allTransactions().isEmpty) } static func execute(productID: String) async throws { guard let product = try await Product.products(for: [productID]).first( where: { $0.id == productID }) else { throw NSError( domain: "SKDemoTests", code: 404, userInfo: [NSLocalizedDescriptionKey: "Product not found for ID: \(productID)"] ) } _ = product } static func getStoreKitConfigurationURL() throws -> URL { guard let bundle = Bundle(identifier: "your.bundle.identifier"), let url = bundle.url(forResource: "Products", withExtension: "storekit") else { fatalError("StoreKit configuration not found") } return url } } Test Result The test fails because the expected StoreKitError.notAvailableInStorefront is never thrown. Question Is this a known issue in iOS 26.2 / Xcode 26.2 beta 2, or is there a different approach required for simulating errors with SKTestSession in this version? Any guidance would be appreciated. Feedback Assistant report: FB21110809

Hi, I'm reaching out to report a recurring issue with in-app purchases on iOS that seems to be related to Apple’s transaction handling — not to third-party libraries. In my Flutter application, I use both StoreKit2 and StoreKit1 (for comparison) via different packages, including the official in_app_purchase package. However, in both cases, I’m experiencing unexpected reuse of transactionId and appTransactionId values, even when initiating fresh purchases with unique appAccountToken values. Problem Summary: Purchase Stream Returns Old Purchases When calling buyNonConsumable() with a new product, the purchase stream still returns data for a previously purchased product, despite clearing all Sandbox transactions and using a new applicationUserName for each attempt. Transaction IDs Reused Across Distinct Purchases Even when generating a new UUID for appAccountToken on each purchase, the returned appTransactionId and transactionId are reused — this breaks our server-side logic, which expects these fields to uniquely identify purchases and users. Example Logs: // First purchase { "appAccountToken": "2d5a0880-f68e-44a7-a414-f51204e63904", "appTransactionId": "704464472748013865", "transactionId": "2000000928154716" } // Second purchase (different user context) { "appAccountToken": "2d5a0880-f68e-44a7-a414-f51204e63904", "appTransactionId": "704464472748013865", "transactionId": "2000000928429780" } Even when using a different productId, the appTransactionId stays the same. When using StoreKit1, the productId updates properly, but the transactionId still matches the previous one. This behavior also affects App Store Server Notifications (V2): we have observed notifications tied to appAccountTokens from completely different user accounts (based on internal logs), sometimes delayed by days or weeks. I’ve prepared a reproducible example using the official Flutter in_app_purchase sample with minimal changes — you can find it here: Github gist The code is almost identical to the package example. I only added UUID generation for applicationUserName in _getToken(). In the actual app (not in this example), I retrieve the token from an API. Additional Observations from the Community: We’ve also found similar issues reported in other frameworks and languages. For instance, a developer using react-native-iap observed that App Store Server Notifications in TestFlight were tied to previously deleted users, even after signing up with a new user account and generating a new appAccountToken. Details here: User A deleted → User B signs up → receives upgrade event with User A’s token Notification uses appAccountToken from old account, not the new one This strengthens the suspicion that the issue may be related to how Apple associates transactions with Apple IDs in test environments. Questions: Is it expected for transactionId or appTransactionId to persist across purchases within the same Apple ID, even for different user contexts (e.g., separate logins in the same app)? Is there any official recommendation for avoiding this kind of data reuse in Sandbox or TestFlight environments? Should I expect appAccountToken in server notifications to always match the latest value provided during the purchase? Thank you in advance for your assistance. I would appreciate any clarification or advice regarding this issue, as it impacts production logic that relies on these identifiers being unique and consistent.

Whether using Storefront.current?.countryCode or SKPaymentQueue.default().storefront?.countryCode, both are returning "USA" only. (It used to return the correct country code before the update.) In the sandbox environment, the country code is returned correctly, but in the TestFlight environment, it always returns "USA". There's no mention of this behavior in the beta release notes, so I'm posting it here for visibility.

In Getting started with In-App Purchase using StoreKit views and the corresponding sample project, Store simultaneously enumerates Transaction.unfinished and Transaction.updates. Since, "if your app has unfinished transactions, the updates listener receives them once, immediately after the app launches," it appears that Transaction.unfinished would also receive the same unfinished transactions causing handle(updatedTransaction:) to be called for twice for each transaction, causing consumables to be double-counted. Is this a bug in the sample? Is there more information on concurrent execution of unfinished and updates?

I am unable to sign in to a Sandbox Apple Account, where this issue occurs only via Simulator. Under Settings > Developer, I tap "Sign In" under Sandbox Apple Account. I enter my account credentials, and after bringing me back to the Developer page, the Sign In button briefly appears as disabled, before being re-enabled, without signing in to the account. (The account credentials are also recognized as correct, as I will receive an alert popup if incorrect.) See screenshots below: After signing in, Sign In button appears disabled... ... then is re-enabled without actually signing in to the account. I have now tried setting up multiple sandbox accounts via App Store Connect with various permutations (no confirmation of Apple Account email, confirming Apple Account email, logging in to iCloud and accepting terms of service), running different device simulators, running simulators on different Mac computers... none of which yield a different result. By contrast, I can sign in to the Sandbox Apple Account without issue on a physical device. The problem occurs only via Simulator.

Over the past two days, we've observed an unusual spike in requests from some iOS users to our server endpoint responsible for verifying App Store purchase receipts. After sampling and analyzing the data, we found that the cause is related to the behavior of StoreKit2.Transaction.updates. Specifically, when listening for transaction updates, the system returns a large number of historical transactions — some dating back as far as one year. These callbacks are interpreted as "new" transactions, which in turn trigger repeated calls to Apple’s receipt verification servers, leading to an abnormal surge in traffic and putting pressure on our backend services. This behavior is ongoing and is something we've never encountered in our previous experience. It appears to be outside of expected behavior, and we suspect it may be due to some kind of abnormality or unintended usage scenario. We would appreciate guidance on the following: Is this a known behavior or issue with StoreKit2? Are there specific device states or conditions that could cause the system to emit historical transactions in bulk? Are there any recommended practices for mitigating or filtering such transaction floods? We have attached logs for reference. Any help identifying the root cause or suggestions for investigation would be greatly appreciated. 2025-07-24 12:39:58.594 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713445834000, "originalTransactionId" : "430001791317037", "purchaseDate" : 1713445834000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", } 2025-07-24 12:39:58.594 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "c4f79de2-a027-4b34-b777-6851f83f7e64", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713445849000, "originalTransactionId" : "430001791317270", "purchaseDate" : 1713445849000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001791317270", } 2025-07-24 12:39:58.594 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "02f305d7-0b2d-4d55-b427-192e61b99024", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713511999000, "originalTransactionId" : "430001792218708", "purchaseDate" : 1713511999000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001792218708", } 2025-07-24 12:39:58.598 +0400 [INFO] [MKPaymentService:23]: [XLPay] listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "5ca85907-1ab6-4160-828e-8ab6d3574d6f", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713512034000, "originalTransactionId" : "430001792219189", "purchaseDate" : 1713512034000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001792219189", } 2025-07-24 12:39:58.599 +0400 listenForTransactions :{ "appTransactionId" : "704289572311513293", "deviceVerificationNonce" : "04869b50-b181-4b69-b4ff-025175e9cf14", "environment" : "Production", "inAppOwnershipType" : "PURCHASED", "originalPurchaseDate" : 1713512049000, "originalTransactionId" : "430001792219440", "purchaseDate" : 1713512049000, "quantity" : 1, "signedDate" : 1753346396278, "storefrontId" : "143481", "transactionId" : "430001792219440", }

I have non-consumable and consumable in-app purchases in my app. The tutorial I was following stated Transaction.currentEntitlements includes unfinished consumables, which is incorrect according to the documentation. Is the correct way to handle unfinished consumables (and non-consumables) to implement Transaction.updates and call finish() if it’s verified? The documentation says that listener will receive unfinished transactions once upon app launch, so with that, do I understand correctly you do not need to implement Transaction.unfinished unless you want to look for unfinished transactions manually later on? Otherwise what is the correct and most recommended way to handle unfinished consumables? Is there a way to test that scenario in Xcode?

Because of historical reasons we have the same app with different bundle identifiers in different App Stores, e. g. one in Germany and one in Poland and one in France. Every app offers a monthly and a yearly in app subscription. We want to consolidate our apps and user base and want to have only one app in the end. The question is now: Can Apple make the monthly/daily subscriptions from e. g. the app in the store in Poland available or migrate them to the german app in the german App Store when we make the "german" app available also in Poland? The final goal would be that a user who bought a subscription in the polish store would have the subscription also available on his Apple ID in the german store. Is this possible? Can Apple make this possible?

Hey folks! In one of our apps we're using the FamilyControls framework to manage the screentime for the child. The app requires the Guardian to activate a subscription on his/her device to enable the functionality for the Child on the child device. We're currently using StoreKit 2 to get notified when there is an active subscription. The issue we're seeing (and our users) is that an activated subscription isn't instantly propagated to the Family members, in this case the device belonging to the child. Is this a known bug, and are the possible any workarounds? Currently we have to ask our users to "Restore Purchase" or wait minutes/hours for the app to active, which isn't a viable solution. We want it to "just work" :) Sincerely, César Pinto Castillo Ambi Studio