StoreKit

RSS for tag

Support in-app purchases and interactions with the App Store using StoreKit.

StoreKit Documentation

Posts under StoreKit subtopic

Post

Replies

Boosts

Views

Activity

In-App Purchase Resources
General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video
0
0
513
Jun ’26
**Subject:** AdAttributionKit Postback URL Registration Questions for Existing SKAdNetwork Ad Networks
Here's a much shorter version with just the questions: Hi Apple Developer Support, We're an ad network already registered for SKAdNetwork and are integrating AdAttributionKit. We have a few questions regarding postback URL registration: Do we need to register a separate postback URL for AdAttributionKit, or is our existing SKAdNetwork postback URL reused automatically? If a separate AAK registration is required, can the AAK postback URL be the same as our existing SKAN postback URL, or does Apple require a different URL/path? If the same URL is used for both, are AAK postbacks always delivered as a JWS payload while SKAN postbacks continue to use the existing JSON format? When WWDC states that existing SKAdNetwork ad networks require "no further enrollment," does that refer only to reusing the existing ad network ID, or also to reusing the registered postback URL? Is the Developer Mode AdAttributionKit testing flow the correct way to validate ad network postback delivery? Thanks!
0
0
13
4h
Urgent: AppStore.requestReview(in:) appears to show rating prompts too frequently in production
Hello, We are requesting urgent help with what appears to be repeated presentation of the native in-app rating prompt in our production app, Jízdní řády IDOS: https://apps.apple.com/cz/app/j%C3%ADzdn%C3%AD-%C5%99%C3%A1dy-idos/id473503749 This issue is materially affecting our App Store rating and user trust. We estimate that it has resulted in dozens of negative reviews explicitly mentioning that the native “Rate this app” prompt is shown repeatedly or “all the time”. The actual impact on our overall rating is difficult to determine, as not all affected users explicitly reference this issue in their reviews. The affected builds are App Store production builds, not Debug builds or TestFlight builds. Initially, we used the deprecated SKStoreReviewController API. We suspected that this could be the cause, so we migrated to the current API on iOS 18 and later: import StoreKit import UIKit @MainActor static func requestReview(from view: UIView) { if #available(iOS 18.0, *), let scene = view.window?.windowScene { AppStore.requestReview(in: scene) } else if #available(iOS 14.0, *), let scene = view.window?.windowScene { SKStoreReviewController.requestReview(in: scene) } else { SKStoreReviewController.requestReview() } } Unfortunately, this change did not resolve the issue. Users have continued to report that the native rating prompt appears repeatedly in the App Store version of our app. We understand that StoreKit controls whether the prompt is actually presented and should enforce the documented display limit. However, the volume and consistency of user feedback make us concerned that this limit may not be reliably enforced in our case. We have also found a similar report from another developer: https://developer.apple.com/forums/thread/827331 Could you please clarify: Can SKStoreReviewController.requestReview() or AppStore.requestReview(in:) result in the prompt being shown more than three times within 365 days in a shipping App Store build? Is there any known issue, limitation, or behavioural difference affecting either SKStoreReviewController.requestReview(in:) or AppStore.requestReview(in:) that could explain repeated presentation of the native rating prompt in a shipping App Store build? Could the SwiftUI RequestReviewAction API behave differently from AppStore.requestReview(in:) with respect to enforcing the presentation limit? Would migrating to RequestReviewAction be expected to resolve this issue? Our application is predominantly UIKit, so adopting the SwiftUI API would require non-trivial integration work. More importantly, we do not want to use production users to test another implementation while the issue may continue to negatively affect our rating. We would therefore appreciate guidance on the expected behaviour and the recommended implementation before making this change. We can provide affected app versions, iOS versions, device details, screenshots, and examples of user feedback immediately if useful. Thank you.
1
0
32
13h
Approved in-app purchase not available in production — StoreKit returns no product (live app, all TN3188 checks pass)
Live App Store app; approved non-consumable in-app purchase is not returned by production StoreKit, so customers cannot buy it. Product.products(for:) returns nothing; the paywall shows "purchases aren't available." ~15 days since first release (2026-07-06). Reproduced on two devices with two different Apple IDs. A redeemed promo code also did not deliver it. Important: my IAP status is APPROVED (not "Waiting for Review"), so this differs from some recent threads — yet the product still isn't served in production. Verified per TN3188 (all pass): product ID matches App Store Connect exactly; status Approved; Availability = all 175 regions; priced (base USD); listed on the public App Store product page; Paid Apps Agreement, banking, and tax forms all Active; no local .storekit config in the build; the product returns correctly from our provider's (RevenueCat) servers, so the empty result is specifically the on-device production StoreKit fetch. This coincides with the recent App Store Connect incident affecting in-app-purchase submission, and there's a cluster of similar reports this week (threads 838171, 838435, 835770, and "In-App Subscriptions stuck in 'Waiting for Review' after App Store Connect maintenance"). It looks like a server-side issue where the product never propagated to production StoreKit despite showing Approved. Environment: Expo/EAS, React Native 0.81, StoreKit 2 via react-native-purchases 10.3.0. Devices: iPhone 15 Pro Max (iOS 27.0), iPhone 16 Pro Max (iOS 26.5). Open Developer Support case: 102936978821. Is there any developer-side step remaining, or does this require Apple to re-process / re-propagate the product server-side? Any guidance appreciated.
0
0
47
1d
Production subscription remains Active after failed payment and no funds deducted
Hello, We are investigating an auto-renewable monthly subscription in the Production environment. Timeline and observed behavior: On June 29, 2026, the user initiated the first subscription purchase. The Apple Account used WeChat Pay as its payment method. The WeChat charge failed because the balance was insufficient, and no funds were deducted from any available payment source. Nevertheless, StoreKit returned a verified transaction, the subscription purchase succeeded in the app, and App Store Connect Sales Analytics reports proceeds for the purchase. We grant entitlement based only on Apple's signed transaction and subscription status, so the user currently has access. As of July 20, 2026, Get All Subscription Statuses from App Store Server API returns: environment: Production status: 1 (Active) expiresDate: 2026-07-29T03:37:11Z autoRenewStatus: 1 no gracePeriodExpiresDate no revocationDate no expirationIntent no billing retry indication Our App Store Server Notifications endpoint has received only: SUBSCRIBED / INITIAL_BUY We have not received DID_FAIL_TO_RENEW, EXPIRED, REFUND, or REVOKE. Questions: Is it expected for Apple to issue a valid production initial-purchase transaction and report proceeds even when the underlying WeChat Pay charge failed and no money was deducted? Could this be an unpaid Apple Account balance or delayed settlement that is invisible to the developer? While the Server API returns status 1, should the developer continue granting entitlement until expiresDate? Is there another authoritative App Store Server API or signed field that indicates the payment has not actually been collected? If renewal or collection later fails, when should we expect DID_FAIL_TO_RENEW or a change to billing retry or expired status? We have intentionally omitted transaction IDs and account identifiers from this public post. I can provide them privately to Apple Support if needed. Thanks
0
0
45
3d
requestReview() prompting repeatedly
We're getting user reports that the App Store rating prompt appears repeatedly — one user says they're prompted roughly every day, and that they still get the prompt after they've already left a rating. This contradicts the documented behavior, so I want to check whether others are seeing the same thing or whether there's a known regression. What the docs say should happen The system limits display to 3 occurrences per app within a 365-day period. For a user who has already rated/reviewed, StoreKit should only display again if the app version is new and more than 365 days have passed since their previous review. Has anyone else experience it?
2
0
313
5d
SKTestSession.buyProduct(identifier: options:) throws error
Hi, Overview I am trying to write a unit test case to buy a storekit product. SKTestSession.buyProduct(identifier: options:) throws the error StoreKit.StoreKitError.notEntitled Testcase Code @Test func example() async throws { let session = try SKTestSession(configurationFileNamed: "VehicleStore") session.disableDialogs = true session.clearTransactions() do { let transaction = try await session.buyProduct(identifier: "nonconsumable.car", options: []) print(transaction) } catch { // Throws StoreKit.StoreKitError.notEntitled print("Error: \(error)") } } Storekit configuration file Note In-App purchases capability is added StoreKit configuration file is used in testcase Environment: macOS 26.5.2 (25F84) Xcode 26.6 (17F113)
5
0
364
5d
Refund requests failing in production
We offer an in-app way for customers to request an Apple refund for an auto-renewable subscription using StoreKit2. Everything worked during testing and verification in the Sandbox and TestFlight phases, but now consistently fails in Production. We present the refund sheet on a button press: .refundRequestSheet(for: transactionID, isPresented: $isPresenting) { result in switch result { case .success(let status): // .success / .userCancelled handled here case .failure(let error): // -> .failed for every user } } We log the outcome of all the requests, success and cancel behaves as expected. Since RefundRequestError only has .duplicateRequest .failed and the localizedDescription is generic, we don't know why it is failing. We have already checked that the transaction are for verified, not revoked, non-upgraded and active subscriptions. The issue only happens in Production. Is there any way to get more information about why a refund request fails or what other configuration needs to verified for this to work? Is there an eligibility window or other non-specified limit that might result in these errors?
1
0
309
5d
StoreKit 2 currentEntitlements persists after Sandbox Purchase History reset in TestFlight
I am testing a StoreKit 2 non-consumable IAP through TestFlight. Product ID: com.metabolla.plus.lifetime Type: Non-Consumable Environment: TestFlight / Sandbox Transaction.currentEntitlements keeps returning an active entitlement for this product even after: configuring a Sandbox Apple Account clearing Sandbox Purchase History reinstalling the app rebooting the device Important detail: the first TestFlight purchase was completed before configuring the Sandbox Apple Account on the device. If I temporarily change the Product ID in code, the entitlement disappears, so the issue seems tied to the original Product ID/account/receipt. Question: Can a non-consumable TestFlight purchase made before Sandbox Apple Account configuration remain associated with the original TestFlight/Apple ID identity? Is there any supported way to clear this entitlement for testing?
4
0
783
6d
SKPaymentQueue.restoreCompletedTransactions returns 0 transactions for auto-renewable subscriptions on iOS 26.4
Is anybody else seeing this? Since iOS 26.4, calling SKPaymentQueue.restoreCompletedTransactions() no longer returns any transactions for active auto-renewable subscriptions. The success callback is invoked correctly, but the transactions array is empty. The same device and the same Apple ID return the expected transactions on iOS 26.3.1 and earlier. Environment Affected: iOS 26.4.x (confirmed on 26.4.2) Working: iOS 26.3.1 and earlier Product type: Auto-renewable subscriptions Deployment target: iOS 14.0 Steps to reproduce Have an active auto-renewable subscription on an Apple ID (sandbox or production) Run on a device with iOS 26.4 or later Call SKPaymentQueue.default().restoreCompletedTransactions() (or the equivalent via a wrapper such as RMStore) Observe the paymentQueueRestoreCompletedTransactionsFinished delegate callback Expected behaviour The delegate receives the restored transactions via paymentQueue(_:updatedTransactions:) before paymentQueueRestoreCompletedTransactionsFinished is called, as documented. Actual behaviour paymentQueueRestoreCompletedTransactionsFinished is called immediately with no prior transaction updates. The transactions array is empty.
1
1
266
6d
App Subscription "Confirm with Apple Device" UI
My tvOS app includes the purchase of subscriptions, and I am updating the code with Storekit 2.0. I have seen other apps that present the "Confirm with Apple Device" UI upon selection of a product, but for me I only ever see an alert confirming the purchase. I have tested this using Xcode storekit data and a sandbox account. I have also attempted using Storekit views and passing the UIWindowScene to the purchase(confirmIn: ) parameter, but neither made any difference. Is there some limitation that prevents that UI from showing in debug builds?
1
0
303
6d
App approved and released, but auto-renewable subscriptions remain "Waiting for Review" and StoreKit returns no products
M y app was approved and is now live on the App Store, but all four auto-renewable subscriptions are still Waiting for Review in App Store Connect. Because of this, the production app's StoreKit 2 call to Product.products(for:) returns 0 products, and users see: "No subscription products were returned by the App Store." There are no metadata errors or warnings—only Waiting for Review. My questions are: Is it normal for an app to be released before its subscriptions are approved? While subscriptions are in Waiting for Review, is it expected that Product.products(for:) returns an empty array? Has anyone experienced this, and how long did it take for the subscriptions to be approved after the app was already live? I've attached: App Store Connect screenshot showing all four subscriptions in Waiting for Review. App screenshot showing the "No subscription products were returned by the App Store." message. Any insight would be greatly appreciated. Thanks!
0
0
96
6d
Production StoreKit silently omits one approved auto-renewable subscription product — sandbox returns it correctly, sudden onset 2026-05-09
Hi all, Reporting an active production issue in case anyone else is seeing the same pattern, or has insight into what could cause this. Symptom As of 2026-05-09 morning, one specific auto-renewable subscription product is silently absent from Production StoreKit responses on our live App Store build. The product is still 'Approved' in App Store Connect, all metadata is intact, no error code is returned — the product simply does not appear in the products array. The other 3 products in the same subscription group continue to work normally. 100% of production users are affected. Setup App: live on App Store, version 1.0.0 (build 8) Subscription group with 4 auto-renewable products: standard_monthly_799 ✅ returns correctly standard_annual_6999 ✅ returns correctly unlimited_monthly_1299 ❌ MISSING from production response unlimited_annual_9999 ✅ returns correctly SDK: purchases_flutter (RevenueCat) → StoreKit Same physical device, same code, same RC config behaves correctly in Sandbox — all 4 products are returned and a sandbox purchase of unlimited_monthly_1299 succeeds. Timeline 2026-05-08: working correctly, purchases succeeding normally 2026-05-09 morning: product silently disappears from production StoreKit responses No app update was submitted between those dates No App Store Connect changes were made Onset was simultaneous across all production users at one timestamp What I've verified App Store Connect: Product status: Approved All territories enabled, all prices configured (no N/A in any territory) Subscription group correctly contains all 4 products No 'Submit for Review' pending changes Product attached to live app version 1.0.0 (8) Tax category: Match to parent app Family Sharing: Off (consistent with the working products) Paid Applications Agreement: Status: Active Banking and Tax forms: Active RevenueCat dashboard: All 4 products show Store Status: Approved Default offering contains all 4 packages iOS attachment for the affected product is intact No warnings or sync errors Sandbox StoreKit (today): flutter run (debug) on physical device → all 4 products returned flutter run --release on physical device → all 4 products returned Sandbox purchase of unlimited_monthly_1299 succeeds Production StoreKit (today, broken): App Store-downloaded 1.0.0 (8) on multiple users' devices Multiple Apple IDs / multiple devices / multiple regions — all reproduce Only unlimited_monthly_1299 affected; other 3 products fine Why this looks server-side Sudden simultaneous onset across all users No code or config change preceded onset Sandbox unaffected, only Production affected Single product affected, not the whole subscription group or app No error returned — silent omission only Cannot reproduce with locally signed builds, only with App Store-distributed binary This pattern is consistent with a server-side product indexing or fronting issue specific to one product in Production StoreKit. As a developer I don't have visibility into Apple's product-serving infrastructure to investigate further — looking for guidance from anyone who has seen this before. Questions for the community Has anyone else seen a single auto-renewable subscription silently drop out of Production StoreKit responses while remaining Approved in ASC, with no error code returned? Is there any internal product-state flag (beyond what's exposed in the ASC UI) that could cause Production StoreKit to silently omit a product? Anything similar to a hidden 'review hold' or 'price tier reconciliation' state? Has the asymmetry between RevenueCat package identifiers (Standard uses RC's $rc_monthly/$rc_annual default identifiers, Premium uses custom premium_monthly/premium_annual identifiers) ever been implicated in this kind of failure? RC support has been notified, but worth asking publicly. For anyone who has resolved a similar issue: what action ended up clearing it — ASC re-save, RC re-sync, Apple Support escalation, or did it self-resolve after Apple-side cache propagation? Filings in progress ASC Contact Us ticket: filed Apple DTS technical incident: filed RevenueCat support ticket: filed Feedback Assistant report: in progress Will update this thread with the resolution path once we have one. Thanks, — Kin Pong Lo (developer, Alice: AI English Tutor)
1
0
380
6d
Guideline 3.1.1 – Consumable IAPs rejected after binary approved; asked for “new binary” though 1.8 already submitted
Hi, We received App Review feedback under Guideline 3.1.1 for our in-app purchases, and we’d appreciate guidance on the expected next step. What we submitted; We created and completed metadata for the new consumable IAPs (pricing, availability, review screenshots, localizations). We uploaded and submitted app version 1.8 with a recent binary (build processed/VALID in App Store Connect). We also submitted the consumable IAPs for review. Outcome: App version 1.8 was approved (currently Pending Developer Release). The consumable IAPs were returned with Developer Action Needed. Our confusion We already uploaded/submitted a new binary (1.8) for this release, and the consumable purchase flows are implemented in that binary (Store / offers). The app binary itself was approved, but the consumable IAPs were rejected with a request for another new binary. For a first-time expansion from Non-Consumable-only to Consumables, is a separate / subsequent binary submission always required even if the approved version already contains the purchase UI?
1
0
116
1w
AppStore.ageRatingCode always returns 0 on real device — is this expected behavior?
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.
1
0
251
1w
StoreKit Product Retrieval Issue During App Review
Hello, We are contacting you regarding an issue we are currently experiencing during the App Review process related to In-App Purchases and StoreKit product retrieval. After extensive internal testing and investigation, we believe the behavior we are seeing is identical to the issue discussed in the following Apple Developer Forum thread: https://developer.apple.com/forums/thread/827016 Our application was rejected under Guideline 2.1 - Performance because the subscription plans reportedly failed to load during review. According to the review notes, the In-App Purchase product list appeared empty in the review environment, which prevented the paywall from loading correctly. We would like to provide additional technical context because, despite significant testing efforts on our side, we have been unable to reproduce this behavior outside of the App Review environment. The exact same binary that was reviewed by App Review has been thoroughly tested by us through TestFlight on multiple physical devices, including iPhone and iPad devices, using multiple Sandbox tester accounts and different network conditions. In all of our tests, the subscription system functions correctly and consistently. Specifically, we verified that: StoreKit successfully retrieves all configured subscription products RevenueCat offerings load correctly without timeout or empty states Localized pricing information is displayed properly Subscription packages appear correctly in the paywall UI Purchase flows complete successfully Restore purchases functionality works correctly Products are returned both on cold launch and repeated application launches The issue does not occur intermittently in TestFlight or Sandbox testing on our side We also carefully reviewed our App Store Connect configuration and verified the following items multiple times: All In-App Purchase subscriptions are attached to the submitted app version Product identifiers used in the application code exactly match the identifiers configured in App Store Connect All products are marked as “Cleared for Sale” Paid Applications Agreement has been accepted and remains active Tax and banking information are complete and active Subscription localization settings are configured properly Pricing information is active and visible The products are available in the storefronts being tested The submitted binary is identical to the binary tested successfully through TestFlight Additionally, we implemented defensive handling in the application to minimize the impact of temporary StoreKit failures. The application now includes: Retry logic for offerings retrieval Graceful fallback handling for empty offerings Protection against infinite loading states Additional RevenueCat and StoreKit logging UI fallbacks when products temporarily fail to load Despite these safeguards, the review feedback still indicates that the products are not being returned in the App Review environment. At this point, because the issue cannot be reproduced externally and only appears during App Review, we suspect there may be an intermittent or environment-specific issue affecting StoreKit product retrieval in the review sandbox environment. One important detail is that the exact same build consistently works in TestFlight immediately before and after submission. This makes the behavior particularly difficult for us to diagnose because there appears to be no configuration difference between our successful tests and the App Review scenario. We also understand from Apple documentation and previous App Review communication that In-App Purchases are tested within an Apple-provided sandbox environment. Based on the evidence currently available to us, the failure appears to occur specifically within that review sandbox process rather than within the application logic itself. If possible, we would greatly appreciate assistance with the following: Verifying whether StoreKit product retrieval is functioning correctly in the App Review sandbox environment Confirming whether the review device successfully established communication with App Store sandbox services Providing any available diagnostic logs related to the failed product request Confirming whether the product identifiers were visible to StoreKit during review Sharing any guidance on how we may reproduce the App Review behavior locally Clarifying whether there are known intermittent issues affecting StoreKit product loading during App Review We are fully committed to resolving the issue and ensuring complete compliance with App Store requirements. However, because the issue currently appears environment-specific and non-reproducible from our side, we are struggling to determine what additional changes are necessary. If there are any additional diagnostics, logging methods, StoreKit verification steps, or App Review recommendations you would like us to implement, we would be happy to do so immediately. Thank you very much for your assistance, support, and time. We sincerely appreciate your help in investigating this issue. Best regards, Mert Akgün
3
1
398
1w
In App Purchase UI difference for tvOS
We're seeing differences in the purchase dialog and overall presentation when testing with Sandbox accounts compared to commercially available apps. Are these UI differences are expected and are simply a characteristic of the Sandbox testing environment, or if there are any configuration requirements that affect the purchase sheet appearance? It would be helpful to know whether developers should expect the production purchase UI to match App Store apps once the app is distributed through TestFlight/App Store, or if there are additional factors involved. Sandbox UI Expected UI
0
0
183
1w
Subscription bundle & suite testing failure on XCode 27 Beta 3
I'm quite excited about the newly announced bundle and suite feature and trying to test the new Subscription Bundle type introduced in the recent Xcode Beta (using a local .storekit configuration file). I have set up: A local .storekit file. Inside it, I configured a Subscription Bundle with the ID "bundle". This bundle is linked to two internal auto-renewable subscriptions in the same file. The StoreKit configuration is active in my Scheme options. When I try to fetch a standard auto-renewable subscription ID, it works perfectly. However, when I try to fetch the "bundle" ID, the API returns successfully but with an empty array [] (no errors thrown). Is there a different way to query/fetch the new Subscription Bundle type in StoreKit 2, or is local testing for bundles not yet supported in the simulator in this beta? My sample code import StoreKit @MainActor class StoreManager: ObservableObject { @Published var products: [Product] = [] func fetchProducts() async { do { // "bundle" is defined in our local .storekit file as a SubscriptionBundle self.products = try await Product.products(for: ["bundle"]) print("Fetched products: \(self.products.map { $0.id })") } catch { print("Fetch error: \(error)") } } } struct ContentView: View { @StateObject private var store = StoreManager() var body: some View { VStack { if store.products.isEmpty { Text("Stuck Loading: Product not found.") } else { ForEach(store.products, id: \.id) { product in Text("Found: \(product.displayName) - \(product.displayPrice)") } } } .task { await store.task { await store.fetchProducts() } } } } My storekit "appPolicies" : { "eula" : "", "policies" : [ { "locale" : "en_US", "policyText" : "", "policyURL" : "" } ] }, "identifier" : "2B237494", "nonRenewingSubscriptions" : [ ], "products" : [ ], "settings" : { "_askToBuyEnabled" : false, "_billingGracePeriodEnabled" : false, "_billingIssuesEnabled" : false, "_disableDialogs" : false, "_failTransactionsEnabled" : false, "_locale" : "en_US", "_renewalBillingIssuesEnabled" : false, "_storefront" : "USA", "_storeKitErrors" : [ ], "_timeRate" : 0 }, "subscriptionBundleGroups" : [ { "id" : "EE1EB207", "localizations" : [ ], "name" : "bundle_group", "subscriptions" : [ { "displayPrice" : "0.99", "duration" : "P1M", "groupNumber" : 1, "internalID" : "84A95B47", "introductoryOffers" : [ { "billingPlanType" : "BILLED_UPFRONT", "internalID" : "DD9208A6", "numberOfPeriods" : 1, "paymentMode" : "free", "subscriptionPeriod" : "P1W" } ], "isFamilyShareable" : false, "linkedSubscriptions" : [ { "internal" : "D1A384C1" }, { "internal" : "01ABB5D2" } ], "localizations" : [ { "description" : "", "displayName" : "", "locale" : "en_US" } ], "productID" : "bundle", "referenceName" : "Awesome Bundle", "subscriptionGroupID" : "EE1EB207", "type" : "SubscriptionBundle" } ] } ], "subscriptionGroups" : [ { "id" : "84E94B59", "localizations" : [ ], "name" : "premium_group", "subscriptions" : [ { "adHocOffers" : [ ], "billingPlans" : [ { "billingPlanType" : "BILLED_UPFRONT", "commitmentDisplayPrice" : "1.99", "displayPrice" : "1.99", "internalID" : "21C9C75B", "isEnabled" : true } ], "codeOffers" : [ ], "displayPrice" : "1.99", "familyShareable" : false, "groupNumber" : 1, "internalID" : "D1A384C1", "introductoryOffer" : { "billingPlanType" : "BILLED_UPFRONT", "displayPrice" : "0.99", "internalID" : "F0651A66", "numberOfPeriods" : 1, "paymentMode" : "payUpFront", "subscriptionPeriod" : "P1M" }, "introductoryOffers" : [ { "billingPlanType" : "BILLED_UPFRONT", "displayPrice" : "0.99", "internalID" : "F0651A66", "numberOfPeriods" : 1, "paymentMode" : "payUpFront", "subscriptionPeriod" : "P1M" } ], "localizations" : [ { "description" : "", "displayName" : "", "locale" : "en_US" } ], "productID" : "premium_monthly", "recurringSubscriptionPeriod" : "P1M", "referenceName" : "premiume monthly", "subscriptionGroupID" : "84E94B59", "type" : "RecurringSubscription", "winbackOffers" : [ ] } ] }, { "id" : "39607B86", "localizations" : [ ], "name" : "basic_group", "subscriptions" : [ { "adHocOffers" : [ ], "billingPlans" : [ { "billingPlanType" : "BILLED_UPFRONT", "commitmentDisplayPrice" : "0.99", "displayPrice" : "0.99", "internalID" : "0FAC3C7D", "isEnabled" : true } ], "codeOffers" : [ ], "displayPrice" : "0.99", "familyShareable" : false, "groupNumber" : 1, "internalID" : "01ABB5D2", "introductoryOffers" : [ ], "localizations" : [ { "description" : "", "displayName" : "", "locale" : "en_US" } ], "productID" : "basic_monthly", "recurringSubscriptionPeriod" : "P1M", "referenceName" : "basic monthly", "subscriptionGroupID" : "39607B86", "type" : "RecurringSubscription", "winbackOffers" : [ ] } ] } ], "subscriptionSuiteGroups" : [ ], "version" : { "major" : 6, "minor" : 3 } }
0
0
180
1w
"Sandbox Apple Account" Developer Setting Does Not Work
I am trying to test a sandbox account for an in-app subscription. It will not work. When I try to check out in my app, I'm told... 2026-07-08 14:41:59.282977-0700 PlainSite[1364:48033] [Default] [StoreKit] Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=500 "Unhandled exception" UserInfo={NSUnderlyingError=0x2835d21f0 {Error Domain=AMSErrorDomain Code=100 "Authentication Failed" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=AMSErrorDomain Code=2 \"An unknown error occurred. Please try again.\" UserInfo={NSLocalizedDescription=An unknown error occurred. Please try again.}", "Error Domain=AMSServerErrorDomain Code=-5000 \"(null)\" UserInfo={failureType=-5000, m-allowed=false, pings=(\n), cancel-purchase-batch=true, customerMessage=Check the account information you entered and try again.}" ), NSLocalizedDescription=Authentication Failed, NSLocalizedFailureReason=The authentication failed.}}, NSLocalizedFailureReason=An unknown error occurred, NSLocalizedDescription=Unhandled exception} [CreateAccountView] purchaseForSignup threw: userCancelled This is false. The user (me) did not cancel. This is with me manually typing in the sandbox credentials as the Apple ID and password at the point of completing the transaction on both iOS 15 and iOS 26. So I try to make sure that my sandbox account is properly set in iOS 26's Settings -> Developer -> Sandbox Apple Account screen. It says Sign In. Then it says "Apple Account Sign in Requested". What does this actually mean? Who knows. It could mean my App Store Connect credentials are what it wants so that it can query which sandbox accounts are available to use—after all, that is where they are set up. It could also mean that you should type in the sandbox account's credentials directly because a sandbox account is basically a fake Apple ID. I try both. Neither works. No matter what I do, it just goes back to the Developer view and says "Sign In". Have I signed in? I don't know. Maybe, but probably not, given that nothing works. Is the problem that I didn't confirm the sandbox account's e-mail address? No. It doesn't work before or after I've confirmed the e-mail. Is the problem that I don't have two-factor authentication on for the sandbox account? No. It doesn't work whether or not two-factor authentication is enabled. I am not the only one having this problem. People on a certain Reddit thread I'm for some reason not allowed to link to here (sandbox_accounts_simulator_help) have been having it for the past year it looks like, except they got it to work on a real device, and I'm using an iPhone 17, which is a real device, and it doesn't work. This is the third bug in Apple's code I've found in the past couple of weeks that is preventing me from getting my app published and it's getting frustrating. Any assistance would be appreciated. Fix your code, Apple.
2
0
295
1w
Product.SubscriptionInfo.Status.all returns empty for accounts with an active auto-renewable subscription
Summary: We gate premium access on the renewal status returned by Product.SubscriptionInfo.Status.all, following the pattern in your Implementing a store in your app using the StoreKit API sample (CustomerEntitlements.checkCurrentStatuses()). In production we are seeing a subset of users whose Status.all yields zero statuses, even though they hold an active subscription with a future expiration date (according to our own persisted state). This causes us to incorrectly treat them as unsubscribed. How we read status: func currentSubscriptionStatuses() async -> [SubscriptionStatusInfo] { await Product.SubscriptionInfo.Status.all .collect() .flatMap(.1) .compactMap(SubscriptionStatusInfo.init(skStatus:)) } The compactMap only drops entries failing case .verified. In the affected cases Status.all itself emits no (groupID, statuses) pairs at all - the sequence is empty, not filtered. Affected population: Previously had an active paid subscription (our own persisted state shows pro with an expiry date in the future). Not new installs. Questions: Under what conditions can Product.SubscriptionInfo.Status.all return an empty sequence for an Apple Account that currently holds an active auto-renewable subscription (e.g. not signed into the App Store, StoreKit not yet initialized at launch, offline, renewal in flight, Family Sharing)? Is an empty result from Status.all ever authoritative ("no subscription"), or must it always be treated as inconclusive and never used to revoke access? Is there a recommended way to distinguish "no subscription for this account" from "status temporarily unavailable" (e.g. a signal for no signed-in App Store account, or a readiness/error path)? Does Status.all guarantee it reflects a signed-in account context, and what is the expected behavior when the device has no active App Store account at call time?
0
2
214
1w
Our sandbox accounts don't work now.
Our sandbox accounts don't work now. We are testing our IAP product now, so we need our sandbox accounts to be logged in, for purchaise test. Settings -> Developer -> Sandbox Apple Account screen - > log in : Not working Logged out status -> test app -> purchasing IAP product : Not working our 4 members of dev team have same problem now.
0
0
201
2w
In-App Purchase Resources
General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video
Replies
0
Boosts
0
Views
513
Activity
Jun ’26
**Subject:** AdAttributionKit Postback URL Registration Questions for Existing SKAdNetwork Ad Networks
Here's a much shorter version with just the questions: Hi Apple Developer Support, We're an ad network already registered for SKAdNetwork and are integrating AdAttributionKit. We have a few questions regarding postback URL registration: Do we need to register a separate postback URL for AdAttributionKit, or is our existing SKAdNetwork postback URL reused automatically? If a separate AAK registration is required, can the AAK postback URL be the same as our existing SKAN postback URL, or does Apple require a different URL/path? If the same URL is used for both, are AAK postbacks always delivered as a JWS payload while SKAN postbacks continue to use the existing JSON format? When WWDC states that existing SKAdNetwork ad networks require "no further enrollment," does that refer only to reusing the existing ad network ID, or also to reusing the registered postback URL? Is the Developer Mode AdAttributionKit testing flow the correct way to validate ad network postback delivery? Thanks!
Replies
0
Boosts
0
Views
13
Activity
4h
Urgent: AppStore.requestReview(in:) appears to show rating prompts too frequently in production
Hello, We are requesting urgent help with what appears to be repeated presentation of the native in-app rating prompt in our production app, Jízdní řády IDOS: https://apps.apple.com/cz/app/j%C3%ADzdn%C3%AD-%C5%99%C3%A1dy-idos/id473503749 This issue is materially affecting our App Store rating and user trust. We estimate that it has resulted in dozens of negative reviews explicitly mentioning that the native “Rate this app” prompt is shown repeatedly or “all the time”. The actual impact on our overall rating is difficult to determine, as not all affected users explicitly reference this issue in their reviews. The affected builds are App Store production builds, not Debug builds or TestFlight builds. Initially, we used the deprecated SKStoreReviewController API. We suspected that this could be the cause, so we migrated to the current API on iOS 18 and later: import StoreKit import UIKit @MainActor static func requestReview(from view: UIView) { if #available(iOS 18.0, *), let scene = view.window?.windowScene { AppStore.requestReview(in: scene) } else if #available(iOS 14.0, *), let scene = view.window?.windowScene { SKStoreReviewController.requestReview(in: scene) } else { SKStoreReviewController.requestReview() } } Unfortunately, this change did not resolve the issue. Users have continued to report that the native rating prompt appears repeatedly in the App Store version of our app. We understand that StoreKit controls whether the prompt is actually presented and should enforce the documented display limit. However, the volume and consistency of user feedback make us concerned that this limit may not be reliably enforced in our case. We have also found a similar report from another developer: https://developer.apple.com/forums/thread/827331 Could you please clarify: Can SKStoreReviewController.requestReview() or AppStore.requestReview(in:) result in the prompt being shown more than three times within 365 days in a shipping App Store build? Is there any known issue, limitation, or behavioural difference affecting either SKStoreReviewController.requestReview(in:) or AppStore.requestReview(in:) that could explain repeated presentation of the native rating prompt in a shipping App Store build? Could the SwiftUI RequestReviewAction API behave differently from AppStore.requestReview(in:) with respect to enforcing the presentation limit? Would migrating to RequestReviewAction be expected to resolve this issue? Our application is predominantly UIKit, so adopting the SwiftUI API would require non-trivial integration work. More importantly, we do not want to use production users to test another implementation while the issue may continue to negatively affect our rating. We would therefore appreciate guidance on the expected behaviour and the recommended implementation before making this change. We can provide affected app versions, iOS versions, device details, screenshots, and examples of user feedback immediately if useful. Thank you.
Replies
1
Boosts
0
Views
32
Activity
13h
Approved in-app purchase not available in production — StoreKit returns no product (live app, all TN3188 checks pass)
Live App Store app; approved non-consumable in-app purchase is not returned by production StoreKit, so customers cannot buy it. Product.products(for:) returns nothing; the paywall shows "purchases aren't available." ~15 days since first release (2026-07-06). Reproduced on two devices with two different Apple IDs. A redeemed promo code also did not deliver it. Important: my IAP status is APPROVED (not "Waiting for Review"), so this differs from some recent threads — yet the product still isn't served in production. Verified per TN3188 (all pass): product ID matches App Store Connect exactly; status Approved; Availability = all 175 regions; priced (base USD); listed on the public App Store product page; Paid Apps Agreement, banking, and tax forms all Active; no local .storekit config in the build; the product returns correctly from our provider's (RevenueCat) servers, so the empty result is specifically the on-device production StoreKit fetch. This coincides with the recent App Store Connect incident affecting in-app-purchase submission, and there's a cluster of similar reports this week (threads 838171, 838435, 835770, and "In-App Subscriptions stuck in 'Waiting for Review' after App Store Connect maintenance"). It looks like a server-side issue where the product never propagated to production StoreKit despite showing Approved. Environment: Expo/EAS, React Native 0.81, StoreKit 2 via react-native-purchases 10.3.0. Devices: iPhone 15 Pro Max (iOS 27.0), iPhone 16 Pro Max (iOS 26.5). Open Developer Support case: 102936978821. Is there any developer-side step remaining, or does this require Apple to re-process / re-propagate the product server-side? Any guidance appreciated.
Replies
0
Boosts
0
Views
47
Activity
1d
Production subscription remains Active after failed payment and no funds deducted
Hello, We are investigating an auto-renewable monthly subscription in the Production environment. Timeline and observed behavior: On June 29, 2026, the user initiated the first subscription purchase. The Apple Account used WeChat Pay as its payment method. The WeChat charge failed because the balance was insufficient, and no funds were deducted from any available payment source. Nevertheless, StoreKit returned a verified transaction, the subscription purchase succeeded in the app, and App Store Connect Sales Analytics reports proceeds for the purchase. We grant entitlement based only on Apple's signed transaction and subscription status, so the user currently has access. As of July 20, 2026, Get All Subscription Statuses from App Store Server API returns: environment: Production status: 1 (Active) expiresDate: 2026-07-29T03:37:11Z autoRenewStatus: 1 no gracePeriodExpiresDate no revocationDate no expirationIntent no billing retry indication Our App Store Server Notifications endpoint has received only: SUBSCRIBED / INITIAL_BUY We have not received DID_FAIL_TO_RENEW, EXPIRED, REFUND, or REVOKE. Questions: Is it expected for Apple to issue a valid production initial-purchase transaction and report proceeds even when the underlying WeChat Pay charge failed and no money was deducted? Could this be an unpaid Apple Account balance or delayed settlement that is invisible to the developer? While the Server API returns status 1, should the developer continue granting entitlement until expiresDate? Is there another authoritative App Store Server API or signed field that indicates the payment has not actually been collected? If renewal or collection later fails, when should we expect DID_FAIL_TO_RENEW or a change to billing retry or expired status? We have intentionally omitted transaction IDs and account identifiers from this public post. I can provide them privately to Apple Support if needed. Thanks
Replies
0
Boosts
0
Views
45
Activity
3d
requestReview() prompting repeatedly
We're getting user reports that the App Store rating prompt appears repeatedly — one user says they're prompted roughly every day, and that they still get the prompt after they've already left a rating. This contradicts the documented behavior, so I want to check whether others are seeing the same thing or whether there's a known regression. What the docs say should happen The system limits display to 3 occurrences per app within a 365-day period. For a user who has already rated/reviewed, StoreKit should only display again if the app version is new and more than 365 days have passed since their previous review. Has anyone else experience it?
Replies
2
Boosts
0
Views
313
Activity
5d
SKTestSession.buyProduct(identifier: options:) throws error
Hi, Overview I am trying to write a unit test case to buy a storekit product. SKTestSession.buyProduct(identifier: options:) throws the error StoreKit.StoreKitError.notEntitled Testcase Code @Test func example() async throws { let session = try SKTestSession(configurationFileNamed: "VehicleStore") session.disableDialogs = true session.clearTransactions() do { let transaction = try await session.buyProduct(identifier: "nonconsumable.car", options: []) print(transaction) } catch { // Throws StoreKit.StoreKitError.notEntitled print("Error: \(error)") } } Storekit configuration file Note In-App purchases capability is added StoreKit configuration file is used in testcase Environment: macOS 26.5.2 (25F84) Xcode 26.6 (17F113)
Replies
5
Boosts
0
Views
364
Activity
5d
Refund requests failing in production
We offer an in-app way for customers to request an Apple refund for an auto-renewable subscription using StoreKit2. Everything worked during testing and verification in the Sandbox and TestFlight phases, but now consistently fails in Production. We present the refund sheet on a button press: .refundRequestSheet(for: transactionID, isPresented: $isPresenting) { result in switch result { case .success(let status): // .success / .userCancelled handled here case .failure(let error): // -> .failed for every user } } We log the outcome of all the requests, success and cancel behaves as expected. Since RefundRequestError only has .duplicateRequest .failed and the localizedDescription is generic, we don't know why it is failing. We have already checked that the transaction are for verified, not revoked, non-upgraded and active subscriptions. The issue only happens in Production. Is there any way to get more information about why a refund request fails or what other configuration needs to verified for this to work? Is there an eligibility window or other non-specified limit that might result in these errors?
Replies
1
Boosts
0
Views
309
Activity
5d
StoreKit 2 currentEntitlements persists after Sandbox Purchase History reset in TestFlight
I am testing a StoreKit 2 non-consumable IAP through TestFlight. Product ID: com.metabolla.plus.lifetime Type: Non-Consumable Environment: TestFlight / Sandbox Transaction.currentEntitlements keeps returning an active entitlement for this product even after: configuring a Sandbox Apple Account clearing Sandbox Purchase History reinstalling the app rebooting the device Important detail: the first TestFlight purchase was completed before configuring the Sandbox Apple Account on the device. If I temporarily change the Product ID in code, the entitlement disappears, so the issue seems tied to the original Product ID/account/receipt. Question: Can a non-consumable TestFlight purchase made before Sandbox Apple Account configuration remain associated with the original TestFlight/Apple ID identity? Is there any supported way to clear this entitlement for testing?
Replies
4
Boosts
0
Views
783
Activity
6d
SKPaymentQueue.restoreCompletedTransactions returns 0 transactions for auto-renewable subscriptions on iOS 26.4
Is anybody else seeing this? Since iOS 26.4, calling SKPaymentQueue.restoreCompletedTransactions() no longer returns any transactions for active auto-renewable subscriptions. The success callback is invoked correctly, but the transactions array is empty. The same device and the same Apple ID return the expected transactions on iOS 26.3.1 and earlier. Environment Affected: iOS 26.4.x (confirmed on 26.4.2) Working: iOS 26.3.1 and earlier Product type: Auto-renewable subscriptions Deployment target: iOS 14.0 Steps to reproduce Have an active auto-renewable subscription on an Apple ID (sandbox or production) Run on a device with iOS 26.4 or later Call SKPaymentQueue.default().restoreCompletedTransactions() (or the equivalent via a wrapper such as RMStore) Observe the paymentQueueRestoreCompletedTransactionsFinished delegate callback Expected behaviour The delegate receives the restored transactions via paymentQueue(_:updatedTransactions:) before paymentQueueRestoreCompletedTransactionsFinished is called, as documented. Actual behaviour paymentQueueRestoreCompletedTransactionsFinished is called immediately with no prior transaction updates. The transactions array is empty.
Replies
1
Boosts
1
Views
266
Activity
6d
App Subscription "Confirm with Apple Device" UI
My tvOS app includes the purchase of subscriptions, and I am updating the code with Storekit 2.0. I have seen other apps that present the "Confirm with Apple Device" UI upon selection of a product, but for me I only ever see an alert confirming the purchase. I have tested this using Xcode storekit data and a sandbox account. I have also attempted using Storekit views and passing the UIWindowScene to the purchase(confirmIn: ) parameter, but neither made any difference. Is there some limitation that prevents that UI from showing in debug builds?
Replies
1
Boosts
0
Views
303
Activity
6d
App approved and released, but auto-renewable subscriptions remain "Waiting for Review" and StoreKit returns no products
M y app was approved and is now live on the App Store, but all four auto-renewable subscriptions are still Waiting for Review in App Store Connect. Because of this, the production app's StoreKit 2 call to Product.products(for:) returns 0 products, and users see: "No subscription products were returned by the App Store." There are no metadata errors or warnings—only Waiting for Review. My questions are: Is it normal for an app to be released before its subscriptions are approved? While subscriptions are in Waiting for Review, is it expected that Product.products(for:) returns an empty array? Has anyone experienced this, and how long did it take for the subscriptions to be approved after the app was already live? I've attached: App Store Connect screenshot showing all four subscriptions in Waiting for Review. App screenshot showing the "No subscription products were returned by the App Store." message. Any insight would be greatly appreciated. Thanks!
Replies
0
Boosts
0
Views
96
Activity
6d
Production StoreKit silently omits one approved auto-renewable subscription product — sandbox returns it correctly, sudden onset 2026-05-09
Hi all, Reporting an active production issue in case anyone else is seeing the same pattern, or has insight into what could cause this. Symptom As of 2026-05-09 morning, one specific auto-renewable subscription product is silently absent from Production StoreKit responses on our live App Store build. The product is still 'Approved' in App Store Connect, all metadata is intact, no error code is returned — the product simply does not appear in the products array. The other 3 products in the same subscription group continue to work normally. 100% of production users are affected. Setup App: live on App Store, version 1.0.0 (build 8) Subscription group with 4 auto-renewable products: standard_monthly_799 ✅ returns correctly standard_annual_6999 ✅ returns correctly unlimited_monthly_1299 ❌ MISSING from production response unlimited_annual_9999 ✅ returns correctly SDK: purchases_flutter (RevenueCat) → StoreKit Same physical device, same code, same RC config behaves correctly in Sandbox — all 4 products are returned and a sandbox purchase of unlimited_monthly_1299 succeeds. Timeline 2026-05-08: working correctly, purchases succeeding normally 2026-05-09 morning: product silently disappears from production StoreKit responses No app update was submitted between those dates No App Store Connect changes were made Onset was simultaneous across all production users at one timestamp What I've verified App Store Connect: Product status: Approved All territories enabled, all prices configured (no N/A in any territory) Subscription group correctly contains all 4 products No 'Submit for Review' pending changes Product attached to live app version 1.0.0 (8) Tax category: Match to parent app Family Sharing: Off (consistent with the working products) Paid Applications Agreement: Status: Active Banking and Tax forms: Active RevenueCat dashboard: All 4 products show Store Status: Approved Default offering contains all 4 packages iOS attachment for the affected product is intact No warnings or sync errors Sandbox StoreKit (today): flutter run (debug) on physical device → all 4 products returned flutter run --release on physical device → all 4 products returned Sandbox purchase of unlimited_monthly_1299 succeeds Production StoreKit (today, broken): App Store-downloaded 1.0.0 (8) on multiple users' devices Multiple Apple IDs / multiple devices / multiple regions — all reproduce Only unlimited_monthly_1299 affected; other 3 products fine Why this looks server-side Sudden simultaneous onset across all users No code or config change preceded onset Sandbox unaffected, only Production affected Single product affected, not the whole subscription group or app No error returned — silent omission only Cannot reproduce with locally signed builds, only with App Store-distributed binary This pattern is consistent with a server-side product indexing or fronting issue specific to one product in Production StoreKit. As a developer I don't have visibility into Apple's product-serving infrastructure to investigate further — looking for guidance from anyone who has seen this before. Questions for the community Has anyone else seen a single auto-renewable subscription silently drop out of Production StoreKit responses while remaining Approved in ASC, with no error code returned? Is there any internal product-state flag (beyond what's exposed in the ASC UI) that could cause Production StoreKit to silently omit a product? Anything similar to a hidden 'review hold' or 'price tier reconciliation' state? Has the asymmetry between RevenueCat package identifiers (Standard uses RC's $rc_monthly/$rc_annual default identifiers, Premium uses custom premium_monthly/premium_annual identifiers) ever been implicated in this kind of failure? RC support has been notified, but worth asking publicly. For anyone who has resolved a similar issue: what action ended up clearing it — ASC re-save, RC re-sync, Apple Support escalation, or did it self-resolve after Apple-side cache propagation? Filings in progress ASC Contact Us ticket: filed Apple DTS technical incident: filed RevenueCat support ticket: filed Feedback Assistant report: in progress Will update this thread with the resolution path once we have one. Thanks, — Kin Pong Lo (developer, Alice: AI English Tutor)
Replies
1
Boosts
0
Views
380
Activity
6d
Guideline 3.1.1 – Consumable IAPs rejected after binary approved; asked for “new binary” though 1.8 already submitted
Hi, We received App Review feedback under Guideline 3.1.1 for our in-app purchases, and we’d appreciate guidance on the expected next step. What we submitted; We created and completed metadata for the new consumable IAPs (pricing, availability, review screenshots, localizations). We uploaded and submitted app version 1.8 with a recent binary (build processed/VALID in App Store Connect). We also submitted the consumable IAPs for review. Outcome: App version 1.8 was approved (currently Pending Developer Release). The consumable IAPs were returned with Developer Action Needed. Our confusion We already uploaded/submitted a new binary (1.8) for this release, and the consumable purchase flows are implemented in that binary (Store / offers). The app binary itself was approved, but the consumable IAPs were rejected with a request for another new binary. For a first-time expansion from Non-Consumable-only to Consumables, is a separate / subsequent binary submission always required even if the approved version already contains the purchase UI?
Replies
1
Boosts
0
Views
116
Activity
1w
AppStore.ageRatingCode always returns 0 on real device — is this expected behavior?
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.
Replies
1
Boosts
0
Views
251
Activity
1w
StoreKit Product Retrieval Issue During App Review
Hello, We are contacting you regarding an issue we are currently experiencing during the App Review process related to In-App Purchases and StoreKit product retrieval. After extensive internal testing and investigation, we believe the behavior we are seeing is identical to the issue discussed in the following Apple Developer Forum thread: https://developer.apple.com/forums/thread/827016 Our application was rejected under Guideline 2.1 - Performance because the subscription plans reportedly failed to load during review. According to the review notes, the In-App Purchase product list appeared empty in the review environment, which prevented the paywall from loading correctly. We would like to provide additional technical context because, despite significant testing efforts on our side, we have been unable to reproduce this behavior outside of the App Review environment. The exact same binary that was reviewed by App Review has been thoroughly tested by us through TestFlight on multiple physical devices, including iPhone and iPad devices, using multiple Sandbox tester accounts and different network conditions. In all of our tests, the subscription system functions correctly and consistently. Specifically, we verified that: StoreKit successfully retrieves all configured subscription products RevenueCat offerings load correctly without timeout or empty states Localized pricing information is displayed properly Subscription packages appear correctly in the paywall UI Purchase flows complete successfully Restore purchases functionality works correctly Products are returned both on cold launch and repeated application launches The issue does not occur intermittently in TestFlight or Sandbox testing on our side We also carefully reviewed our App Store Connect configuration and verified the following items multiple times: All In-App Purchase subscriptions are attached to the submitted app version Product identifiers used in the application code exactly match the identifiers configured in App Store Connect All products are marked as “Cleared for Sale” Paid Applications Agreement has been accepted and remains active Tax and banking information are complete and active Subscription localization settings are configured properly Pricing information is active and visible The products are available in the storefronts being tested The submitted binary is identical to the binary tested successfully through TestFlight Additionally, we implemented defensive handling in the application to minimize the impact of temporary StoreKit failures. The application now includes: Retry logic for offerings retrieval Graceful fallback handling for empty offerings Protection against infinite loading states Additional RevenueCat and StoreKit logging UI fallbacks when products temporarily fail to load Despite these safeguards, the review feedback still indicates that the products are not being returned in the App Review environment. At this point, because the issue cannot be reproduced externally and only appears during App Review, we suspect there may be an intermittent or environment-specific issue affecting StoreKit product retrieval in the review sandbox environment. One important detail is that the exact same build consistently works in TestFlight immediately before and after submission. This makes the behavior particularly difficult for us to diagnose because there appears to be no configuration difference between our successful tests and the App Review scenario. We also understand from Apple documentation and previous App Review communication that In-App Purchases are tested within an Apple-provided sandbox environment. Based on the evidence currently available to us, the failure appears to occur specifically within that review sandbox process rather than within the application logic itself. If possible, we would greatly appreciate assistance with the following: Verifying whether StoreKit product retrieval is functioning correctly in the App Review sandbox environment Confirming whether the review device successfully established communication with App Store sandbox services Providing any available diagnostic logs related to the failed product request Confirming whether the product identifiers were visible to StoreKit during review Sharing any guidance on how we may reproduce the App Review behavior locally Clarifying whether there are known intermittent issues affecting StoreKit product loading during App Review We are fully committed to resolving the issue and ensuring complete compliance with App Store requirements. However, because the issue currently appears environment-specific and non-reproducible from our side, we are struggling to determine what additional changes are necessary. If there are any additional diagnostics, logging methods, StoreKit verification steps, or App Review recommendations you would like us to implement, we would be happy to do so immediately. Thank you very much for your assistance, support, and time. We sincerely appreciate your help in investigating this issue. Best regards, Mert Akgün
Replies
3
Boosts
1
Views
398
Activity
1w
In App Purchase UI difference for tvOS
We're seeing differences in the purchase dialog and overall presentation when testing with Sandbox accounts compared to commercially available apps. Are these UI differences are expected and are simply a characteristic of the Sandbox testing environment, or if there are any configuration requirements that affect the purchase sheet appearance? It would be helpful to know whether developers should expect the production purchase UI to match App Store apps once the app is distributed through TestFlight/App Store, or if there are additional factors involved. Sandbox UI Expected UI
Replies
0
Boosts
0
Views
183
Activity
1w
Subscription bundle & suite testing failure on XCode 27 Beta 3
I'm quite excited about the newly announced bundle and suite feature and trying to test the new Subscription Bundle type introduced in the recent Xcode Beta (using a local .storekit configuration file). I have set up: A local .storekit file. Inside it, I configured a Subscription Bundle with the ID "bundle". This bundle is linked to two internal auto-renewable subscriptions in the same file. The StoreKit configuration is active in my Scheme options. When I try to fetch a standard auto-renewable subscription ID, it works perfectly. However, when I try to fetch the "bundle" ID, the API returns successfully but with an empty array [] (no errors thrown). Is there a different way to query/fetch the new Subscription Bundle type in StoreKit 2, or is local testing for bundles not yet supported in the simulator in this beta? My sample code import StoreKit @MainActor class StoreManager: ObservableObject { @Published var products: [Product] = [] func fetchProducts() async { do { // "bundle" is defined in our local .storekit file as a SubscriptionBundle self.products = try await Product.products(for: ["bundle"]) print("Fetched products: \(self.products.map { $0.id })") } catch { print("Fetch error: \(error)") } } } struct ContentView: View { @StateObject private var store = StoreManager() var body: some View { VStack { if store.products.isEmpty { Text("Stuck Loading: Product not found.") } else { ForEach(store.products, id: \.id) { product in Text("Found: \(product.displayName) - \(product.displayPrice)") } } } .task { await store.task { await store.fetchProducts() } } } } My storekit "appPolicies" : { "eula" : "", "policies" : [ { "locale" : "en_US", "policyText" : "", "policyURL" : "" } ] }, "identifier" : "2B237494", "nonRenewingSubscriptions" : [ ], "products" : [ ], "settings" : { "_askToBuyEnabled" : false, "_billingGracePeriodEnabled" : false, "_billingIssuesEnabled" : false, "_disableDialogs" : false, "_failTransactionsEnabled" : false, "_locale" : "en_US", "_renewalBillingIssuesEnabled" : false, "_storefront" : "USA", "_storeKitErrors" : [ ], "_timeRate" : 0 }, "subscriptionBundleGroups" : [ { "id" : "EE1EB207", "localizations" : [ ], "name" : "bundle_group", "subscriptions" : [ { "displayPrice" : "0.99", "duration" : "P1M", "groupNumber" : 1, "internalID" : "84A95B47", "introductoryOffers" : [ { "billingPlanType" : "BILLED_UPFRONT", "internalID" : "DD9208A6", "numberOfPeriods" : 1, "paymentMode" : "free", "subscriptionPeriod" : "P1W" } ], "isFamilyShareable" : false, "linkedSubscriptions" : [ { "internal" : "D1A384C1" }, { "internal" : "01ABB5D2" } ], "localizations" : [ { "description" : "", "displayName" : "", "locale" : "en_US" } ], "productID" : "bundle", "referenceName" : "Awesome Bundle", "subscriptionGroupID" : "EE1EB207", "type" : "SubscriptionBundle" } ] } ], "subscriptionGroups" : [ { "id" : "84E94B59", "localizations" : [ ], "name" : "premium_group", "subscriptions" : [ { "adHocOffers" : [ ], "billingPlans" : [ { "billingPlanType" : "BILLED_UPFRONT", "commitmentDisplayPrice" : "1.99", "displayPrice" : "1.99", "internalID" : "21C9C75B", "isEnabled" : true } ], "codeOffers" : [ ], "displayPrice" : "1.99", "familyShareable" : false, "groupNumber" : 1, "internalID" : "D1A384C1", "introductoryOffer" : { "billingPlanType" : "BILLED_UPFRONT", "displayPrice" : "0.99", "internalID" : "F0651A66", "numberOfPeriods" : 1, "paymentMode" : "payUpFront", "subscriptionPeriod" : "P1M" }, "introductoryOffers" : [ { "billingPlanType" : "BILLED_UPFRONT", "displayPrice" : "0.99", "internalID" : "F0651A66", "numberOfPeriods" : 1, "paymentMode" : "payUpFront", "subscriptionPeriod" : "P1M" } ], "localizations" : [ { "description" : "", "displayName" : "", "locale" : "en_US" } ], "productID" : "premium_monthly", "recurringSubscriptionPeriod" : "P1M", "referenceName" : "premiume monthly", "subscriptionGroupID" : "84E94B59", "type" : "RecurringSubscription", "winbackOffers" : [ ] } ] }, { "id" : "39607B86", "localizations" : [ ], "name" : "basic_group", "subscriptions" : [ { "adHocOffers" : [ ], "billingPlans" : [ { "billingPlanType" : "BILLED_UPFRONT", "commitmentDisplayPrice" : "0.99", "displayPrice" : "0.99", "internalID" : "0FAC3C7D", "isEnabled" : true } ], "codeOffers" : [ ], "displayPrice" : "0.99", "familyShareable" : false, "groupNumber" : 1, "internalID" : "01ABB5D2", "introductoryOffers" : [ ], "localizations" : [ { "description" : "", "displayName" : "", "locale" : "en_US" } ], "productID" : "basic_monthly", "recurringSubscriptionPeriod" : "P1M", "referenceName" : "basic monthly", "subscriptionGroupID" : "39607B86", "type" : "RecurringSubscription", "winbackOffers" : [ ] } ] } ], "subscriptionSuiteGroups" : [ ], "version" : { "major" : 6, "minor" : 3 } }
Replies
0
Boosts
0
Views
180
Activity
1w
"Sandbox Apple Account" Developer Setting Does Not Work
I am trying to test a sandbox account for an in-app subscription. It will not work. When I try to check out in my app, I'm told... 2026-07-08 14:41:59.282977-0700 PlainSite[1364:48033] [Default] [StoreKit] Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=500 "Unhandled exception" UserInfo={NSUnderlyingError=0x2835d21f0 {Error Domain=AMSErrorDomain Code=100 "Authentication Failed" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=AMSErrorDomain Code=2 \"An unknown error occurred. Please try again.\" UserInfo={NSLocalizedDescription=An unknown error occurred. Please try again.}", "Error Domain=AMSServerErrorDomain Code=-5000 \"(null)\" UserInfo={failureType=-5000, m-allowed=false, pings=(\n), cancel-purchase-batch=true, customerMessage=Check the account information you entered and try again.}" ), NSLocalizedDescription=Authentication Failed, NSLocalizedFailureReason=The authentication failed.}}, NSLocalizedFailureReason=An unknown error occurred, NSLocalizedDescription=Unhandled exception} [CreateAccountView] purchaseForSignup threw: userCancelled This is false. The user (me) did not cancel. This is with me manually typing in the sandbox credentials as the Apple ID and password at the point of completing the transaction on both iOS 15 and iOS 26. So I try to make sure that my sandbox account is properly set in iOS 26's Settings -> Developer -> Sandbox Apple Account screen. It says Sign In. Then it says "Apple Account Sign in Requested". What does this actually mean? Who knows. It could mean my App Store Connect credentials are what it wants so that it can query which sandbox accounts are available to use—after all, that is where they are set up. It could also mean that you should type in the sandbox account's credentials directly because a sandbox account is basically a fake Apple ID. I try both. Neither works. No matter what I do, it just goes back to the Developer view and says "Sign In". Have I signed in? I don't know. Maybe, but probably not, given that nothing works. Is the problem that I didn't confirm the sandbox account's e-mail address? No. It doesn't work before or after I've confirmed the e-mail. Is the problem that I don't have two-factor authentication on for the sandbox account? No. It doesn't work whether or not two-factor authentication is enabled. I am not the only one having this problem. People on a certain Reddit thread I'm for some reason not allowed to link to here (sandbox_accounts_simulator_help) have been having it for the past year it looks like, except they got it to work on a real device, and I'm using an iPhone 17, which is a real device, and it doesn't work. This is the third bug in Apple's code I've found in the past couple of weeks that is preventing me from getting my app published and it's getting frustrating. Any assistance would be appreciated. Fix your code, Apple.
Replies
2
Boosts
0
Views
295
Activity
1w
Product.SubscriptionInfo.Status.all returns empty for accounts with an active auto-renewable subscription
Summary: We gate premium access on the renewal status returned by Product.SubscriptionInfo.Status.all, following the pattern in your Implementing a store in your app using the StoreKit API sample (CustomerEntitlements.checkCurrentStatuses()). In production we are seeing a subset of users whose Status.all yields zero statuses, even though they hold an active subscription with a future expiration date (according to our own persisted state). This causes us to incorrectly treat them as unsubscribed. How we read status: func currentSubscriptionStatuses() async -> [SubscriptionStatusInfo] { await Product.SubscriptionInfo.Status.all .collect() .flatMap(.1) .compactMap(SubscriptionStatusInfo.init(skStatus:)) } The compactMap only drops entries failing case .verified. In the affected cases Status.all itself emits no (groupID, statuses) pairs at all - the sequence is empty, not filtered. Affected population: Previously had an active paid subscription (our own persisted state shows pro with an expiry date in the future). Not new installs. Questions: Under what conditions can Product.SubscriptionInfo.Status.all return an empty sequence for an Apple Account that currently holds an active auto-renewable subscription (e.g. not signed into the App Store, StoreKit not yet initialized at launch, offline, renewal in flight, Family Sharing)? Is an empty result from Status.all ever authoritative ("no subscription"), or must it always be treated as inconclusive and never used to revoke access? Is there a recommended way to distinguish "no subscription for this account" from "status temporarily unavailable" (e.g. a signal for no signed-in App Store account, or a readiness/error path)? Does Status.all guarantee it reflects a signed-in account context, and what is the expected behavior when the device has no active App Store account at call time?
Replies
0
Boosts
2
Views
214
Activity
1w
Our sandbox accounts don't work now.
Our sandbox accounts don't work now. We are testing our IAP product now, so we need our sandbox accounts to be logged in, for purchaise test. Settings -> Developer -> Sandbox Apple Account screen - > log in : Not working Logged out status -> test app -> purchasing IAP product : Not working our 4 members of dev team have same problem now.
Replies
0
Boosts
0
Views
201
Activity
2w