I've read several topics on cancelling subscriptions in sandbox environment, but it seems to me that it could not be applied to TestFlight. I can cancel sandbox subscriptions through Settings > App Store > Sandbox account But since TestFlight does not use sandbox account I cannot cancel a sub from there. Also, TF purchase does not appear in the list of regular subscriptions (Settings > Profile > Media & Purchases). So my question is: is there any way to manually cancel auto-renewable subscription bought in TestFlight build of the app?

Title: Sandbox allows free trial again on resubscribe to the same subscription Hi everyone, I'm testing an auto-renewable subscription using App Store Connect with a Sandbox tester (not a local StoreKit configuration file). My subscription has an introductory free trial configured. Scenario: Purchase the subscription for the first time using a Sandbox Apple ID. The user receives the introductory free trial as expected. Let the subscription expire. Purchase the same subscription product again using the same Sandbox Apple ID. I receive an App Store Server Notification with Notification Type = RESUBSCRIBE, and the transaction appears to have a price of 0, making it look like the user received another free trial. From Apple's documentation, my understanding is that an introductory offer can only be redeemed once per subscription group per Apple ID. Based on that, I expected the second purchase to be charged immediately rather than receive another free trial. My questions are: Is this expected behavior in the Sandbox environment? Does Sandbox sometimes allow introductory offers to be redeemed multiple times for testing? Or am I misinterpreting the RESUBSCRIBE notification and the $0 transaction? I did not intentionally reset the Sandbox tester's introductory offer eligibility, and I'm purchasing the same product in the same subscription group with the same Sandbox Apple ID. Has anyone observed this behavior or can clarify whether this is expected in Sandbox versus production? Thanks!

大家好，我正在排查一个 TestFlight 沙盒环境中的 StoreKit 2 商品加载问题，希望获得建议。 一、现象 iOS App 通过 TestFlight 安装（Build 4）后，使用 Product.products(for:) 请求两个非消耗型内购项目。调用不会抛出错误，但始终返回空数组，因此购买页没有任何可购买商品。 products = try await Product.products(for: [ "com.shidan.qieting.plus.trial.7day", "com.shidan.qieting.plus.lifetime" ]).sorted { $0.id < $1.id } 两个 Product ID 分别为： Product ID 类型 价格 App Store Connect 状态 com.shidan.qieting.plus.trial.7day 非消耗型 Tier 0 / US$0.00 可供审核 com.shidan.qieting.plus.lifetime 非消耗型 US$5.99 可供审核 二、日志 在 TestFlight App 冷启动后，诊断日志记录： 2026-09-03T08:12:08Z [settings] plus products loaded: trialAvailable=false, lifetimeAvailable=false 打开购买页时再次调用，结果仍然为空。没有捕获到 StoreKit 异常，也没有购买流程报错。 三、系统级沙盒验证结果 为排除 App UI 和 StoreKit 商品加载代码的影响，我们还使用同一开发团队创建的 Sandbox Apple Account，在 iOS 的“设置 > 开发者 > Sandbox Apple Account > 管理 > Test Transactions”中直接测试： Bundle ID：com.shidan.qieting Product ID：com.shidan.qieting.plus.lifetime 系统提示：“提供的产品 ID 或套装 ID 无效”。该工具不经过 App 内的购买页或 Product.products(for:) 结果，仍无法识别这组 Bundle ID 与 Product ID。 四、已完成核验 代码中的 Product ID 与 App Store Connect 中的 Product ID 完全一致。 Release Bundle ID 与 App Store Connect App Record 一致，均为 com.shidan.qieting。 App ID 为显式 ID，不是 wildcard App ID。 Certificates, Identifiers & Profiles 中已启用 In-App Purchase capability；Xcode Target 也已启用，Xcode Cloud 使用自动签名。 TestFlight 使用 Archive 构建；共享 Scheme 的 ArchiveAction 没有 StoreKit Configuration 文件。本地 .storekit 文件只用于 Xcode Run/Test，本身不影响 Archive/TestFlight。 两个项目均已设置价格、175 个 App Store 地区可售，以及简体中文、繁体中文、英语本地化。 最后一次修改 IAP 元数据已经超过 48 小时。 Paid Apps Agreement、税务信息和银行信息均为有效/正在使用中。 尚未提交 App 或 IAP 审核；理解为 TestFlight 沙盒测试不应以提交审核为前提。 欧盟《数字服务法》（DSA）交易商合规信息仍在审核中；但该要求针对欧盟 App Store 产品页的交易商信息。Apple 官方说明中，单独通过 TestFlight 分发不属于在欧盟 App Store 以交易商身份分发，因此这不应影响 TestFlight 沙盒或 Test Transactions。 五、想请教 在上述条件已确认、Product.products(for:) 不报错却返回 [] 的情况下，是否还有容易遗漏的 App Store Connect、沙盒、签名或 TestFlight 配置？ 是否有人遇到过“所有 Product ID 均正确、商品完整且全球可售，但 TestFlight 沙盒始终返回空数组”的情况？如果这是 Apple 沙盒端的已知延迟或异常，有什么进一步的排查或反馈渠道？ 我可以按需要补充已打码的 App Store Connect 配置截图和完整诊断日志。谢谢。

Environment: Sandbox Bundle ID: com.fosssocial.app Key ID: L7DZYHGM62 Issuer ID: cf1f7bc7-452f-4bb8-a925-31ca29175fac Summary Our In-App Purchase key is accepted by the App Store Server API but rejected by the Advanced Commerce API, using the exact same bearer token. This appears to be an authorization grant that was never applied to the key, rather than a signing or request-format problem on our side. Reproduction — one token, two API families GET /inApps/v1/subscriptions/1 -> 404, errorCode 4040010 (token ACCEPTED, resource simply not found) POST /advancedCommerce/v1/subscription/changeMetadata/1 -> 401, errorCode 4010000 (token REJECTED) Same JWT, same key, issued seconds apart. A 401 on one family and a 404 on the other isolates this to key authorization. On-device symptom A signed SubscriptionCreateRequest passed to StoreKit as advancedCommerceData fails with StoreKitError.unknown / "Unable to Complete Request". No payment sheet appears and no InvalidRequestError is returned, so there is no field-level error to act on. What we have already verified JWS header: alg ES256, kid, typ JWT Claims: iss, iat, aud "advanced-commerce-api", bid, nonce, request No exp claim (per Apple's documentation) The request claim uses standard padded base64, not base64url Key ID and .p8 file confirmed to be a matching pair Key regenerated after receiving the Advanced Commerce access-granted email; the 401 is unchanged AdvancedCommerceProduct(id:) resolves successfully on device, which confirms the PRODUCT has Advanced Commerce access Question Does the In-App Purchase key require a separate authorization for the Advanced Commerce API beyond the product-level access we were granted? If so, how is that applied to an existing key?

Hi all I have an app I’m pretty much done with, and on the Xcode simulator it works perfectly and the IAP shows us when the purchase buttons are clicked but for some reason when it goes to testflight none of the buttons respond, is there any reason that would cause it to behave differently in testflight when its coded correctly and works in the simulator. thanks

We have a monthly subscription and an annual subscription with a 3-day free trial. The monthly converts fine. On the annual, trials tend to enter billing retry rather than convert — users don't cancel, the charge just fails. We've audited our implementation and found nothing on our side that participates in the renewal charge. What can a developer actually do about this? Does trial length, price point, or using a paid introductory offer instead of a free trial make a difference?

We have 5 consumable in-app purchase products (Product IDs: localshadows_support_099, _499, _999, _2499, _4999) currently in "Prepare for Submission" status. Our app's first version (1.0) has also not yet been submitted for App Review. Question: Does sandbox testing of these consumable IAPs require the app to be fully approved through App Review first, or is it sufficient for the products to be attached to a version that has been submitted (even if still pending review)? What we've tried: We're using react-native-iap v16.4.1 for a real native StoreKit 2 purchase flow (not RevenueCat, which was masking this issue via its Test Store simulation mode). Calling fetchProducts() for these SKUs returns an empty array, and calling requestPurchase() for them results in an indefinite hang with no error. We want to complete sandbox testing before deciding on our actual App Review submission timeline.

We are testing two auto-renewable subscriptions for a new iOS app. In Apple Sandbox, StoreKit 2 Product.products(for:) always returns an empty array. Legacy SKProductsRequest independently reports both identifiers as invalid. Environment: Physical iPhone, iOS 26.5 Xcode development build with automatic signing Storefront.current = USA (143441) canMakePayments = true No StoreKit Configuration file in the Run scheme Direct native StoreKit 2 diagnostics, without a third-party purchase SDK TN3186 checks completed: Explicit Bundle ID matches the App Store Connect app, installed app, and provisioning profile In-App Purchase is enabled for the App ID Developer membership, Paid Apps Agreement, banking, and tax are active One subscription group with monthly and yearly subscriptions is visible Pricing, localizations, and availability are configured Neither subscription is Rejected or Developer Action Needed The scheme is using real Sandbox data, not local StoreKit testing Results: StoreKit 2 batch query: rawCount = 0 SKProductsRequest: valid = []; both identifiers are invalid StoreKit 2 individual monthly query: 0 StoreKit 2 individual yearly query: 0 No exception; failure occurs during product discovery Related reports: https://developer.apple.com/forums/thread/839313 — TN3186 verified and USA storefront valid, but still 0 products; no replies https://developer.apple.com/forums/thread/841722 — Apple Commerce mentioned Rejected or Developer Action Needed states; ours have neither https://developer.apple.com/forums/thread/820656 — Apple DTS confirmed first subscriptions do not require review before Sandbox testing Apple Developer Support referred us to TN3186, and we verified every applicable item. The individual subscription detail route in App Store Connect also intermittently remains on a loading indicator although the group and both records are visible. Could an App Store Commerce or StoreKit engineer check whether the app-to-IAP catalog association is populated correctly on Apple's side, or advise an official escalation path to have the Sandbox catalog reprocessed? Exact account, app, product, device, email, and support-case identifiers are omitted from this public post and can be supplied privately through Apple Support or Feedback Assistant.

I’m trying to diagnose a StoreKit issue with an auto-renewable subscription in my iOS app. The subscription is called “Lighthouse Plus” and is $9.99/month. The app is currently being tested through TestFlight. When the user taps the Lighthouse Plus subscription button, the app begins the purchase process/loading state, but the Apple purchase sheet never appears. The UI then remains stuck loading indefinitely. This has continued across multiple TestFlight builds, including our current Build 11. What happens: Install/open the app through TestFlight. Sign into the app. Navigate to Lighthouse Plus. Tap the subscription/purchase button. The app enters a loading state. No Apple purchase confirmation sheet appears. The loading state never resolves. We have also been investigating Restore Purchases and Manage Subscription behavior as part of the same StoreKit implementation. The subscription product has been configured in App Store Connect and associated with the app. We have repeatedly tested new builds while trying to determine whether the failure is in our StoreKit implementation, product configuration, TestFlight sandbox environment, or communication with the App Store. The particularly difficult part is that we are not receiving a visible StoreKit error on the device — the purchase attempt appears to wait indefinitely rather than returning a clear success, cancellation, or failure. I do not currently have access to a Mac for direct Xcode/StoreKit Console debugging, so I am trying to determine the best way to diagnose exactly where this transaction is stopping from a TestFlight device. Questions: What would cause a StoreKit subscription purchase request to remain pending/loading without ever presenting Apple's purchase sheet? Is there a way to retrieve useful StoreKit/TestFlight transaction diagnostics without access to Xcode on a Mac? Are there specific App Store Connect subscription states/configuration issues that can cause this behavior without StoreKit returning an obvious error? What StoreKit transaction/product logging should we add to the app itself so the next TestFlight build can identify exactly where the request is failing? Should the purchase call have an explicit timeout/error path if StoreKit never returns? I can provide the product identifier, relevant StoreKit implementation/code, App Store Connect configuration screenshots, and additional diagnostics if needed. Any guidance on isolating whether this is an App Store configuration issue versus an implementation issue would be greatly appreciated.

product?.subscription?.isEligibleForIntroOffer 在swift中使用该方法时，目前生产环境只有一个例出现无反应的情况，从日志看有调用该方法前的日志，但无该方法之后的日志，怀疑无返回阻塞在此处，看有什么办法尝试修复这种情况

Our first submission has now been rejected under Guideline 2.1(b), with the message: "the in-app purchases do not load successfully." Each review was performed on an iPad Air 11-inch (M3) running iPadOS 26.6. The app sells only auto-renewable subscriptions. We cannot reproduce the failure, and we have verified every part of the configuration we can think of. WHAT WE VERIFIED (via the App Store Connect API, not just the UI) Two subscriptions in one group, state READY_TO_SUBMIT Product IDs exactly match what the app requests Available in 175 territories, including the United States Prices set, en-US localizations present for both products and for the group App review screenshots attached to both, state COMPLETE Both subscriptions are included in the review submission (READY_FOR_REVIEW) Paid Apps Agreement: Active. Bank account: Active. Tax forms: Active. WHAT WORKS On our own devices, installed via TestFlight (sandbox environment), the products load correctly and a purchase completes and activates as expected. This works on both a real Apple ID and a Sandbox Tester account. WHAT WE OBSERVED FROM THE REVIEW SESSION We use RevenueCat. Their server-side API returns our offering with both packages and the correct product identifiers, so the offering metadata is fine. Our backend also shows that the reviewer's session reached our servers and signed in successfully at the review timestamp, so the device had working network connectivity. That leaves StoreKit itself returning no products on the reviewer's device, which is what empties the offering. QUESTIONS Are there known conditions under which StoreKit returns no products in the App Review sandbox for subscriptions that are in "Ready to Submit" and are attached to the same submission as the binary? For an app that has never been approved, is product loading during review handled differently from a normal sandbox session on a released app? Is there any way to obtain diagnostics from a review session, or to ask the reviewer for a screenshot of the failing screen? Replies in Resolution Center so far have only repeated the original rejection text. Is there anything specific to iPadOS 26.6 that could affect StoreKit 2 product lookups? For the next submission we have added a timeout and automatic retries around the product lookup, plus a visible retry control instead of a spinner, in case the failure is a transient cold-start timeout. But we would rather understand the actual cause than keep guessing. Any pointers appreciated.

Since January 28, 2026, we’ve noticed an increase in StoreKit-related errors during purchase flows. Specifically, we’re seeing a spike in errors reported as “Unable to Complete Request”, categorized as unknown StoreKit errors. This correlates with a noticeable drop in the overall purchase success rate. A few observations: The issue is not limited to the latest app version, it also affects older versions. It appears to occur only on iOS 17+. The impact seems country-specific: some regions are affected more heavily, while others show no significant change compared to previous days. At the moment, there are no related incidents reported on Apple’s System Status page. Given these symptoms, this looks like a potential StoreKit / Apple API issue, but we haven’t found any official confirmation yet. Has anyone else observed similar StoreKit behavior recently on iOS 17+? Any insights or known issues would be greatly appreciated.

My app is live on the App Store and all three auto-renewable subscriptions are Approved, but StoreKit 2 never answers on device. Product.products(for:) does not settle — no products, no error, no throw. I let it run 30 seconds. Storefront.current behaves the same way, so this is not a product-id or catalogue problem. StoreKit is not reaching a store at all. Already ruled out: Product ids app.steady.pro.weekly / .monthly / .yearly, all Approved; subscription group Approved Bundle id app.steady.calm, matches App Store Connect exactly Paid Applications Agreement Active, bank and tax forms Active In-App Purchase capability enabled on the App ID and present on the App Store provisioning profile Two iPhones, two Apple Accounts, storefronts AZ and TR, three networks A clean build run directly from Xcode on a different Mac — identical silence Also reproduced through a third-party purchases SDK before reverting to plain StoreKit 2, so it is not my bridge layer This has never worked once, on any device or account, since launch. It is not intermittent. Open with Apple: Developer Support case 20000143122321, Feedback FB24488724 with sysdiagnose attached. Has anyone seen Storefront.current hang like this? Is there an account-level state that can stop StoreKit from resolving a storefront even when the app and products are approved?

Hi, Overview I have an app for which I have created a sandbox account. When I try to clear purchase history it doesn't work, it still shows the in-app purchase items (non-consumable in-app purchases) as purchased. I have tied tried the following ways, but none of them work. Any help on this would be much appreciated! Attempt 1: Go to https://appstoreconnect.apple.com/ Users and Access > Sandbox Check sandbox account > Tap Clear Purchase History button Attempt 2: Go to the iPhone > Settings > Developer > Sandbox Apple Account Tap on account > Manage > Clear Purchase History Attempt 3: Sign out of Sandbox account and sign back in Attempt 4: Delete app and re-run app from Xcode

Hello, I am investigating an intermittent In-App Purchase failure that occurred during App Review for the first release of my app. Environment Review device: iPad Air 11-inch (M3) OS: iPadOS 26.6 Environment: App Review sandbox Product type: Consumable StoreKit integration: RevenueCat through react-native-purchases 10.4.3 Observed behavior StoreKit successfully returned the products, localized names, and prices. The reviewer could see the credit packs and initiate the native purchase flow. My diagnostics show this sequence: Purchase initiated PURCHASE_CANCELLED; no transaction evidence Purchase initiated again RevenueCat code 2: STORE_PROBLEM elapsed: 9.4 seconds no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE no transaction evidence Purchase initiated again RevenueCat code 5: PRODUCT_NOT_AVAILABLE_FOR_PURCHASE elapsed: 0.6 seconds no transaction evidence code-block The relevant sanitized logs are: { "occurredAt": "2026-08-25T12:52:59.733Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "2", "providerReadableCode": "STORE_PROBLEM", "transactionEvidence": false, "elapsedMs": 9417 } code-block { "occurredAt": "2026-08-25T12:55:42.752Z", "platform": "ios", "appVersion": "1.0.0", "build": "14", "productId": "HIDDEN_FOR_DISPLAY", "stage": "STORE_CHECKOUT", "providerCode": "5", "providerReadableCode": "PRODUCT_NOT_AVAILABLE_FOR_PURCHASE", "transactionEvidence": false, "elapsedMs": 637 } code-block No App Store transaction was created, and therefore RevenueCat received no transaction or webhook for these attempts. Configuration verified I confirmed that: The affected product and the other consumable products are attached to the App Review submission. Product IDs match between the app, App Store Connect, and RevenueCat. Prices and localizations are configured. The products are available in the relevant storefronts. The Paid Apps Agreement is active. Banking and tax information are active. The In-App Purchase capability is present. The distribution build does not use a local StoreKit configuration file. The same build and affected product completed successfully afterward on a physical device using Apple Sandbox. The native purchase sheet opened, the transaction completed, and the consumable content was delivered successfully in my reproduction. The product metadata clearly remained available because its localized name and price were displayed. However, after the initial STORE_PROBLEM, subsequent purchase requests were rejected almost immediately as PRODUCT_NOT_AVAILABLE_FOR_PURCHASE. I do not have the underlying Apple NSError, such as an ASDServerErrorDomain or AMSErrorDomain value, because it was not exposed in my remote diagnostic record. Questions Can a failed sandbox transaction leave the StoreKit account/session or commerce-catalog state temporarily inconsistent, causing subsequent requests for an otherwise loaded product to return storeProductNotAvailable? Does StoreKit use separate metadata and transaction-eligibility services, allowing product information to load while the same product is rejected during purchase()? Are there known sandbox or StoreKit issues on iPadOS 26.6 that could produce this sequence? Could a stale App Review sandbox account token or storefront session explain the transition from STORE_PROBLEM to PRODUCT_NOT_AVAILABLE_FOR_PURCHASE? Is there any developer-side configuration that could explain this when the same product and binary complete successfully using another sandbox session? What additional logging should I capture from RevenueCat’s React Native SDK to preserve the complete underlying Apple error chain?

I'm testing iAP in a sandbox account (as configured in App Store Connect under 'Sandbox Testers'). So the in app purchase works. Cool. But I wanted to retry it. So I cleared the purchase history (both in App Store Connect and on my iPad in the 'Developer' section in Settings). But when I relaunch my app the purchase still validates and my app displays the item as 'unlocked'. Figure the receipt must still be cached so I nuke the app and completely reinstall it but it appears StoreKit is still getting the receipt and it isn't being cleared because my app is displaying it as 'purchased.' Also tried rebooting the iPad. But the sandbox purchase doesn't clear. I just did a sandbox test since it is closer to real life than StoreKit Configuration so I just wanted to do it a few times to make sure all is good but making a burner test account for every purchase is kind of tiresome. Anyone know of a workaround? I might just declare victory and go back to StoreKit Configuration.

We are implementing in-app purchases using StoreKit 2. The issue we need guidance on is how our app should correctly handle a StoreKit 2 transaction that becomes .unverified during Apple App Review. In our local development testing, purchases work correctly. When we test the same IAP products locally, the transaction returned from Product.purchase() is .verified, and the purchase flow completes successfully. However, during Apple App Review, the reviewer appears to encounter a failure where the StoreKit 2 transaction is returned as .unverified on the client side. The original localized error message shown is in Traditional Chinese: 「資訊對裝置無效」 Our English translation of this message is: “The information is not valid for this device.” Because the message is localized, we are not sure what the exact original English StoreKit error string would be. This failure happens in the client app before our backend receipt or server-side validation flow. We are not using verifyReceipt for this step. The failure occurs at the StoreKit 2 VerificationResult level when checking the transaction returned by StoreKit. Our current implementation only accepts .verified transactions. If StoreKit 2 returns .unverified, we treat the transaction as failed and do not unlock the purchased content. We believe this is the recommended secure behavior, but we would like to confirm the correct handling, especially because this issue is appearing during App Review while our local development purchases succeed. Additional context: • Distribution/review context: App Review / IAP review • API: StoreKit 2 • Failure point: VerificationResult returned as .unverified • Localized error message: 「資訊對裝置無效」 • Rough English translation: “The information is not valid for this device.” • Local development testing: purchases return .verified and succeed • The issue occurs before backend validation • Our app currently rejects .unverified transactions and does not unlock content Questions: What are the known causes of StoreKit 2 returning .unverified with the localized error message 「資訊對裝置無效」 during App Review? Is our current behavior correct: only unlock content for .verified transactions and reject .unverified transactions? If App Review receives .unverified, what should the app do from Apple’s recommended perspective? Should we show a retry/error message, ask the reviewer to retry, refresh entitlements, or take another action? Is there any App Review environment, device configuration, Apple ID configuration, or StoreKit account state that can cause this device-related verification error? Since local development purchases succeed but App Review fails, what diagnostics or logs should we collect and provide to identify the root cause? Should we ever bypass StoreKit 2 transaction verification in App Review/TestFlight, or should .unverified always be treated as a failed transaction? We would appreciate guidance on the correct code-level handling so that our app remains secure while also passing App Review reliably. Thank you.

purchaseDate=1787743932000, originalPurchaseDate=1785065532000, expiresDate=1788348732000, quantity=1, type=<Type.AUTO_RENEWABLE_SUBSCRIPTION: 'Auto-Renewable Subscription'>, rawType='Auto-Renewable Subscription', inAppOwnershipType=<InAppOwnershipType.PURCHASED: 'PURCHASED'>, rawInAppOwnershipType='PURCHASED', signedDate=1787715151907, revocationReason=None, rawRevocationReason=None, revocationDate=None, isUpgraded=None, offerType=None, rawOfferType=None, offerIdentifier=None, environment=<Environment.PRODUCTION: 'Production'>, rawEnvironment='Production', storefront='USA', storefrontId='143441', transactionReason=<TransactionReason.RENEWAL: 'RENEWAL'>, rawTransactionReason='RENEWAL', currency='USD', price=7990, offerDiscountType=None, rawOfferDiscountType=None, offerPeriod=None) This is a piece of decode notification, you can see that the purchaseDate and signedDate ​​differ by approximately 8 hours. I can confirm that all the DID_RENEW notifications have this difference. purchaseDate=1787715089000, originalPurchaseDate=1787715089000, expiresDate=1787974289000, quantity=1, type=<Type.AUTO_RENEWABLE_SUBSCRIPTION: 'Auto-Renewable Subscription'>, rawType='Auto-Renewable Subscription', inAppOwnershipType=<InAppOwnershipType.PURCHASED: 'PURCHASED'>, rawInAppOwnershipType='PURCHASED', signedDate=1787715089920, revocationReason=None, rawRevocationReason=None, revocationDate=None, isUpgraded=None, offerType=<OfferType.INTRODUCTORY_OFFER: 1>, rawOfferType=1, offerIdentifier=None, environment=<Environment.PRODUCTION: 'Production'>, rawEnvironment='Production', storefront='IDN', storefrontId='143476', transactionReason=<TransactionReason.PURCHASE: 'PURCHASE'>, rawTransactionReason='PURCHASE', currency='IDR', price=0, offerDiscountType=<OfferDiscountType.FREE_TRIAL: 'FREE_TRIAL'>, rawOfferDiscountType='FREE_TRIAL', offerPeriod='P3D' and this is a SUBSCRIBED/INITIAL_BUY notification, it has right purchaseDate.

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?

I've been struggling to work with the Storekit framework and specifically to find the current Storefront used by the user of the app. Context : My app needs to behave differently depending on the country of the user. For me relying on Locale.current.region?.identifier does not seem very reliable, the user can change it really easily. I'm trying to use the Storekit framework like so : if let storefront = await StoreKit.Storefront.current{ return storefront.countryCode } As per Apple's Storekit documentation : Use current to determine a customer's current storefront region and offer in-app products suitable for that region. You maintain your own list of product identifiers and the storefronts in which you make them available. But I just can't find out what I need to change in my current configuration to get another country. The code keeps returning my original storefront (which is France) I've tried login in with a sandbox user defined on another country. Changed all settings on my device to another country. Changed my Apple's account region as described here. Also tried to logout from everything. The only thing that works is setting a local .storekit file as described here and changing the default storefront. Is Xcode overriding the default storefront when building on debug or TestFlight? does anyone know how can I test different storefronts with sandbox users without the local storekit file ? Thank you in advance.