I'm using TestFlight to test an app with payment/subscription functionality. I created sandbox accounts in AppStore Connect accordingly to be able to test the subscriptions. I'm logged in with the sandbox account. When I try to subscribe in the App the wrong account (this is my actual real AppleID) is used for the subscription although it is recognized that this is just a sandbox subscription. I tried: logging off/on into the sandbox account creating a totally new sandbox account trying to trigger the payment with no logged in sandbox account The result is always: in the payment popup it is stated that the purchase account will be my original AppleID and not a sandbox account. How can I switch the accounts? Is this a bug at Apple's side somehow?

Im building a small iphone app with StoreKit and currently testing it in testflight right on my mac, not on iphone. StoreKit part almost exactly copied from SKDemo from one of the Apple's WWDC. For some users and for myself Transaction.currentEntitlements always returns .unverified results. I double-checked Apple Connect settings, i checked my internet connection and everything is fine. Is there some pitfalls for testflight on mac? How can I find out what is causing this problem?

The majority of our sandbox calls to verifyReceipt end in an ETIMEDOUT error. This is making it very difficult to verify our purchase flow for our pending release. We have not yet migrated to StoreKit 2 and still rely on this API endpoint. The Apple API status page reports no issues. Is anyone else encountering this?

The sample code provided in https://developer.apple.com/wwdc21/10114 doesn't appear to call finish() on unverified transactions, and I haven't been able to find any documentation regarding what to do with unfinished transactions. However, Apple has always emphasized the importance of finishing transactions, and since a transaction object is provided even with the unverified state, I'd love some guidance!

We were facing the same error yesterday and tried many different solutions, but none of them worked. However, today the issue resolved itself and everything is working properly now. The issue we were facing was: #1. not getting any product in didReceive method of storekit. #2. it was working sometimes (i.e. if we try 3 times then 1 time we were getting the product

Hello, Is anyone else seeing Purchase.PurchaseResult.UserCancelled, despite a successful transaction? I had a user notify me today that he: Attempted a purchase Entered payment credentials Was asked to opt in to email subscription notifications Opted In Was shown my app's "User Canceled Purchase" UI Attempted to repurchase Was alerted that he was "Already Subscribed" I have adjusted my code to check Transaction.currentEntitlements on receiving a .userCancelled result, to avoid this in the future. Is this logically sound? Here is my code - please let me know if you see any issues: func purchase(product: Product, userId: String) async throws -> StoreKit.Transaction { let purchaseUUID = UUID() let options: Set<Product.PurchaseOption> = [.appAccountToken(purchaseUUID)] let result = try await product.purchase(options: options) switch result { case .success(let verification): guard case .verified(let tx) = verification else { throw PurchaseError.verificationFailed // Show Error UI } return try await processVerified(tx) case .userCancelled: for await result in Transaction.currentEntitlements { if case .verified(let tx) = result, tx.productID == product.id, tx.revocationDate == nil { return try await processVerified(tx) } } throw PurchaseError.cancelled // Show User Cancelled UI case .pending: throw PurchaseError.pending // Show Pending UI @unknown default: throw PurchaseError.unknown // Show Error UI } } @MainActor func processVerified(_ transaction: StoreKit.Transaction) async throws -> StoreKit.Transaction { let id = String(transaction.id) if await transactionCache.contains(id) { await transaction.finish() return transaction // Show Success UI } let (ok, error) = await notifyServer(transaction) guard ok else { throw error ?? PurchaseError.serverFailure(nil) // Show Error UI } await transaction.finish() await transactionCache.insert(id) return transaction // Show Success UI } The only place the "User Cancelled Purchase" UI is displayed on my app is after the one instance of "throw PurchaseError.cancelled" above. This happened in Production, but I have also seen userCancelled happen unexpectedly in Sandbox. Thank you for your time and help.

I enter the payment wall, there it takes more or less 3 to 4 minutes to show the plans, when I select the monthly plan the loader is shown and from there the pop up to make the purchase in sandbox does not appear, I have waited until a maximum of 50 minutes and it is not shown, I go back and close the app I do the same steps and I am still there, without showing the pop up. Doing this same process in xcode, everything happens immediately without any interruption.

We are experiencing an issue with our iOS TestFlight builds where in-app purchase (IAP) products are not being retrieved as expected. We are using Unity IAP to handle our purchases, and despite having all the products correctly configured and approved in App Store Connect, we consistently receive errors such as: UnityIAP: Received 0 products Unavailable product [product_id] We have thoroughly verified that: The product identifiers are correctly configured in App Store Connect. The bundle ID mappings are correctly set on both Unity and our backend. The same setup works on the live App Store build, where purchases are fetched and validated correctly for the same set of In App products. Sandbox test accounts are being used during TestFlight testing. This issue only started appearing recently and affects the TestFlight builds only. Note: My App ID and Product ID are correct, the IAP is live on the App Store, and the product is recognized in sandbox. Looking forward to your support on this matter.

In Xcode's StoreKit transaction manager (Debug > StoreKit > Manage Transactions), how can I delete old apps that I do not need anymore from the list of apps?

There is an issue with StoreKit. The line let products = try await StoreKit.Product.products(for: ids) doesn't always work correctly. Sometimes it returns an array with the correct data, and sometimes it returns an empty array. I'm passing the correct ids to products(for:). This problem only occurs when using the sandbox environment (in TestFlight builds). In the App Store version, everything works fine. StoreKit configuration is none. All IAPs are approved. Everything was working fine before this. The problem was discovered on May 1, 2025.

Hello all! My application written with C++ and using StoreKit1. For now my application using bridge C++/Objective-CPP/Objective-C/Swift. Since StoreKit1 declared "deprecated" got a question of how to implement correctly StoreKit2 in C++ application, mostly everything about Renewable Subscriptions. StoreKit2 have no direct API in Objective-C, it's available only in Swift. Which is the way the best and correct way: -- for on-device writing C library and in it implement Swift? In this case how to add correctly StoreKit2 into library itself? -- for on-device somehow write kind of wrapper for Swift StoreKit 2 within translation of all of objects in Objective-C and implement it with C++/Objective-CPP bridge? In this case how to add correctly StoreKit2 in C++ project written with CMake? Here https://github.com/compnerd/swift-cmake-examples/tree/main the one of the examples of interoperability C++/Swift with CMake. But how to use exactly with StoreKit2? -- only using server side solution?

We’re encountering a problem with StoreKit in the sandbox environment. During an SKProductsRequest, some or all of the product identifiers provided are being returned in the invalidProductIdentifiers array of the SKProductsResponse, despite being valid and already approved. This behavior began occurring since last 2 days only and appears to be intermittent—in some cases, a product identifier that initially fails will succeed after one or two retries, without any changes on our end. What we've verified: All product identifiers are correctly configured and approved in App Store Connect. No recent changes have been made to our product configuration. The same product identifiers have previously worked without issue. We would appreciate any assistance in identifying the root cause of this behavior. Please also let us know if there is a known issue currently affecting StoreKit sandbox services. Thank you for your support.

In my understanding, with the latest court ruling in the US, iOS apps may decide to support web-based payments for subscriptions and in-app purchases. However, are we allowed to exclusively support web-based payments and not implement StoreKit at all?

Hello, I'm encountering an issue when trying to use the subscriptionGroupLookups endpoint in the App Store Connect API. Despite having the correct setup, I continue to receive a 404 NOT FOUND error when making requests to: GET https://api.appstoreconnect.apple.com/v1/subscriptionGroupLookups Here is the current state of my environment: I am the Account Holder of the App Store Connect account The App Store Connect API key has been successfully created I have the correct Key ID, Issuer ID, and .p8 private key I can authenticate and access the apps and subscriptionGroups endpoints However, the subscriptionGroupLookups endpoint always returns: { "errors": [ { "status": "404", "code": "NOT_FOUND", "title": "The specified resource does not exist" } ] } I suspect that LookUp Keys (UUIDs) have not been assigned to our subscription groups, even though they were created and are active in App Store Connect. There is no “Request Access” button visible under the Integrations tab (as mentioned in Apple support instructions), and my keys appear under “App Store Connect API” > “Keys” as active. Questions: How can I ensure that LookUp Keys are assigned to my subscription groups? Is there a way to trigger this manually or via support? Has anyone successfully resolved this? Any advice or experience would be greatly appreciated. Thank you!

Looking for assistance in managing subscription upgrades for TestFlight users. I have a few monthly subscriptions, 30days, each with a different set of available features, 1 with all, and 1 with fewer. (All are in proper order and grouped in App Store connection subscriptions) subscribing seems to be working fine, and purchasing an upgrade is going ok. what is not: reflecting the upgraded plan in app (currently reflects it will start in 30days when current subscription expires) I’m lead to believe this will be resolved with a live app in App Store, that will then handle prorating, terminate the old plan and immediately start the new one. looking for help getting TestFlight to show immediate upgrades.

Hi, I'm using the AppTransaction.shared API to retrieve the originalAppVersion, but I'm encountering issues for users who originally installed the app in 2017. Specifically, the property doesn't seem to return the expected value (or returns nil) for these older accounts. I have verified this issue using a real App Store purchase from 2017. Steps to Reproduce: Use a test account that originally downloaded the app in 2017. Call: let shared = try await AppTransaction.shared print(shared.originalAppVersion) Observe that originalAppVersion is missing or not returned correctly. Any insights on whether this is expected behavior for very old App Store purchases, or if there is a workaround to reliably detect the original app version? Thanks in advance!

Our app server has subscription feature and processes purchase life cycles based on App Store Server Notification v1. Last year, when users purchased subscriptions during the following timeframe, we received "INITIAL_BUY" notifications with "unified_receipt.Latest_receipt_info.purchase_date" set to future date(approx. 1 hour after the actual purchase). 2024-11-03 08:00:00 - 2024-11-03 09:00:00 Etc/GMT (UTC) For example, we received the following v1 notification at 2024-11-03 08:36:33 Etc/GMT. "notification_type": "INITIAL_BUY" "unified_receipt.latest_receipt_info[].purchase_date": "2024-11-03 09:36:02 Etc/GMT" Our server grants subscription entitlement based on "purchase_date" so the users had to wait 1 hour before the subscription features became available. The timeframe coincided with the end of daylight saving time in the U.S., so we assume that it affected the behavior, but our country doesn't adopt daylight saving time. We have some questions regarding this behavior. In countries without daylight saving time, how should we handle such notifications with future purchase date in order to properly grant subscription entitlement? In App Store Server Notification v2, could purchase date be set to future date at the end of daylight saving time in the U.S., just as in v1 notifications? JWSTransactionDecodedPayload.purchaseDate

Hey everyone, I’m submitting my first version of an iOS app to the App Store and ran into an issue I can’t seem to resolve. The app was rejected because during review, Apple couldn’t see the In-App Purchase product on the purchase screen. That’s their only complaint — everything else works fine. Here’s what’s going on: • In debug mode via Xcode, the product shows up correctly, and everything works as expected. • In TestFlight builds, the product doesn’t show up at all — neither for me nor for Apple. • The IAP is currently marked as “Waiting for Review”, not “Ready to Submit”, and it is linked to the current app version in App Store Connect. I’m not sure if the IAP being in “Waiting for Review” is the reason it doesn’t show up in the TestFlight version — but I assumed Apple would still be able to access it for testing. Has anyone experienced this? Do I need to wait for the IAP itself to be approved before it works in TestFlight and can be reviewed? Any insights would be super helpful. Thanks!

I'm currently still on StoreKit 1, and am testing the paymentQueueShouldShowPriceConsent delegate function. In my local .storekit file, I have a renewable subscription set up with a promotional offer. My test flow is as follows: User subscribes to renewable subscription Let subscription auto-renew once or twice User subscribes to renewable subscription with promotional offer with significant price reduction Promotional offer lapses and price increases to normal Expect paymentQueueShouldShowPriceConsent delegate function to trigger However, #5 never does get invoked, despite re-trying the subscription and promotional offers in various configurations. Manually triggering the Request Price Increase Consent option in the Xcode StoreKit transactions list does invoke the delegate function, but letting the promotional offer lapse does not. My storefront is set to Korea, and my simulator region is set to Korea as well. According to the documentation here and here, consent is required for all price increases in Korea. Is there some way I could check if things are working as intended?

How can I get the region region currently used in the macOS App Store? Preferably via Swift libraries, but any command / function will suffice. The following StoreKit property seems to always return the region for the Apple Account associated with my macOS user. await Storefront.current?.countryCode See the Apple docs. My macOS Apple Account region is US; in the App Store, when I sign into a different Apple Account whose region is GB (UK), Storefront.current?.countryCode continues to return US, not GB (or UK). I correctly see prices in pounds instead of in dollars, British spelling instead of American spelling, apps listed in my purchased tab for the UK (not the US) Apple Account, and, in the Account Settings dialog, the UK Apple Account email address, billing address & Country/Region set to United Kingdom. I didn't get any relevant results from the following command lines: defaults find GB defaults find UK defaults find uk-apple-id@example.com defaults find uk-apple-id The following didn't change after I signed into the UK Apple Account in the App Store: $ defaults read com.apple.AppStoreComponents { ASCLocaleID = "en-US@calendar=gregorian"; } Maybe Storefront.current?.countryCode only specifies the country code for the Storefront that will be used for in-app purchases, instead of for purchasing new apps from the App Store; maybe the former is tied to the Apple Account for the macOS user, instead of to the Apple Account for the App Store. If that's the case, what other mechanism can I use to obtain the country code for the App Store storefront?