Does App Review accept multiple In-App Purchases in the same app sharing an identical display name (for example ten non-renewing subscriptions all named 'Example Digital', differing only in price and duration)? The purchase sheet always shows the price alongside the name. App Store Connect Help documents a 2–30 character limit for the display name but states no uniqueness rule.

Can an In-App Purchase that has reached the 'Approved' state ever be deleted from App Store Connect, either in the UI or through the App Store Connect API? App Store Connect Help documents no deletion procedure and no 'deleted' status. If deletion is possible, is it blocked while the product has existing purchases, or while it is still available for sale?

Does the App Store send a CONSUMPTION_REQUEST App Store Server Notification when a customer requests a refund for a non-renewing subscription? The documentation is inconsistent: the notificationType page lists only 'a consumable In-App Purchase or auto-renewable subscription', beginRefundRequest(in:) mentions only consumables, but the Send Consumption Information endpoint states it applies to 'any product type (consumable, non-consumable, non-renewing subscription, or auto-renewable subscription)'. Which is correct for a non-renewing subscription sold in the Saudi Arabia storefront?

On both iOS & macOS 27.2 Beta 2 the call: let token = try await MusicDataRequest.tokenProvider.developerToken(options: [.ignoreCache]) is throwing an error. I can reproduce this on all of my 27.2 Beta 2 devices and I have users worldwide reaching out to me with this issue. The error that gets thrown is: Unknown error "Error returned from daemon: Error Domain=com.apple.accounts Code=9 "(null)"" Have raised FB24895830.

For our app, we saved a sandbox App Store Server Notifications URL with V2 enabled and independently read the configuration back. A subsequent test-notification request returned HTTP 404 / 4040007. An authenticated sandbox notification-history request shortly beforehand returned HTTP 200. We restored the original settings after collecting diagnostics. The recorded failure is covered by Feedback Assistant report FB24885397. What could explain this discrepancy, and what additional diagnostics would help Apple investigate?

-(void)paymentQueue:(SKPaymentQueue*)queue updatedTransactions:(NSArray<SKPaymentTransaction*>*)transactions In the sandbox environment this is called continuously every time my enters the foreground. I call -finishTransaction on approximately 22 transactions. Confirmed by: NSUInteger finishCount = 0; NSUInteger transactionCount = transactions.count; for (SKPaymentTransaction *aTransaction in transactions) { // Check state..if purchased or restored.. [[SKPaymentQueue defaultQueue]finishTransaction:aTransaction]; finishCount++; // Post notification telling everyone here! } NSLog(@"Finsihed %lu of %lu",finishCount,transactionCount); The log at the bottom says - finished 22 of 22 transactions. But every time the app enters the foreground the -paymentQueue:updatedTransactions: is called again with another batch of transactions. How Over and over again. Not sure how this is possible but the transactions seem to never clear from the queue. I hope this may be limited to the sandboxed environment. In this loop after finish transaction is called I then post a notification which kicks off receipt validation...and then I even store something in the keychain. Doing this work over and over again in a tight loop is very unexpected and causes my app to lock up. Yea I know this is deprecated. Will move to my Objective-C storekit 2 wrapper but breaking SK1 on purpose seems kind of um, rude. Hope this is only in the sandbox environment. This app got sidelined even though I got some plans to resurrect it in the back of my head.

Hello, We have a critical, release-blocking issue with the StoreKit External Purchase Link entitlement (com.apple.developer.storekit.external-purchase-link) and would appreciate an engineer's help. We submitted a request for the External Purchase Link entitlement earlier this year. After no updates since February, we followed up with Apple Developer Support. Support confirmed the entitlement has already been granted to our account, but advised that Xcode is unable to display/select it and directed us to Feedback Assistant / the Developer Forums. However, the capability still does not appear as enabled on our App ID, and it is not included in our provisioning profiles. Current impact We cannot build or sign the app. Automatic signing fails because the provisioning profile is missing the entitlement, which blocks both development builds and release. What we're seeing Xcode – Signing & Capabilities Automatic signing fails with: Provisioning profile "iOS Team Provisioning Profile: ...." doesn't include the StoreKit External Purchase Link capability. StoreKit External Purchase Link capability needs to be assigned to your team and bundle identifier by Apple in order to be included in a profile. And: Entitlement com.apple.developer.storekit.external-purchase-link requires approval from Apple to include in a profile. Please request access to the associated capability. To continue building for device during request processing, remove entitlement and add upon approval. Provisioning profile detail (Xcode) The managed profile shows: Capabilities: 4 Included, 1 Missing → Missing StoreKit External Purchase Link, and Entitlements: 7 Included, 1 Missing → Missing com.apple.developer.storekit.external-purchase-link. Local entitlement configuration The entitlement is correctly added in our Xcode project, but builds fail due to the missing support in the provisioning profile. Apple Developer Portal – Edit App ID Configuration In the capability list, "StoreKit External Purchase Link" shows "No Requests" and cannot be selected/enabled. (The separate "StoreKit External Purchase" entry shows "No Status".) So the capability is not actually attached to the App ID on the portal, despite Support confirming the grant at the account level. What we've already tried Confirmed the entitlement is present in the app's .entitlements file. "Try Again" / regenerating the automatically managed provisioning profile in Xcode. Verified with Apple Developer Support, who confirmed the grant but could not enable it in Xcode/portal and referred us here. Question / request Since Support confirms the entitlement is granted at the account level but it does not appear as an assignable capability on the App ID or in the provisioning profiles, could an engineer please: Confirm whether the External Purchase Link entitlement is actually associated with our Team and this specific App ID, and Assign/enable the capability so it can be selected on the App ID and included in the provisioning profile? Environment: Xcode version: 27.0 macOS version: 26.6.2 Screenshots of the Xcode signing error, the provisioning profile detail, the local entitlement configuration, and the Developer Portal capability list are attached. Thank you very much for any assistance.

Hello. I am having trouble because when I send a request to the External Purchase Server API from my own server, I receive a 400 error, but the response does not specify a reason. ・Sent data (some information is masked with ) marketplaceToken received from the client: eyJhcHBBcHBsZUlkIjo2NzU5MTg2MjcyLCJidW5kbGVJZCI6ImNvbS5IYWJiaXQuQW5hRG9zLlBh**************************************************************************************************************************************************************************************************************************CJ0b2tlblR5cGUiOiJDT1JFX1RFQ0hOT0xPR1kifQ== The content of the Bearer Token used when performing a cancellation operation for this payment transaction: {"iss":"a5******---****-3c08","iat":1790134367,"exp":1790135567,"aud":"appstoreconnect-v1","bid":"com...Pal"} The JWT actually sent: eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikg5N1dOOTRLNjYifQ.eyJpc3MiOiJhNTU*************************************************************************************************************************N0LXYxIiwiYmlkIjoiY29tL********************************************************************************************************************************************************KVfupOI4wW-gMWjHSq2rppbzezTqqiHl0Q The request body actually sent: {"requestIdentifier":"01a0cc52-b3b4-71d4-99c9-e1df27c6193b","externalPurchaseId":"98******---****-****903174ab","status":"NO_LINE_ITEM"} ・Request endpoint (Production) PUT https://api.storekit.apple.com/externalPurchase/v1/reports ・Request endpoint (Sandbox) PUT https://api.storekit-sandbox.apple.com/externalPurchase/v1/reports ・API response response: ( 'status' => 400, 'content_length' => '0', 'body_size' => 0, 'body_position' => 0, 'body_string' => '', ) Whether the request is sent to the production environment or the sandbox environment, a "400 Bad Request" response is returned with an empty response body, making it impossible to determine the cause of the issue. Could you please point out what the problem might be?

Hello everyone, I am encountering a persistent date discrepancy between the subscription expiration date returned by the App Store Server API and the date displayed to the user in the native iOS Settings UI. Our app receives the renewal timestamp via the App Store Server Notifications in UTC milliseconds. For a recent transaction, we received renewalDate = 1820988823000, which is September 15, 2027, at 06:13 AM UTC. Following standard practices, our app formats this UTC timestamp to the user's local device timezone. On a device set to India Standard Time (IST, UTC+5:30), the app correctly displays the expiration as September 15. However, on the exact same device, navigating to iOS Settings > Apple ID > Subscriptions shows the expiration date as September 14. Converting 06:13 AM UTC to Pacific Time (PT) results in September 14 at 11:13 PM PDT. This leads me to suspect that the iOS Settings page anchors its display strictly to Cupertino/Pacific Time, completely bypassing the device's local timezone. I noticed another developer raised this exact issue regarding KST back in September 2025 (Thread ID: 800332), but that post remains unanswered. My questions for the community and Apple Engineers: Can anyone officially confirm if the native iOS Settings > Subscriptions screen intentionally displays dates anchored strictly to Pacific Time (PT) rather than the device's local timezone? If so, how are you handling user inquiries when your app correctly displays the local time, but Apple's UI displays the day prior? Any official references or guidance on this behavior would be greatly appreciated to help us clarify this for our QA teams and end-users.

I need the supported way to obtain an Apple-signed AppTransaction for a development-installed iOS app without initiating an in-app purchase. DTS directed me to ask on the forums. Environment at the time of reproduction Physical iPhone 17e, iOS 27.0 (24A437). Xcode 27.0 (27A266a), macOS 27.0 (26A428). Swift / SwiftUI / StoreKit; version 0.1.0, build 1. Explicit bundle identifier registered with App Store Connect; development signing. The executable signature, embedded profile and installed executable hash were checked. Installed and launched using devicectl. Network access allowed. No StoreKit Configuration file or StoreKitTest session. No IAP products or TestFlight builds. App Store Connect version 1.0: Prepare for Submission. Observed behavior Call try await AppTransaction.shared once. It throws; no verified transaction is returned. From a separate visible button, the user explicitly calls try await AppTransaction.refresh() once. No Apple Account authentication prompt appears. The refresh fails immediately. The refresh error is identified by Swift pattern matching as StoreKitError.systemError: Outer NSError: StoreKit.StoreKitError, code 1 Underlying NSError: SKInternalErrorDomain, code 14 The refresh was recorded at 2026-09-20T15:40:12Z. The original shared probe recorded only the outer error, so I am not claiming its underlying error was identical. I could not find a public definition of the internal error; I am not interpreting it as SKErrorDomain code 14. A Sandbox Test Account was subsequently created, but has not been signed in on the device. The user could not find the Sandbox Apple Account entry. No purchase has been attempted to make that entry appear. The later controlled refresh is described below. The device App Store account differs from the developer account; we have not established this as a cause. Controlled follow-up on 2026-09-22 A separate instrumented copy of RefreshProbe was development-signed, installed and launched with devicectl on the same phone. The user explicitly tapped refresh once at 2026-09-22T14:35:39Z. It again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The runtime executable SHA-256 matched the locally validated signed binary. No verified AppTransaction was returned. Bounded traversal of the typed underlying error, NSUnderlyingErrorKey and multiple underlying errors exposed only those two domain/code nodes and no allowlisted numeric service status. We did not collect arbitrary userInfo, accounts or signed transactions. App stdout confirmed the result; no storekitd/appstored system log or Xcode IDE launch comparison is claimed. The user confirmed that this attempt also showed no Apple Account login or password prompt. This instrumented copy is separate from the original source ZIP described below. No automatic retry or purchase was performed. VPN-disabled follow-up on 2026-09-22 After the earlier controlled attempt, the user reported using a VPN. For a second controlled attempt the user confirmed that the VPN was disabled and the normal Apple Account remained unchanged. At 2026-09-22T14:48:25Z, one explicit button tap again returned StoreKitError.systemError, outer StoreKit.StoreKitError code 1 and underlying SKInternalErrorDomain code 14. The bounded error tree was identical to the preceding attempt. The user confirmed that no login or password prompt appeared. No verified AppTransaction was returned. The runtime executable hash matched this signed build. The StoreKit call and diagnostic logic were unchanged; only the run identifier and UI label changed to preserve earlier records, followed by installation/relaunch. VPN and account conditions are user observations, not captured network routing. Disabling the VPN did not resolve this attempt; this is not proof that all network causes are excluded. There were no automatic retries or purchases. Questions Is an Apple-signed sandbox AppTransaction supported in this development-install scenario without an IAP product or purchase attempt? What registration and authentication prerequisites apply? What supported diagnostics or corrective steps should we use when refresh fails before presenting authentication? Is there a supported sandbox authentication path for this case without initiating a purchase or signing out of the normal Apple Account? If logs are needed, which narrowly scoped StoreKit logs should we collect? Focused sample A small project with two targets (192 Swift source lines, no dependencies) is ready to provide. The source entry points match the probes used for the observations above. Both packaged targets passed unsigned generic iOS builds, but the newly assembled focused package has NOT itself been re-signed and run on a device. It performs no purchase or photo-library access and does not include credentials, provisioning profiles, device identifiers or signed transactions. I can provide the package to DTS in the existing email request with a link to this forum post. I have not uploaded the package publicly.

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (https://developer.apple.com/forums/thread/774053) and a DTS support request on the same topic, I am posting this issue with the Feedback Assistant ID requested there: FB24820430. Summary: This is a content anomaly in Apple-signed App Store Server payloads, not a notification delivery problem — our server receives and verifies every notification; the defect is in the field values themselves. For a stable subset of subscription families, purchaseDate in JWSTransactionDecodedPayload is consistently ~8 hours later than the signedDate of the very same JWS — a purchase recorded as happening after the signed document reporting it existed. Reproducible field comparison inside one and the same Apple-signed JWS: Field relation Affected transactions Unaffected (control) transactions purchaseDate − signedDate +7h54m … +7h59m (never ≤ 0) ≈ 0 (seconds) Webhook arrival at our server ≈ signedDate (seconds to minutes), never ≈ purchaseDate ≈ signedDate originalPurchaseDate carries the same ~8h shift (renewals inherit it) no shift expiresDate − purchaseDate exactly one subscription period exactly one subscription period expiresDate − signedDate period + ~8h period All fields are documented as "UNIX time, in milliseconds". Our iOS client passes StoreKit 2 Transaction.purchaseDate through unmodified; our backend stores the epoch-millisecond values verbatim as UTC with no timezone conversion. These payloads are generated and signed by Apple infrastructure. Scale (production, as of 2026-09-14): ≈710 subscription families (distinct originalTransactionId lineages), ≈2,700 transactions — roughly three quarters of all families with renewals. Affected purchases span early March 2026 to present, ~30–45 new affected transactions per day. Observed across US, PH, ID and GB storefronts and across app build versions. Sandbox is unaffected. Our interpretation (inference, not confirmed): the offset varies between 7h54m and 7h59m rather than being exactly 8h, consistent with a local wall-clock time in a UTC+8 environment having been encoded as if it were UTC when the original transaction record was created, then inherited by all renewals of that family. Questions for Apple engineers: Is this a known issue in App Store Server data, and is there a reference we can track? What conditions cause a family's purchaseDate to be recorded this way (storefronts/regions, purchase channels, offer types, original-receipt formats)? When purchaseDate and signedDate disagree, which field is authoritative for "when the customer was charged"? The public documentation defines each field only as "UNIX time, in milliseconds" and does not define its relationship. Is remediation planned on Apple's side, or what is the recommended way to obtain the true charge time? Evidence: A focused sample project (a ~85-line Swift tool plus four unmodified signedTransactionInfo JWS samples — three affected families and one unaffected control, each carrying Apple's x5c certificate chain) is included in Feedback Assistant report FB24820430, together with the raw HTTP notification bodies for an affected and a control notification, exactly as delivered to our endpoint. Thank you.

Hello Apple Developer Forums, We are unable to authorize the Production App Store Server API Request a Test Notification endpoint. Environment: Production API: Request a Test Notification Library: Apple App Store Server Library for Java 5.2.0 Client: AppStoreServerAPIClient Result: HTTP 401 Unauthorized before a testNotificationToken is returned. We have verified the following: The key is an active In-App Purchase key created in App Store Connect under Users and Access > Integrations > In-App Purchase. The production server uses the matching .p8 private key, Key ID, Issuer ID, and bundle ID. The bundle ID is com.ansio.serviceproof.ios. The server clock is NTP-synchronized. The request uses the official Apple Java Server Library rather than a manually generated JWT. We rotated the production In-App Purchase key once and received the same 401 result. The notification URL is configured for the Production environment, uses HTTPS, and is reachable. Sandbox uses an independent key and notification configuration. We intentionally do not include the private key, JWT, Key ID, or Issuer ID publicly. According to the documentation, HTTP 401 means the JWT is invalid. Since the official library creates the JWT and the active In-App Purchase key configuration has been verified, could Apple clarify: Is any additional App Store Connect role, agreement, team activation, or entitlement required for a Production In-App Purchase key to authorize App Store Server API requests? Is there a known propagation or authorization issue that can cause a newly created active In-App Purchase key to return 401? What non-sensitive diagnostic details can help distinguish a JWT construction issue from a team-level authorization issue? Thank you.

I am designing a cross-platform application whose core application is a web/PWA application. I want to distribute a very small native wrapper through the Apple App Store. The customer would purchase the application once through the App Store. There would be no subscription, no developer-managed customer account, no developer password, and no cloud storage of the customer's data. The customer's songs remain entirely on their device. The native Apple wrapper would use StoreKit to determine whether the customer owns the application. If they do, the web application should operate in unlimited mode. If they don't, the web application should operate in a free mode limited to 10 songs. Can an App Store-distributed native wrapper securely communicate the verified StoreKit entitlement to the embedded web/PWA application, without requiring my own customer account or licensing server? If yes, what Apple-supported mechanism should be used to pass that entitlement from the native application to the web application? Additionally, does Apple's App Store license for a non-consumable purchase automatically allow the purchaser to use the application on multiple Apple devices associated with the purchaser's Apple Account?

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (thread 774053), Feedback ID: FB24877994. Apple Developer Support case 102971044266 is open in parallel. Summary On our account no auto-renewable subscription renewal has ever succeeded, on either of our two products, while every customer-present initial purchase succeeds. In the last 48 hours 4 of 4 free trials that reached their renewal date with auto-renew ON failed with expirationIntent 2, in four countries (PK, GB, NL, US). What we observe Yearly product with a 7-day free introductory offer (all 175 territories, offerMode FREE_TRIAL, ONE_WEEK, 1 period). Monthly product with no offer. For each of the four, GET /inApps/v1/subscriptions/{originalTransactionId} returns status 3, and the renewal info has autoRenewStatus 1, expirationIntent 2, isInBillingRetryPeriod true, the correct renewalPrice and currency, no priceIncreaseStatus. Environment Production, inAppOwnershipType PURCHASED. The DID_FAIL_TO_RENEW notification (no subtype; billing grace period not enabled) arrives at the expiry time in each case. App Store Connect subscription events from 2026-08-01 to 2026-09-20: 18 free trial starts, 6 full-price starts, 4 voluntary churns from free trial, 4 from full price, 3 "Billing retry from free trial", 1 "Involuntary churn from full price", and no renewal event of any kind. So 5 of 5 unattended renewal charges ever attempted have failed, across two products and five countries, while the 6 paid monthly purchases in the same window (TR, FR, AU, MN, US) were charged normally at purchase time. The customers are in their own storefront countries (device time zones match), and none of the four cancelled. What we have verified Both products Approved, 175 price rows each, no scheduled or preserved prices; Paid Applications Agreement, Free Apps Agreement, banking, tax forms and both compliance items (DSA, MRDP) all show Active with nothing pending in App Store Connect > Business; our servers call no App Store Server API endpoint that modifies a subscription. Thread 847338 (posted today) describes every renewal on an account failing after an agreement issue, with expirationIntent 5. Ours is expirationIntent 2 and our agreements show Active, but the shape is the same: every renewal, no purchase affected. Questions for Apple engineers Is there any account, agreement or product condition that causes renewal charges to fail with expirationIntent 2 while initial purchases succeed? Is anything more than expirationIntent 2 available about these four renewals? The four original transaction IDs are in FB24877994. Is there a known issue affecting free-trial-to-paid renewals around 19 to 21 September 2026? Thank you.

I see different storefronts in StoreKit product queries and Apple’s purchase sheet when testing through TestFlight. Xcode-installed builds work normally. iPhone — iOS 26.6 (23G71), US Media & Purchases account Both StoreKit 1 and StoreKit 2 return CHN/CNY. The app displays CNY 128 for a non-consumable, but Apple’s sandbox purchase sheet shows USD 29.99 for the same product. This reproduces in a standalone 177-line Swift sample using Product.displayPrice directly, with no third-party dependencies, currency conversion, or local .storekit configuration. Reloading products and signing out of the sandbox account did not resolve it. Mac Catalyst — macOS 26.3 (25D125), China purchase account The original TestFlight app returns USA/USD. Purchasing shows “Account Not In This Store” and asks to switch to China, although the purchase account is already set to China. The Mac symptom has not yet been verified in the standalone sample. Reproduction on the affected iPhone: install via TestFlight, load products and log Storefront.current plus the SK1 storefront, open the purchase sheet for the same product, then compare currencies. No completed purchase is needed. Built with Xcode 26.1 (17B55). Has anyone found a workaround for this TestFlight-only mismatch? Should the app handle storefront updates differently, and which additional diagnostics would help distinguish a device/account-session issue from a StoreKit service issue? Feedback: FB24873070. A focused sample and diagnostic evidence are prepared for Apple Developer Technical Support. Reproduction on other devices/accounts is not yet confirmed.

Hello, We are currently seeing errors when validating receipts for every auto-renewable subscription purchased through both StoreKit 1 and StoreKit 2. Details below. Case 1 — StoreKit 1 Calling https://buy.itunes.apple.com/verifyReceipt with the subscription receipt returns: "status": 21006, "expiration_intent": "5" Case 2 — StoreKit 2 Calling https://api.storekit.itunes.apple.com/inApps/v1/subscriptions and reading the most recent transaction (LastTransactionsItem) returns status 3. Within JWSRenewalInfoDecodedPayload: autoRenewStatus = 1, expirationIntent = 5 Timeline We believe renewals stopped processing for essentially all auto-renewing subscribers of our app as of 2026-09-18 09:30 KST (UTC+9). After resolving an agreement/licensing issue on our side, new purchases and some receipt validations recovered as of 2026-09-21 11:49 KST. However, most existing receipts still return expirationIntent = 5 when we query receipt validation or subscription status. Questions Is any action required on our side — a server-side change, a configuration change in App Store Connect, or a further review of our agreements? Now that the agreement issue is resolved, when are the renewals that were left pending during the outage expected to be processed? Any guidance would be appreciated. Thank you.

Hello, I submitted a mass subscription renewal date extension request using the App Store Server API on September 9, 2026. The request was accepted successfully. However, when I check the request using getStatusOfSubscriptionRenewalDateExtensions, the status continues to return: complete: false As of September 20, the request has remained incomplete for 11 days. Request details: Extension: 1 day Reason: temporary service interruption Environment: Production The documentation states that a mass renewal date extension may take hours or even days to complete, but I have not been able to find guidance for a request that remains incomplete this long. Only three subscribers were affected by the service interruption, and I have their originalTransactionId values. I am considering using the individual subscription renewal date extension API instead. My questions are: Is it expected for a mass renewal date extension request to remain complete: false for 11 days? Could this mass request still complete at a later date? Is there any way to cancel or determine whether this mass request is stuck? If I extend the three affected subscriptions individually now, is there a risk that the pending mass request could later complete and extend them a second time? I would like to compensate the affected subscribers as soon as possible while avoiding duplicate extensions. Thank you for any guidance.

Hey We are implementing EU external purchases for both our iOS and native macOS apps as it's written here: https://developer.apple.com/br/support/payment-options-on-the-app-store-in-the-eu For our App ID, we enabled StoreKit External Purchases or Offers, whose entitlement key is: com.apple.developer.storekit.custom-purchase-link.allowed-regions The capability works for iOS, but newly generated macOS provisioning profiles do not contain this entitlement. In Certificates, Identifiers & Profiles, the capability itself shows Platform Support: iOS, tvOS, watchOS, visionOS - macOS is not listed. However, the StoreKit documentation for ExternalPurchaseCustomLink and the EU alternative-payment documentation appear to describe external-purchase support more generally. Could you please clarify: Is com.apple.developer.storekit.custom-purchase-link.allowed-regions currently supported for native macOS apps distributed through the Mac App Store? If not, what entitlement and API should a native macOS app use for EU external purchases and external-purchase token reporting? Is macOS support for the StoreKit External Purchases or Offers entitlement planned or available through a separate entitlement request? At the moment, our macOS provisioning profiles cannot contain this entitlement because macOS is not listed as a supported platform for this capability. Thank you!

I am troubleshooting a reproducible StoreKit product discovery issue in a TestFlight build of my iOS application. App: Bundle ID: com.aileguvende.app Version: 2.9.59 Build: 97 On a physical iPhone using the TestFlight build, opening the subscription/paywall screen reproduces the issue. StoreKit availability is true and canMakePayments is true, but Product.products(for:) requests six auto-renewable subscription identifiers and returns: Requested products: 6 Returned products: 0 Not found products: 6 The query reports product_query_error with the plugin error code storekit_no_response. No purchase or Restore operation is required to reproduce the issue. The applicable TN3186 checks completed successfully: the App ID is explicit, In-App Purchase capability is enabled, the bundle ID and signing profile match, all six product identifiers match App Store Connect, all six products are available in Türkiye, pricing is configured, Turkish and English localizations are present, and the Paid Apps Agreement, banking, and tax information are active. The Apple Account and storefront are Türkiye. During the same runtime window, storekitd and appstored activity was observed and AMSErrorDomain activity was present, but no reliable native numeric error code or native product counts were exposed. CLIENT_PLUGIN_DEFECT_PROVEN=NO OFFICIAL_APPLE_INCIDENT_CONFIRMED=NO Feedback Assistant report: FB24793792. Could Apple engineers please verify: Whether the six subscriptions are present in the TestFlight/Sandbox commerce catalog for com.aileguvende.app. Whether the app-to-subscription catalog association is healthy on Apple’s backend. Whether there is a current StoreKit/App Store Commerce product-discovery issue where Product.products(for:) returns an empty result despite TN3186 checks passing. Whether any additional diagnostic is needed for FB24793792. This issue is reproducible without a transaction. I am not requesting a source-code change or a new build.

One user of my app reached out reporting an interesting in-app purchase issue. Has anyone encountered this or have an idea what's going on here? Proceed to purchase the non-consumable IAP in the app downloaded from the App Store iOS shows the price sheet as expected Confirm with the side button iOS shows an alert "You've already purchased this. Would you like to get it again for free?" Tap OK iOS shows an alert "You're all set. Your purchase was successful." Tap OK The app's content remains locked Tap Restore Purchases iOS shows an alert to sign (with the same account shown in step 2) Input the password and tap OK iOS shows an alert "Unable to Complete Request" (which is the error.localizedDescription thrown from AppStore.sync())