Hello! My subscriptions have been stuck in review for a while. I have been chasing my tail trying to get the sandbox purchases to work but the subscriptions are not returning after "sale". Is this because the subscriptions are still in review? Will the purchase ever return a product in the sandbox environment if the products are still in review? How do we get the subscriptions approved? I have submitted them with the app multiple times. The app is rejected because I can't complete it without the subscriptions but the subscriptions are never reviewed. Help!

Hi everyone, I’m currently developing an iOS app using React Native and implementing consumable In-App Purchases (IAP). I'm facing an issue where getProducts returns an empty array without any error messages when testing on a TestFlight build. I have already completed the following setup: Agreements, Tax, and Banking: All forms are signed and the status is "Active" in App Store Connect. Product Configuration: The Consumable product is created in App Store Connect with the status "Ready to Submit". App Store Connect Integration: The product is correctly linked under the "In-App Purchases and Subscriptions" section of the App version. Xcode Capability: The "In-App Purchase" capability has been added to the project. Implementation: The Product ID in my React Native code (using react-native-iap) matches the ID in App Store Connect exactly. Despite these steps, the product list remains empty. Are there any hidden requirements or specific configurations for TestFlight that I might have missed? Any guidance would be greatly appreciated. Thanks!

Hi, I am planning to show the StoreKitError as alerts, I have corresponding custom Error so that I can show meaningful error messages. Reason I wanted to display error alert messages that describe the underlying error so that when in production and user faces this error I would be able to reason about the error and try to resolve the error in a app update or Appstore Connect change. If I display a generic error I wouldn't know the cause of the error, but is there is a security risk in display the following kind of messages? Proposed UI error messages: | Error | UI alert message | | ------------------------------------ | ----------------------------------------------- | | StoreKitError.notEntitled | App is not entitled to make this request. | | PurchaseError.invalidOfferSignature | Invalid offer signature. | Questions From a security / user perspective is it risky / wrong to show an error message like the ones pasted above? Or are there some errors I shouldn't explicitly state? Or is there a better / preferred approach?

I have an iOS app (SwiftUI) that includes recurring subscriptions. To allow users to manage their subscriptions I have implemented manageSubscriptionsSheet according to apple documentation. When I published the app last year for iOS17 and iOS18 this was working well. Now I have gotten a user report that this features yields No connection error instead of the abonnements on iOS26. I have tested on my iPad running iOS 26 as well as on the simulator with iOS 26 and 18. In all cases I get the error. I can press Retry in the dialog and am prompted for AppStore credentials After entering them, again the same error. I can not find a single hint on why and how to fix it. Best wishes, Volker

Hi, I'm testing my first auto-renewable subscription using StoreKit 2 and TestFlight. When loading products via: let products = try await Product.products(for: ids) the product is returned successfully, but product.displayPrice shows: $4.99 even though: My App Store account is located in Germany. The app is only intended for the German market. The native Apple purchase sheet displays the correct price in EUR. The subscription pricing is configured correctly in App Store Connect. The subscription is still in "Ready to Submit / Prepare for Submission" state and has not yet been approved. Example: print(product.displayPrice) returns: $4.99 while the StoreKit purchase dialog shows: 5,99 € Has anyone seen this behavior before? Is this expected for new subscriptions in TestFlight/Sandbox before the first App Review approval, or could there be another reason why displayPrice differs from the actual purchase dialog? Thanks!

I am testing a StoreKit 2 non-consumable IAP through TestFlight. Product ID: com.metabolla.plus.lifetime Type: Non-Consumable Environment: TestFlight / Sandbox Transaction.currentEntitlements keeps returning an active entitlement for this product even after: configuring a Sandbox Apple Account clearing Sandbox Purchase History reinstalling the app rebooting the device Important detail: the first TestFlight purchase was completed before configuring the Sandbox Apple Account on the device. If I temporarily change the Product ID in code, the entitlement disappears, so the issue seems tied to the original Product ID/account/receipt. Question: Can a non-consumable TestFlight purchase made before Sandbox Apple Account configuration remain associated with the original TestFlight/Apple ID identity? Is there any supported way to clear this entitlement for testing?

General: Forums topic: StoreKit Forums tag: In-App Purchase App Store Pathway Simple and safe In-App Purchases Auto-renewable subscriptions In-App Purchase documentation Getting started with In-App Purchase using StoreKit views documentation Supporting business model changes by using the app transaction documentation Testing at all stages of development with Xcode and the sandbox documentation App Store Server Notifications documentation App Store Server API documentation Simplifying your implementation by using the App Store Server Library documentation TN3185: Troubleshooting In-App Purchases availability in Xcode technote TN3186: Troubleshooting In-App Purchases availability in the sandbox technote TN3188: Troubleshooting In-App Purchases availability in the App Store technote Understanding StoreKit workflows sample code Implementing a store in your app using the StoreKit API sample code What’s new in StoreKit and In-App Purchase video

My non renewing subscriptions got rejected as I move from subscription to one time payment model. It says "In order to approve your new In-App Purchase business model, we have to verify the purchasability of the items being sold. Please upload a new binary and make sure that your new In-App Purchase products are available for purchase at the time of review." But the thing is I uploaded to new builds since then and both got approved and live but this error is still stuck. Submit for review is greyed out.

Could you help clarify the expected behavior in downgrade scenarios during a Free Trial period? Does Apple trigger billing immediately for the downgraded plan, or does the change take effect only after the Free Trial window completes?

I'm testing IPhone and iPad Apps on Apple Silicon Macs. When I purchase In-app product in the app on Apple Silicon Mac, the payment receipt is not created, so the purchase fails. In console log, it says it doesn't have permission to write to the file. storekitagent [6913DE38_SK1] Error writing receipt (5095 bytes) to file:///Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt: Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “sandboxReceipt” in the folder “StoreKit”" UserInfo={NSFilePath=/Users/XXXX/Library/Containers/90FE2A60-9FDF-4ECF-848F-CE3D396322CA/Data/StoreKit/sandboxReceipt, NSUnderlyingError=0x14202c920 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}} The App is using Original API for In-App Purchase written in Objective-C. When I purchase in-app product, the app calls SKPaymentQueue::addPayment. And then it gets paymentQueue:updatedTransactions callback with SKPaymentTransactionStatePurchased. This means that the payment was successful. But the receipt is not created so I can't continue the after process. I'm testing with sandbox in-app purchase. I have tested several times and confirmed that on macOS Monterey 12.2 the receipt is created successfully, but on macOS Ventura 13.2 the receipt isn't created. I think there is something to do with macOS version. Does anyone have any solutions? Here is a very similar thread on apple developer forum. (And there too has no anwsers)  https://developer.apple.com/forums/thread/719505

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?

I am implementing device authentication for a macOS app. Our iOS app uses App Attest, but App Attest is not available on macOS, so we are evaluating StoreKit's AppTransaction plus AppStore.deviceVerificationID as the macOS equivalent signal. The issue: in a macOS app installed through TestFlight, AppStore.deviceVerificationID is available, but AppTransaction.shared throws StoreKitError code=2. I reproduced this in a focused standalone macOS test app with no backend and no custom dependencies. Environment: Platform: macOS Distribution: TestFlight App Store Connect app ID: 6769568350 Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 Observed output from the TestFlight-installed app: Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 deviceVerificationID available: true deviceVerificationID prefix: CA91ED5D... AppTransaction.shared threw error: StoreKitError; domain=StoreKit.StoreKitError; code=2 The relevant code path is essentially: import StoreKit let deviceVerificationID = try? AppStore.deviceVerificationID let appTransaction = try await AppTransaction.shared In the TestFlight-installed build: AppStore.deviceVerificationID succeeds. AppTransaction.shared throws StoreKitError code=2. Questions: Is AppTransaction.shared expected to work for macOS apps distributed through TestFlight? If yes, what does StoreKitError code=2 indicate in this context, and what setup might be missing? If no, is there an Apple-supported way to obtain an AppTransaction JWS, or equivalent signed App Store/TestFlight app-install assertion, for macOS TestFlight builds? For macOS apps that need a device-bound trust signal comparable to iOS App Attest, is AppStore.deviceVerificationID intended to be used without AppTransaction.shared, or should these APIs be used together? I have a focused Xcode test project that demonstrates the issue and can share it if helpful.

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! 🙏