Hi! I’ve just recently launched a feature that could be subscribed to (.autoRenewable) or alternatively unlocked with a one-time purchase (.nonConsumable). I want both methods to be shareable with Family Sharing, however at launch I had forgotten to enable Family Sharing on the one-time unlock. I enabled it like one hour after launch. As I understand it, when I consult Transaction.currentEntitlements on a family device, both IAPs should just show up. This works with the subscription, but not with the unlock – even for people who have purchased it two days after I made it shareable, which sounds like enough time for the setting change to propagate. When I load the products now, using Product.products(for: productIDs), both the sub and the unlock report that isFamilyShareable is true. Could the unlock IAP be in a buggy state on the App Store side, where it’s nominally shareable but doesn’t actually get shared when purchased? And if so, how can this be resolved? If not, what am I doing wrong? 😅 Thanks for your time 🙏

My Non-Consumable IAP was rejected with Guideline 3.1.1 and now has status ‘Developer Action Required’. The problem: On the version page in App Store Connect, the ‘In-App Purchases and Subscriptions’ section does not appear at the bottom. I cannot link the IAP to a new version submission. Every time I submit a new binary, Apple approves the app version but rejects the IAP afterward — even though I have no way to attach it to the version in the first place. This seems to be a circular issue: the IAP doesn’t appear on the version page because of its current status, but the only way to fix the status is to submit it with a new version. Has anyone experienced this and found a solution? Any help appreciated!​​​​​​​​​​​​​​​​

We're currently having an issue with our app where the review prompt is displaying for the user too often. I know the documentation says that: If the person hasn’t rated or reviewed your app on this device, StoreKit displays the ratings and review request a maximum of three times within a 365-day period. If the person has rated or reviewed your app on this device, StoreKit displays the ratings and review request if the app version is new, and if more than 365 days have passed since the person’s previous review. From this post I can see that there's an updated API that is recommended AppStore.requestReview(in:). Is there a currently known bug with the SKStoreReviewController version that would cause the review prompt to display outside of the limitations? Locally we're seeing a limit of 3 prompts in the same session but a few days later, we get the same 3 prompt limit when it's should have been limited for another year. Does using the AppStore version just fix our issue? Is it actually a different API?

Hello, I would like to understand the possible end-user journey when a subscription transitions into the DID_FAIL_TO_RENEW state. During this period—when the App Store continues to retry billing for up to 60 days, or until the user resolves the billing issue or cancels the subscription is the user allowed to purchase the same subscription again? If so, my understanding is that this would follow a resubscribe flow, rather than an initial purchase flow. Could you please confirm and provide further details on how this scenario is expected to behave?

When an auto renewing subscription is "Developer removed from sale", any auto renewal should fail. Will this make the subscription enter billing "Grace Period"? Our expectation is that the rewal would fail without entering a "Grace Period".

I'm trying to use a sandbox account, and am stuck on the verification stage. My primary number (my personal iPhone phone number) has been used too many time, as I've used it to set up many devices. My personal mobile number is tied to a physical SIM in my iPhone 12 Pro. Now I'm trying to use a Freedom Mobile eSIM, and can successfully send and received texts to/from myself, other people, to/from Freedom Mobile as well. Setting up the sandbox account (my email address with a +3 at the end of it) I choose USE A DIFFERENT NUMBER and my eSIM number is shown along with my "Freedom" description of the eSIM right below it. The Verification Code page appears, but I never get a verification code. I click on DID NOT GET A VERIFICATION CODE? and try trigger a phone call and do not get that either. I've reset my eSIM, I've reset my iPhone's networking, I've rebooted my phone many times, I've un/re-installed the app and TestFlight. I'm willing to try anything here, but is it possible because my personal mobile number (which is tied to my personal Apple ID) not having any spare slots (or whatever we call them) that is why the eSIM is also being impeded, although not telling me that is why? Can Apple increase the number of verifications I can do with my primary mobile number? So I can nevermind this eSIM? Can Apple try text me on my eSIM, and see if there is some sort of generic Apple issue with it and not just this sandbox system?

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)?