I’m encountering an incorrect App Store storefront on one iOS device when testing an in-app purchase through TestFlight. Environment: App: ClawApp TestFlight build: 1.0.9 (08251556) Product ID: com.chagent.claw.credits.advanced StoreKit 2 Sandbox Apple Account country/region: Mainland China Device A: works correctly and returns CNY Device B: always returns USA/USD The same Sandbox Apple Account and the same TestFlight build are used on both devices On the affected device, StoreKit returns: storefrontCountryCode=USA storefrontCurrency=USD storeKitCurrency=USD storeKitDisplayPrice=US$9.99 The server catalog returns: serverSaleAmount=79.00 serverSaleCurrency=CNY I have already tried the following on the affected device: Signed out and signed back in to the Sandbox Apple Account Used another Mainland China Sandbox Apple Account Signed out of Media & Purchases Restarted the device Deleted and reinstalled the TestFlight app Cleared Sandbox purchase history However, Storefront.current still returns USA/USD. The same account and app return the expected China storefront on another device. This seems to be device- or iOS-version-specific. Could this be a known StoreKit/TestFlight storefront synchronization issue? What additional logs or sysdiagnose information should I provide?

I have filed Feedback Assistant report FB24182480 for this issue. On an Apple Watch Series 6 running watchOS 26.6 (23U67), a TestFlight watchOS app can successfully load a non-consumable StoreKit 2 product from Sandbox and display its localized price. However, a subsequent single call to product.purchase() can fail before, or while, the system confirmation sheet is displayed. The app itself remains alive. It receives StoreKit.StoreKitError.systemError (code 1), with an underlying NSCocoaErrorDomain error 4097, consistent with losing the XPC connection to storekitd. The affected run’s private co-sysdiagnose shows this sequence: storekitd starts processing the payment. The Sandbox purchase request returns HTTP 200. AMSPaymentSheetTask begins. The kernel reports that storekitd exceeded its ActiveSoft 5 MB limit and terminates it as the high-water process. The app receives Cocoa error 4097. A later user-initiated retry was handled by a restarted storekitd process and ended with the same result. There are no overlapping product, entitlement, or purchase operations, and the app does not automatically retry purchase(). The issue is intermittent: in other runs on the same Watch, the Sandbox purchase sheet has appeared successfully. This makes it appear to be a system purchase-service lifecycle or memory-management issue rather than a product-configuration or product-loading issue. Environment: Apple Watch Series 6 (Watch6,4) watchOS 26.6 (23U67) TestFlight build StoreKit 2 Sandbox non-consumable IAP One explicit Buy tap per attempt Has anyone seen storekitd being terminated with a high-water reason during a watchOS purchase flow, or found a supported app-side mitigation for the resulting StoreKit error 1 / Cocoa 4097? I have kept the sysdiagnose and recordings private in Feedback Assistant because they contain account, device, and network information.

Does anyone have info about the Retention Messaging API. We've requested access to it, but there's no answer.

StoreKit 2 returns zero subscription products in Sandbox/TestFlight — FB24199369 I’m experiencing an issue where StoreKit 2 returns zero subscription products in both Sandbox and TestFlight for my iOS app. App: Bundle ID: com.sleeplessnight.naengbiseo Subscription group: Naengbiseo Premium Product IDs: naengbiseo_premium_monthly naengbiseo_premium_yearly Although the production app uses RevenueCat, I reproduced the same issue in a separate minimal native SwiftUI app using StoreKit 2 directly, with no RevenueCat, Expo, React Native, or other third-party SDK involved. Native StoreKit 2 call: let products = try await Product.products(for: [ "naengbiseo_premium_monthly", "naengbiseo_premium_yearly" ]) Current native test result: STOREKIT_COUNTRY_CODE: KOR STOREKIT_STOREFRONT_ID: 143466 DIRECT_STOREKIT_COUNT: 0 Returned products: None Test environment: Physical iPhone StoreKit Configuration: None Sandbox Apple Account signed in Storefront: KOR In-App Purchase capability enabled Correct Bundle ID and Product IDs I have rechecked the following configuration: The subscriptions are available in the test storefront Subscription pricing is configured Subscription localization is configured Paid Apps Agreement, banking, and tax information are active App ID has In-App Purchase enabled The App Store/TestFlight build has the expected Bundle ID, provisioning, and signing configuration I also created a StoreKit Configuration file using “Sync this file with an app in App Store Connect”. The sync completed, but the resulting configuration contained: products: [] subscriptionGroups: [] The same subscriptions also fail to load in TestFlight. The subscription products currently show Rejected in App Store Connect because the associated app version was rejected. App Store Connect states that the subscriptions were returned because the associated app was rejected and will remain Rejected until resubmitted for review. However, App Review also stated: “In-App Purchase products do not need prior approval to function in review.” I have reviewed TN3186 and have not found a remaining developer-side configuration issue that explains why Product.products(for:) returns zero products. Since the issue reproduces in a minimal native StoreKit 2 app, this does not appear to be caused by RevenueCat or another third-party SDK. Feedback Assistant: FB24199369 Could an App Store Commerce / StoreKit engineer advise whether there is any remaining developer-side configuration that could cause this, or whether the subscription catalog / app association may need to be reprocessed on Apple’s side? Thank you.

Hello, I am currently implementing External Purchase Link and External Purchase Custom Link and am encountering an issue where both ExternalPurchaseLink.canOpen and ExternalPurchaseCustomLink.isEligible always return false under all test conditions. I would like to confirm whether my setup is missing any required steps or whether this behavior is expected. Below are the details of my current environment and configuration: 🔧 1. Development Environment Xcode: 16.3, 16.4, 26.0 beta 4 Devices: iPhone running iOS 26.2 beta iPhone running iOS 16.7.12 macOS 15.5 (real device testing) Simulator iOS 18.0 Build Type: Local development build using a Developer Provisioning Profile Sandbox account signed in during testing 🔑 2. Entitlements (Developer site & Xcode) In Certificates → Identifiers → App ID, both capabilities are enabled: StoreKit External Purchase StoreKit External Purchase Link The .entitlements file in Xcode includes: com.apple.developer.storekit.external-purchase = YES com.apple.developer.storekit.external-purchase-link = YES The Provisioning Profile also contains both entitlements (confirmed via codesign -d --entitlements :-). 📄 3. Info.plist Configuration Both keys are configured with correct region codes according to documentation: SKExternalPurchase SKExternalPurchaseCustomLinkRegions 🌍 4. Test Storefront Device storefront verified as United States (US) or Portugal (PT) (US = target region for External Purchase Link, PT = EU region) But despite all the above configuration, both API calls consistently return false: ExternalPurchaseLink.canOpen // false ExternalPurchaseCustomLink.isEligible // false So I cannot proceed to testing the remaining flow (token retrieval, link opening, etc.) ------ Questions ------ ❓ Q1) Local Development Build Limitation Is it expected behavior that Developer-signed local builds always return canOpen = false / isEligible = false for External Purchase Link & Custom Link? Is there a technical or policy restriction that prevents eligibility in local dev builds? ❓ Q2) App Store Connect Configuration Requirement Are there mandatory App Store Connect settings (such as external purchase URLs, support URL, disclosures, or country configuration) that must be enabled before eligibility becomes true? Currently, no External Purchase Link or Custom Link menu is visible in my App Store Connect app settings. Is this menu only available after certain approvals or under specific conditions? ❓ Q3) TestFlight Requirement Do External Purchase Link and Custom Link only return eligibility = true on: TestFlight builds, or Distribution-signed builds? Or should eligibility also work on developer builds? Formal confirmation would be helpful. ❓ Q4) Developer Account Type Limitation We are using an Individual Developer Account (not Organization). Can Individual accounts fully request, test, and ship apps using: External Purchase Link External Purchase Custom Link Or are there limitations on account type? 🙏 Request We have completed all documented setup steps (Entitlements → Provisioning → Info.plist), but eligibility remains false, blocking feature validation. Please clarify which of the following is the cause: Local development builds do not support eligibility Missing App Store Connect configuration (not visible to us) Account type restriction Region rollout or entitlement approval requirement Any additional setup not documented publicly Thank you for your assistance.

App: com.playatrium.mobile Issue: StoreKit 2's Product.products(for:) returns USD pricing regardless of account region on TestFlight builds. Account/device confirmed UK at every layer I can check: App Store Connect developer account region: UK Personal Apple ID Media & Purchases country/region: UK Device region: UK No .storekit configuration file present in the project In-App Purchase capability confirmed enabled on the App ID The native purchase sheet, for the SAME product in the SAME app session, correctly resolves and displays GBP, and purchases complete successfully with correct entitlement grants on our server. So the purchase flow itself resolves the storefront correctly — only the catalog/pricing query does not. Console.app shows the account object with storefront = (null) at the moment of the catalog query: account = <ACAccount: ... storefront = (null)> and the resulting request falls back to /catalog/us/ with locale es-MX, rather than the correct territory. I've seen a few threads here with similar symptoms (products returning empty or wrong-region data on TestFlight specifically, working fine via local StoreKit config in the simulator) but haven't found a clear explanation or fix. Anyone know why Storefront.current / the catalog query would fail to resolve correctly on TestFlight while Product.purchase() resolves fine in the same session?

I am experiencing a StoreKit issue on iOS 27 Beta with eFootball™ 11.0.0 (jp.konami.pesactionmobile). After an in-app purchase, the app becomes stuck on an infinite loading screen during login. If I manage to log in, the in-game Shop also remains stuck loading. I investigated the issue using macOS Console and found that StoreKit repeatedly attempts to finish the same production transaction every approximately 2–3 seconds. The relevant logs are: Starting request FinishTransactionRequest(...) Failed to encode request parameters NSCocoaErrorDomain Code=3840 Error finishing transaction: StoreKitServiceError StoreKitInternalError.requestEncodeFailed The same transaction is repeatedly passed to FinishTransactionRequest, but the finish operation never succeeds. What I have confirmed The purchase itself was confirmed by Apple Support as successfully completed. The transaction is a Production transaction with the JPN storefront. Reinstalling eFootball does not resolve the issue. Restarting the iPhone does not resolve the issue. Signing out and back into "Media & Purchases" with the affected Apple Account does not resolve the issue. Network requests from the app itself are succeeding with HTTP 200 responses. The issue occurs when StoreKit attempts to finish the transaction. Most importantly, if I sign out of the affected Apple Account under Media & Purchases and sign in with a different Apple Account on the same iPhone, eFootball immediately works normally again — both login and the Shop load successfully. If I switch back to the original Apple Account, the issue returns. Steps to reproduce Use the affected Apple Account for Media & Purchases. Launch eFootball. Attempt to log in. The app remains stuck loading. Observe Console logs from storekitd. The same transaction repeatedly triggers FinishTransactionRequest. Each attempt fails with StoreKitInternalError.requestEncodeFailed. Expected behavior StoreKit should successfully finish the completed transaction, remove it from the unfinished transaction queue, and allow the app to continue normally. Actual behavior FinishTransactionRequest repeatedly fails with requestEncodeFailed, causing the same transaction to be processed indefinitely and preventing normal use of the app. Has anyone encountered the same behavior on iOS 27 Beta? Is this a known StoreKit issue, or is there any way to safely clear/finish the affected production transaction without restoring the device to the current public iOS release?

We have an auto-renewable subscription in our app that we want to stop offering. However, we want to make sure that people who have already purchased the subscription remain subscribed until the end of their current subscription period (and are subsequently unsubscribed and not charged further). What is the right way to do this?We tried submitting the app with the subscription still enabled in App Store Connect but hidden in the app, and our update was rejected because the reviewer couldn't find a way to subscribe.Thanks,Frank

Transaction.finish() doesn't clear a transaction on iOS 27 beta 5 — worked correctly through beta 4 — every repeat purchase after the first replays the same transaction with no confirmation sheet and no charge. StoreKit.Transaction.finish() does not clear a transaction on iOS 27 beta 5. The transaction remains in Transaction.unfinished indefinitely, and every subsequent Product.purchase() call for that product returns the same stale transaction instead of starting a new purchase — with no confirmation sheet, no charge, and no way for the app to tell it apart from a genuine purchase. Because the replayed result is .success carrying a VerificationResult that verifies normally, an app has no supported signal that nothing was bought. The only distinguishing traits are that the id and purchaseDate are unchanged and the call returns in ~10ms instead of making a server round-trip. Consequence: a consumable product can be purchased exactly once per device. Every later attempt silently no-ops while appearing to succeed. Steps to Reproduce On a device running iOS 27 beta 5, sign in to a newly created Sandbox Apple Account (Settings → Apps → App Store → Sandbox Account) with no prior purchase history. Install and launch a development build of an app offering a consumable IAP. Confirm Transaction.unfinished is empty. Purchase the consumable. The confirmation sheet appears and the purchase completes normally. await transaction.finish() on the returned transaction. Enumerate Transaction.unfinished again. Purchase the same consumable a second time. Expected Results Step 6: Transaction.unfinished is empty — the transaction was finished. Step 7: a confirmation sheet appears and a new transaction is created, with a new id and a current purchaseDate. Actual Results Step 6: the just-finished transaction is still listed in Transaction.unfinished. Step 7: no confirmation sheet appears. purchase() returns .success in ~0.01s carrying the same transaction — identical id and identical purchaseDate — and nothing is charged. This repeats indefinitely. Re-fetching the transaction from Transaction.unfinished and calling finish() on that instance does not clear it either, so there is no app-side way to drain the queue. Diagnostic Log Virgin sandbox account, empty queue, three consecutive taps on one product: unfinished before tip.small: [] purchase() returned after 18.10s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 --- await transaction.finish() --- unfinished after finishing 2000001221113013: [small#2000001221113013] unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 The first call is a genuine purchase (18s round-trip, sheet shown). The transaction survives its own finish(). Calls two and three are replays of it. Notes Not reproducible against a local .storekit configuration in the Simulator, which always presents the confirmation sheet. Requires Apple's sandbox. Also reproduces on a TestFlight build billed to a real Apple ID, where it is worse: TestFlight purchase history cannot be reset, so the affected products stay permanently stuck for that account. It survives deleting and reinstalling the app, and a device reboot. Possibly the same underlying issue as the unanswered report at https://developer.apple.com/forums/thread/808648 (iOS 26/18, Nov 2025). Configuration Device: iPhone 16 Pro Max OS: iOS 27 beta 5 Products: consumable in-app purchases API: StoreKit 2 (Product.purchase(), Transaction.finish(), Transaction.unfinished)

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!

Hi everyone, I'm developing a digital retail application which acts as a digital storefront/marketplace where users can purchase standard prepaid gift cards and entertainment store credits (such as PlayStation, Xbox, and Steam gift cards). To give you a clearer picture of how our app and payment system work: The app allows users to browse a catalog of prepaid gift cards and vouchers. When a user decides to purchase an item, they complete the transaction within the app using localized/third-party payment gateways (such as regional digital wallets and online payment providers). Upon successful payment, the app securely fulfills the order by displaying the purchased prepaid code or voucher, which is meant to be redeemed externally on the respective platform's website or app. However, Apple's App Review team keeps rejecting the app under Guideline 3.1.1 (In-App Purchase), stating: "The app allows users to purchase or sell digital items, codes, or currencies to be used in other apps or third-party platforms." We are not selling software licenses or unlocking features inside iOS apps; we are simply selling standard prepaid gift cards through external/local payment methods, similar to traditional physical retail cards. Has anyone faced a similar rejection while using external/regional payment gateways for a gift card or e-commerce app? How did you structure your app metadata, app description, or appeal to satisfy Guideline 3.1.1 without entirely removing the checkout flow? Any insights or advice would be greatly appreciated. Thanks!

I'm seeing IAPError(code: storekit_no_response, source: app_store, message: "StoreKit: Failed to get response from platform.") when calling queryProductDetails() (via Flutter's in_app_purchase/in_app_purchase_storekit plugin) for all 6 of my app's In-App Purchase products. This happens consistently on a real device (iOS 18.7.9), including after a full device restart. I've followed the entire TN3186 checklist: Paid Apps Agreement: Active Banking: Active Tax Forms: Active Bundle ID matches App Store Connect and Certificates/Identifiers/Profiles In-App Purchase capability is enabled on the App ID All 6 product identifiers match exactly and are attached to the app version under review Pricing is set for all territories on all products None of this resolves the error. This also caused an App Store review rejection citing "In-app purchase products... could not be found in the submitted binary" for the same reason. Bundle ID: com.playadda.playadda Product IDs affected: gems_pack_100, gems_pack_500, gems_pack_1200, premium_monthly, battle_pass_s1, starter_pack Has anyone found a resolution to this specific error beyond the standard TN3186 checklist?

Hi, I have deployed my app on Test Flight, I have two subscriptions, monthly and yearly. User can have one of them at a time and upgrade, downgrade to the other. Upgrade, downgrade, cancel from the Apple Settings worked fine in the sandbox environment when testing locally. Now when I have deployed the app on TestFlight, I was able to purchase the subscription successfully from my app. Now when I want to cancel my subscription from the Apple Settings it gives me the following error after confirming cancellation, 'Your request is temporarily unable to be processed. Please try again later.' Also the other subscription offer (yearly) is also not shown to which I could upgrade, even though in the sandbox I was able to upgrade downgrade from the settings. Another thing I have noticed is that the app Icon or name is not shown anywhere in settings with the subscription. Instead of app icon only empty square is shown. Even though app icon shows fine everywhere else. Can someone please help me figure out this issue?

Hi, Overview In my project I am using a .storekit StoreKit configuration file that is synced. I have only non-consumable products Problem When I loop through Transaction.currentEntitlements after verification the properties such as transaction.productType are all NULL. Note I have called .finish on the transaction after the following: Processing Transaction.updates Processing purchasing a new product Environment: Xcode 27 Beta 5 iOS 26.6 Questions How can I resolve this? Am I missing something? Should I be using Transaction.latest(for:) instead of Transaction.currentEntitlements?

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?

FB: https://feedbackassistant.apple.com/feedback/22556883 We're seeing a small number of production users where both Transaction.currentEntitlements and Transaction.all return zero transactions for a valid, active, non-refunded non-consumable IAP. This makes it impossible to restore the purchase via any StoreKit 2 API. Environment: Xcode 26.4 (Build 17E192) iOS 26.4.1 Direct call to SK2 Transactions.all & Flutter in_app_purchase package v3.2.3 (uses SK2 on iOS 15+) Non-consumable IAP (one-time purchase) What we observe: AppStore.sync() triggers but the purchase stream returns 0 transactions Transaction.all returns empty Transaction.currentEntitlements also returns empty User is confirmed on the correct Apple ID Issue reproduces on both iPhone and Mac for the same Apple ID Issue appears to have started recently for users who previously had no problems Debug log from affected production user: [2026-04-20T08:50:10.744115Z] init: iapAvailable=true [2026-04-20T08:50:10.744566Z] init: isPremium=false [2026-04-20T08:50:10.744567Z] init: triggering silent restorePurchases [2026-04-20T08:50:45.974566Z] restore: started [2026-04-20T08:50:45.986848Z] restore: sk2Transactions count=0 [2026-04-20T08:50:45.993004Z] restore: sk2Direct isVerified=false active=null [2026-04-20T08:50:45.993011Z] restore: sk2Direct inconclusive — falling back to standard restore [2026-04-20T08:51:16.000851Z] restore: timed out after 30s — fallback isPremium=false [2026-04-20T08:51:16.000910Z] restore: completed — succeeded=false foundPurchase=false Unable to reproduce in sandbox — Transaction.all works correctly there. Appears specific to production for a small subset of users. Has anyone else seen this?

Product: Auto-renewable annual subscription Environment: Production iOS version: 26.6 StoreKit version: StoreKit 2 I have an active subscription that shows correctly in the App Store app, but neither Transaction.currentEntitlements nor Product.SubscriptionInfo.Status (via subscription.status) return any record of it — both come back empty. What I've checked: Transaction.currentEntitlements — iterated fully, zero transactions found for this product ID Product.SubscriptionInfo.Status — checked independently as a second signal, also returns no active status for this product AppStore.sync() — called before checking entitlements, completes successfully, does not resolve the issue Settings → [Apple ID] → Subscriptions on-device — does not show this subscription "Restore Purchases" in-app — consistently reports nothing found Impact: Since my app gates access behind an active entitlement check, this means the user is stuck on the paywall screen indefinitely, despite having a valid, active, paid subscription. There's no client-side workaround, since every available StoreKit 2 API reports no entitlement exists. Code pattern (simplified): swift for await result in Transaction.currentEntitlements { if case .verified(let transaction) = result, transaction.productID == productID { // never reached for this product } } if let subscription = product.subscription { let statuses = try await subscription.status // statuses is empty / doesn't reflect the active subscription } This looks consistent with the pattern reported in thread 823454, where currentEntitlements and Transaction.all return empty for valid, non-refunded purchases in production for a small number of users. In my case, this is affecting a currently active subscription — not a refunded or expired one — and is reproducible on this account across multiple app builds. Has anyone found a reliable workaround, or is this being tracked by Apple as an active known issue beyond the fix already applied for the non-Gregorian calendar case (which doesn't apply here)?

iOS 26.4系统上，我们发现三个问题： 1.调用了finishTransaction接口，但是在App重新启动后，[SKPaymentQueue defaultQueue].transactions仍然会有这笔订单。 2.支付完成后，[[NSBundle mainBundle] appStoreReceiptURL]]，拿到的票据解析出来里面的商品是空的，需要延迟2秒钟左右在调用[[NSBundle mainBundle] appStoreReceiptURL]]才能获取有效票据。 3.支付完成后，如果用户没有点击最后弹出的确认弹框，等待5秒钟，系统会自己回调 - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions; 代理方法。正常应该是用户点击了最后弹出的确认弹框，在回调- (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray<SKPaymentTransaction *> *)transactions;方法。 我们在苹果开发者论坛上面找到其他开发者反馈的类似问题，链接如下： https://developer.apple.com/forums/thread/817700 https://developer.apple.com/forums/thread/792437?answerId=849557022#849557022 https://developer.apple.com/forums/thread/817834 https://developer.apple.com/forums/thread/817706 https://developer.apple.com/forums/thread/818586 我们有大量用户升级到了26.4系统，这对于我们造成了巨大的困扰，我们需要你们的帮助，感谢！

We are investigating SKAdNetwork attribution for a production iOS app distributed through the App Store. Bundle ID: com.stencilstudio.app App Store ID: 6760613806 We receive real winning SKAdNetwork postbacks directly from the App Store at our attribution endpoint. The raw Apple payloads consistently contain: version: "3.0" campaign-id: 25 did-win: true Some postbacks also include a valid fine conversion value, for example: conversion-value: 1 However, we have not received postbacks containing: version: "4.0" source-identifier postback-sequence-index coarse-conversion-value The advertising network is Meta. The advertised app is App Store distributed and has an iOS deployment target of 16.1. We are trying to understand one specific technical point: What determines whether the resulting production attribution postback is SKAdNetwork 3.0 or 4.0? In particular: Is the postback version determined by the SKAdNetwork version used by the ad network when signing the winning ad impression? Can anything on the advertised-app side, such as an entitlement, App Store Connect setting, build configuration, registration state, or SDK configuration, cause an attribution to remain on version 3.0? Is there any advertiser-side diagnostic that allows the advertised-app developer to determine which SKAdNetwork version the winning impression was signed with? Given that the postbacks themselves explicitly contain version: "3.0", is there any other condition we should verify on the advertised-app side before asking the ad network to investigate how its impressions are being signed? Example raw postback received directly from the App Store: { "app-id": 6760613806, "fidelity-type": 1, "conversion-value": 1, "campaign-id": 25, "did-win": true, "version": "3.0", "ad-network-id": "v9wttpbfk9.skadnetwork", "redownload": false } We can provide additional production postbacks if useful.

TL;DR: Does iOS automatically receive App Store transaction updates in the background when internet connection is available so the backing storage state of Transaction.currentEntitlements gets synced even when my app is not running? Or does iOS update Transaction.currentEntitlements only when my app is running? The long version: Imagine the following situation: A user has purchased a non-consumable IAP in my app and is granted the locked premium content. The IAP transaction is now present in Transaction.currentEntitlements (it's also cached locally). The user blocks internet access every time before my app gets opened (either enables the Airplane mode and/or disconnects from the Wi-Fi before launching my app). So from this point on, my app never gets a chance to connect to the internet. The user gets refunded for the IAP. The user uses their iPhone to browse the internet via Safari, checks emails, etc. Then, before launching my app, the user blocks internet access. My app gets is launched (without internet access) and reads entitlements from Transaction.currentEntitlements. The question is: does the StoreKit service know that the IAP has been refunded? Did iOS update the local cached storage of Transaction.currentEntitlements while the user was connected to the internet in step 4? Or will Transaction.currentEntitlements contain the old state from step 1 so the app won't know about the refund and the user will be able to use my app's premium content which has been refunded by now? Is the behavior the same for auto-renewable subscriptions as it is for non-consumable IAPs?