All of a sudden both our development and production app stopped loading products for the subscription screens. Within our code I noticed that product.products is always returning 0 elements even after confirming product ids are correct and ensuring all agreements in App Store Connect are signed and active. What could be the issue?

Our app offers auto-renewable subscriptions using StoreKit Original API for In-App Purchase and App Store Server Notifications V1. Starting around 2025-03-15, we found some cases where original_transaction_id which was associated to web_order_line_item_id of already purchased subscription had changed in the receipt information of verifyReceipt response or App Store Server Notifications V1. The detailed steps are: Around February 2025, re-purchase from the app the same subscription product which was canceled and expired some time ago, using StoreKit Original API for In-App Purchase Receive the following 2 notifications from App Store Server Notifications V1 almost at the same time INITIAL_BUY DID_CHANGE_RENEWAL_STATUS In both notifications, latest_receipt_info contains the receipt for the re-purchased subscription period with new original_transaction_id and web_order_line_item_id pending_renewal_info contains both new original_transaction_id and original one which was generated at first purchase, and original one has "is_in_billing_retry_period": "1" Starting around 2025-03-15, the following happens When we receive another "DID_CHANGE_RENEWAL_STATUS" notification from App Store Server Notifications V1, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription period has changed back to the original one (the one which was generated at first purchase) in latest_receipt_info. When we call verifyReceipt with the receipt obtained from appStoreReceiptURL, the response does not seem to contain new original_transaction_id which was generated at re-purchase We have some questions regarding this original_transaction_id behavior. When a user re-purchase the same subscription product which was canceled and expired some time ago, it seems that new original_transaction_id is generated. Is this an expected behavior? If yes, it seems that, at some point, original_transaction_id which is associated to web_order_line_item_id of the re-purchased subscription changed back to the original original_transaction_id which had been generated at first purchase. Is this an expected behavior? What triggers the original_transaction_id change to the original one? Is it related to some user actions or subscription status change?

Hi everyone, I'm submitting my watchOS-only app and its In-App Purchase for the very first time (both app and IAP submitted simultaneously). After multiple rejections, I still can't resolve the issue and would appreciate any guidance. Environment: App type: watchOS-only (no iOS companion app) First submission of both the app and IAP IAP type: Non-Consumable, Product Apple ID: 6770497337 The problem: The reviewer (App Review) states that the IAP product information cannot be retrieved in the review environment. According to the reviewer, they are testing in the production environment, not the sandbox. However: In my TestFlight build, the app correctly retrieves the IAP product I have successfully completed the full purchase flow using a sandbox account All business agreements (including Paid Apps Agreement) are accepted and active in The Bundle ID and Product ID are correctly configured in both Xcode and App Store Connect Current IAP status in App Store Connect: Overall status: "Developer Action Needed" All localizations (English US/UK/AU/CA, Japanese, Simplified Chinese, Traditional Chinese): "Rejected" No specific rejection reason is shown anywhere in App Store Connect Any help would be greatly appreciated. Thank you! 🙏

My auto-renewable subscription products are approved in App Store Connect, but fetchProducts() returns 0 products when testing in Production & Testflight. Debug output shows: "products.size is 0 - no products fetched! Expected 6 products." All my business agreements are active. Has anyone faced this before? What do you recommend? Thank you.

APP被下架后是否会影响之前已经订阅了自动续费产品用户的定期扣费

Is anybody else seeing this? Since iOS 26.4, calling SKPaymentQueue.restoreCompletedTransactions() no longer returns any transactions for active auto-renewable subscriptions. The success callback is invoked correctly, but the transactions array is empty. The same device and the same Apple ID return the expected transactions on iOS 26.3.1 and earlier. Environment Affected: iOS 26.4.x (confirmed on 26.4.2) Working: iOS 26.3.1 and earlier Product type: Auto-renewable subscriptions Deployment target: iOS 14.0 Steps to reproduce Have an active auto-renewable subscription on an Apple ID (sandbox or production) Run on a device with iOS 26.4 or later Call SKPaymentQueue.default().restoreCompletedTransactions() (or the equivalent via a wrapper such as RMStore) Observe the paymentQueueRestoreCompletedTransactionsFinished delegate callback Expected behaviour The delegate receives the restored transactions via paymentQueue(_:updatedTransactions:) before paymentQueueRestoreCompletedTransactionsFinished is called, as documented. Actual behaviour paymentQueueRestoreCompletedTransactionsFinished is called immediately with no prior transaction updates. The transactions array is empty.

Hi, I'm experiencing an issue with StoreKit 2 in my iOS app where Product.products(for:) always returns an empty array on a real iPhone device. 📱 Environment iOS: 26 Device: iPhone 16 pro max Xcode: 26.5 StoreKit: StoreKit 2

Hi, I’m experiencing an issue with StoreKit 2 in my iOS app where Product.products(for:) always returns an empty array on a real iPhone device. iOS: 26 Device: iPhone 16 pro Max Xcode: 26.5 StoreKit: StoreKit 2

Greetings fellow devs, After accepting the Alternative Terms Addendum for Apps in the EU and adding the Storekit External Purchases or Offers capability via App Store Connect in our app identifier, the entitlement showing up in xcode is com.apple.developer.storekit.custom-purchase-link.allowed-regions and has the value 'jp'. How can we change the value for that entitlement to 'gr'? We tried changing it in xcode, but we get the error <Provisioning profile "iOS Team Provisioning Profile: [app identifier]" doesn't match the entitlements file's value for the com.apple.developer.storekit.custom-purchase-link.allowed-regions entitlement.>. In Certificates, Identifiers and Profiles in the developer account there is no way to configure that capability. We sent a request to support and they only gave a link to documentation and to the forum here. We have a completed every business agreement requested and we have chosen Greece as the organisation region and the app's availability region wherever possible. We haven't found anywhere that Japan would be chosen to explain the entitlement given. So where can this entitlement about allowed regions be configured? Xcode version is 16.4 and iOS minimum deployments is 18

I am testing a situation when user cancels auto renewable subscription (via StoreKit->Manage Transactions window). The problem is StoreKit2 does not provide an update when subscription was cancelled. I started using demo from apple developer.apple.com/documentation/storekit/in-app_purchase/implementing_a_store_in_your_app_using_the_storekit_api to test this behaviour in order to get rid of possible mistakes in my implementation, but result is the same - when user cancels subscription app does not receive any storekit events (change in renewal info, update in current entitlements, transaction status - nothing) and only after app's relaunch it fetches everything from scratch and finally updates UI. I tried to wait for up to 20 minutes to check whether this update in transaction (subscription) status will be delivered to the app - still nothing. So the problem, as I see it, is that if user cancels subscription and then does not relaunch the app he can continue to use the app for free for a long time. In this regard I have several questions: is it expected behavior of StoreKit2? If yes - why? Does it happen in Test Flight mode or in production env as well? If it's not expected behavior then is it correct to fix it with checking (lets say once in an hour) user's current entitlements (I tried and it seems to work ok) or there are better solutions?

I'm implementing EU external purchase using ExternalPurchaseCustomLink. No IAP transactions are offered on EU storefronts — payment happens entirely on our external website. I want to call Product.products(for:) on EU storefronts solely to fetch localized product metadata (displayName, displayPrice, currency formatting) for display. Product.purchase() will never be called. Is it acceptable to use Product.products(for:) for read-only product info display on EU storefronts where only external purchase is offered?

We are seeing trial conversions for our auto-renewable monthly subscription wingman_monthly (App ID 6758346525) land in a persistent "Pending" state in users' iOS Purchase History after the 3-day free trial ends, with no debit reaching the user's payment method. App Store Server Notifications V2 indicate the renewals succeeded — each affected transaction is delivered as DID_RENEW (subType BILLING_RECOVERY not present) with is_trial_conversion: true, period_type: NORMAL, a new expires_date set 31 days in the future, AUD 19.99 attributed, no expirationIntent, no is_in_billing_retry_period, and no cancellation_reason. So Apple's billing layer reports the renewals as successful, but settlement does not appear to complete. The same trial-to-paid flow on our yearly product wingman_yearly in the same subscription group converts and debits cleanly. The pattern is specific to wingman_monthly.

My tvOS app includes the purchase of subscriptions, and I am updating the code with Storekit 2.0. I have seen other apps that present the "Confirm with Apple Device" UI upon selection of a product, but for me I only ever see an alert confirming the purchase. I have tested this using Xcode storekit data and a sandbox account. I have also attempted using Storekit views and passing the UIWindowScene to the purchase(confirmIn: ) parameter, but neither made any difference. Is there some limitation that prevents that UI from showing in debug builds?

Hey! App is approved for Advanced Commerce API and have generic product id (Consumable) for digital items purchasing. Uncertain on ho to test flow of pending purchase changing it's status to failed. As by docs BE side handling creating jws for purchase (also creates order to keep track of which items user bought) app with signed jws initiate purchase via product.purchase (send data for advancedCommercialData in options). If product purchase returns status .pending (still no transaction created) I notify BE that for that item (using item SKU) user has pending status for purchase, so that when user attempts to buy this exact item we do not create order duplicate. So the first question - do we need to check if user already made an attempt to buy this item and if item purchasing is pending decline another attempt of buying it? If user sends several requests to buy item under similar SKU for advanced commerce api do all of them will be charged or only one (does apple check SKU value when making a purchase of consumable product via advanced commerce api)? Another question is how to test purchase returns pending status for consumable item via advanced commerce api and then for that item (by SKU) changes status from pending to success? How to know (and eventually) test that after purchase of item via advanced commerce api firstly returns .pending status and then changes to .failure? I want to prevent users from trying to create order duplicates for single item, so when product purchase returns pending status I sent to BE id of item and order for this item on BE side will be marked as pending. So if user tries to buy this exact item once more and status of order on BE still .pending no new purchase will be initiated. So I need to know when purchase changes it's status to failed and then delete pending order on BE side, so that user will have an ability to initiate purchase for this item once more. How to tell whether .pending status for item changes to failed, will I be able in case of failed gather SKU that I previously passed in advancedCommercialData)?

My first auto-renewable subscriptions have been stuck in “In Review” for almost two weeks. Apple’s notice says the first subscription must be submitted with a new app version and selected from the “In-App Purchases and Subscriptions” section on the version page. However, my version page does not show that section, even after creating a new version in Prepare for Submission. The only place I can see the subscriptions is from the Subscriptions side tab. The app itself has already been approved, but StoreKit does not return the products in production, so my paywall cannot sell subscriptions. Has anyone found a working fix for this, or does Apple need to manually reset/review the subscription state?

On devices configured to use the Buddhist calendar (primarily Thai users) Transaction.currentEntitlements returns an empty async sequence even when the customer holds a legitimate, non-revoked, non-expired entitlement for a non-consumable in-app purchase or subscription. The same transaction is correctly returned by Transaction.all. Switching the device calendar back to Gregorian immediately restores correct behavior: the entitlement is yielded by currentEntitlements again. No reinstall, sign-out, or AppStore.sync() is required. The defect is purely client-side, deterministic, and reproducible at will. Is this a known bug introduced in iOS 26? It is causing me significant problems with in-app purchase validation and restore flows in that market. Is anyone else experiencing this issue?

Hi all, Reporting an active production issue in case anyone else is seeing the same pattern, or has insight into what could cause this. Symptom As of 2026-05-09 morning, one specific auto-renewable subscription product is silently absent from Production StoreKit responses on our live App Store build. The product is still 'Approved' in App Store Connect, all metadata is intact, no error code is returned — the product simply does not appear in the products array. The other 3 products in the same subscription group continue to work normally. 100% of production users are affected. Setup App: live on App Store, version 1.0.0 (build 8) Subscription group with 4 auto-renewable products: standard_monthly_799 ✅ returns correctly standard_annual_6999 ✅ returns correctly unlimited_monthly_1299 ❌ MISSING from production response unlimited_annual_9999 ✅ returns correctly SDK: purchases_flutter (RevenueCat) → StoreKit Same physical device, same code, same RC config behaves correctly in Sandbox — all 4 products are returned and a sandbox purchase of unlimited_monthly_1299 succeeds. Timeline 2026-05-08: working correctly, purchases succeeding normally 2026-05-09 morning: product silently disappears from production StoreKit responses No app update was submitted between those dates No App Store Connect changes were made Onset was simultaneous across all production users at one timestamp What I've verified App Store Connect: Product status: Approved All territories enabled, all prices configured (no N/A in any territory) Subscription group correctly contains all 4 products No 'Submit for Review' pending changes Product attached to live app version 1.0.0 (8) Tax category: Match to parent app Family Sharing: Off (consistent with the working products) Paid Applications Agreement: Status: Active Banking and Tax forms: Active RevenueCat dashboard: All 4 products show Store Status: Approved Default offering contains all 4 packages iOS attachment for the affected product is intact No warnings or sync errors Sandbox StoreKit (today): flutter run (debug) on physical device → all 4 products returned flutter run --release on physical device → all 4 products returned Sandbox purchase of unlimited_monthly_1299 succeeds Production StoreKit (today, broken): App Store-downloaded 1.0.0 (8) on multiple users' devices Multiple Apple IDs / multiple devices / multiple regions — all reproduce Only unlimited_monthly_1299 affected; other 3 products fine Why this looks server-side Sudden simultaneous onset across all users No code or config change preceded onset Sandbox unaffected, only Production affected Single product affected, not the whole subscription group or app No error returned — silent omission only Cannot reproduce with locally signed builds, only with App Store-distributed binary This pattern is consistent with a server-side product indexing or fronting issue specific to one product in Production StoreKit. As a developer I don't have visibility into Apple's product-serving infrastructure to investigate further — looking for guidance from anyone who has seen this before. Questions for the community Has anyone else seen a single auto-renewable subscription silently drop out of Production StoreKit responses while remaining Approved in ASC, with no error code returned? Is there any internal product-state flag (beyond what's exposed in the ASC UI) that could cause Production StoreKit to silently omit a product? Anything similar to a hidden 'review hold' or 'price tier reconciliation' state? Has the asymmetry between RevenueCat package identifiers (Standard uses RC's $rc_monthly/$rc_annual default identifiers, Premium uses custom premium_monthly/premium_annual identifiers) ever been implicated in this kind of failure? RC support has been notified, but worth asking publicly. For anyone who has resolved a similar issue: what action ended up clearing it — ASC re-save, RC re-sync, Apple Support escalation, or did it self-resolve after Apple-side cache propagation? Filings in progress ASC Contact Us ticket: filed Apple DTS technical incident: filed RevenueCat support ticket: filed Feedback Assistant report: in progress Will update this thread with the resolution path once we have one. Thanks, — Kin Pong Lo (developer, Alice: AI English Tutor)

Hi all, I've been observing what appears to be a timing mismatch in how Apple handles Korea trial-to-paid consent, and I wanted to see if other developers are seeing the same thing. Per Korean regulations effective Feb 14, 2025, Apple must obtain explicit user consent before converting a free trial to a paid subscription. Apple handles this via email, push notifications, and an in-app consent option accessible from Settings > Subscriptions. For a 7-day trial in the Republic of Korea storefront, I'm observing: Consent push notifications (Agree to continue your subscription without interruption) start arriving ~1 day after trial redemption, at roughly hourly frequency. However, when the user taps the push and navigates to Settings > Subscriptions, there is no consent option available. The only visible action is "Cancel Free Trial". The consent option only becomes available around day 4 of the trial (i.e., 3 days before renewal, matching Apple's documented messaging cadence [1]). For the first ~3 days, users receive hourly push notifications they cannot act on. The only way to stop them is to cancel the subscription entirely. This is happening across multiple apps in the Korean App Store, so it appears to be a platform-level behavior rather than an app-specific issue. Is anyone else observing this behavior? Any insight from Apple engineers or other developers would be greatly appreciated. [1] https://developer.apple.com/help/app-store-connect/reference/in-app-purchases-and-subscriptions/consent-for-subscription-offer-conversions

We get this error in our App when users try to purchase a subscription. "Invalid Product ID" The respons from Apple backend is: (NOBRIDGE) LOG {"code": "E_DEVELOPER_ERROR", "debugMessage": "Invalid product ID.", "message": "Invalid product ID.", "productId": "com.familycal.daysi.one.month.version71"}

I had published an App, and my app has App Clip supported. The issue I faced is that I had received complaints where the user keep seeing the pop up "Apple Media Services Terms and Conditions Have Changed" when user clicked on the "Open" Button in the App Clip. What we had tried so far: Let user switch the Apple Id's region to our supported region. Let user try to log out and log in to Apple Id within the supported region.