As a developer I have a question I would like cleared up. We offer two tiers of annual subscriptions in our apps. These subscriptions are under the same subscription group in App Store connect. My question is, if a user purchases tier 1 of the annual subscription for $10.00, and uses it for 6 months; then chooses to upgrade to tier 2 which costs $20.00 per year. Would the user be pro-rated the difference in price i.e. charge only another $10.00 at the time of the upgrade., or are they charged $20.00 and then refunded the difference in their remaining lower tier subscription? I keep finding inconsistent answers across the Apple community forums on this.

When TestFlight was in public beta, the user had a mainland China account and downloaded the app from the mainland China App Store. However, when subscribing, the app displayed the message: "Your account is not available in the US App Store. You must switch to the Chinese App Store before making a purchase." In reality, the user's account region was already mainland China, and the app was downloaded from the mainland China Mac App Store. I've set all countries to be available in Connect. Has anyone encountered a similar issue? testflight公测时，用户是中国大陆的账号，在大陆appstore下载了应用。 但是订阅的时候，app提示：你的账户在美国商店中无法使用，在进行购买之前，你必须切换至中国商店。实际上，用户的账号地区已经是中国大陆，也是在中国大陆的mac appstore下载的应用。 我的在connect 中设置了所有国家可用，有人遇到类似的问题了吗？

Hello — quick question about App Store Server Notifications migration. We have a live app using Production V1 notifications for recurring in-app subscriptions. We plan to switch the Production webhook to V2. After the switch: Will notifications for existing subscriptions be delivered in V1 format, V2 format, or will it depend (e.g., queued V1 retries vs new V2 deliveries)? If V1 retries are queued, how long should we expect overlap/retries to continue? Any recommended cutover best practices (support both formats, revert process, etc.)? Happy to share additional details. Thanks.

Hi! I created a subscription class and a button that starts the purchase flow. In the Xcode environment and Simulator everything works correctly — the purchase sheet appears and the subscription flow works as expected. But when I test the app in TestFlight, the subscription button doesn’t appear at all. I cannot trigger a purchase, and I can’t find a clear tutorial that explains how to make subscriptions work specifically in TestFlight. Here is what I have already done: I created the subscription in App Store Connect I set up a Sandbox account and logged in on the device. StoreKit sync works and the product ID matches the one in App Store Connect. The same code works perfectly in Xcode Debug and Simulator, but the button is missing in TestFlight. I’m totally stuck. Can someone explain how to correctly set up and test subscriptions in TestFlight and why the subscription button would disappear even though everything works in Xcode? Any help or guidance would be greatly appreciated! THIS IS SUB CLASS @Published private(set) var products: [Product] = [] @Published private(set) var activeSubscriptions: Set<StoreKit.Transaction> = [] private var updates: Task<Void, Never>? var hasActiveSubscription: Bool { activeSubscriptions.contains { transaction in guard let expirationDate = transaction.expirationDate else { return false } return expirationDate > Date() && transaction.revocationDate == nil } } init() { updates = Task { for await update in StoreKit.Transaction.updates { if case .verified(let transaction) = update { activeSubscriptions.insert(transaction) await transaction.finish() } } } } deinit { updates?.cancel() } // MARK: PRODUCT LOADING func fetchProducts() async { do { let ids = ["test_name"] products = try await Product.products(for: ids) } catch { print("Failed to load products: \(error)") products = [] } } // MARK: PURCHASE func purchase(_ product: Product) async throws { let result = try await product.purchase() switch result { case let .success(.verified(transaction)): await transaction.finish() case .success(.unverified): break case .pending: break case .userCancelled: break @unknown default: break } } // MARK: ACTIVE SUBSCRIPTIONS func fetchActiveSubsciptions() async { var active: Set<StoreKit.Transaction> = [] for await entitlement in StoreKit.Transaction.currentEntitlements { if case .verified(let transaction) = entitlement { active.insert(transaction) } } self.activeSubscriptions = active } > ``` THIS IS BUTTON ```VStack(spacing: 8) { ForEach(sub.products) { product in PrimaryButtonView(text: mainButtonTitle) { Task { do { try await sub.purchase(product) } catch { print("Purchase error: \(error)") } } } } }```

I'm an app developer, and I recently launched a monthly subscription product in my app on the App Store. However, I'm having trouble understanding the App Store's renewal date calculation policy. According to the official documentation, if a subscription is purchased on December 1st, the next renewal date should be January 1st. But the expiresDate is set to December 31st instead. At first, I thought this might be a timezone issue, but even after it became December 1st in UTC, the renewal date was still set to December 31st. Is the timezone used to calculate renewal dates not UTC+0? Or is there documentation on the renewal cycle policy that I might have missed? Any clarification would be greatly appreciated. Thanks in advance!

Hi Apple Developer Community and Support Team, I'm reaching out for advice and potential escalation on a stalled organization enrollment that's blocking our app launch. Here's a quick timeline: Initial enrollment hit issues with D-U-N-S verification (now resolved) and email code delivery, leading to multiple failed attempts and temporary blocks. After unblocking via support, we resubmitted and were directed to higher department review. Submitted all required docs (company formation, passport/ID, etc.) on Wednesday, November 26, 2025. No updates since—it's now Day 6 with zero communication on ETA. This is critically urgent for our business: We have ~4,000 users pre-registered and waiting to download our personal development app (focused on habit-building and goal tracking). Projections show another 10,000 sign-ups in the next two weeks alone, pushing us to 15,000+ if resolved soon. These folks are already investing—our physical planners (promoting the app) are selling via Amazon and our website, http://www.freedommastery.com selling Life planners) and they're expecting seamless iOS access on launch day. Every day of delay risks churn, lost revenue, and momentum in a competitive space. I've followed up via phone/email multiple times, but frontline support can't provide timelines or status. Enrollment ID: [Redact or insert your anonymized ID here for tracking]. Has anyone navigated a similar higher-review holdup? Tips for bumping priority (e.g., additional proof of urgency like waitlist data)? Any rough ETAs from recent org approvals? Grateful for any insights—Apple's ecosystem is key to our growth, and we'd love to get these users onboard ASAP. Thanks in advance!

​ My app has been rejected multiple times during the last few weeks because Apple reviewer is unable to complete the purchase on revenue cat paywall. They gave this error message: Guideline 2.1 - Performance - App Completeness We were still unable to purchase the subscription successfully. Review device details: Device type: iPad Air 11-inch (M2) OS version: iPadOS 26.1 Next Steps When validating receipts on your server, your server needs to be able to handle a production-signed app getting its receipts from Apple’s test environment. The recommended approach is for your production server to always validate receipts against the production App Store first. If validation fails with the error code "Sandbox receipt used in production," you should validate against the test environment instead. Resources Note that in-app purchases do not need to have been previously approved to confirm they function correctly in review. Note that the Account Holder must accept the Paid Apps Agreement in the Business section of App Store Connect before paid in-app purchases will function. Learn how to set up and test in-app purchase products in the sandbox environment. Learn more about validating receipts with the App Store.   The offerings are fetched correctly but they are unable to complete the purchase. I tested on my physical iPhone with real account (not sandbox) and get the same exact error. I have provided screenshot of the paywall screen and my App Store Connect pages below. I think issue might be because my subscriptions on App Store are not approved but I’m not sure. I heard you are supposed to submit them same time when you submit your build. I submitted both but Apple also rejected my subscriptions saying the images were duplicate. Now they say “developer action needed” First of all, it says the images are optional so why does it matter what they are? Second of all, what image am I supposed to provide there then?  Guideline 2.3.2 - Performance - Accurate Metadata We noticed that your promotional image to be displayed on the App Store does not sufficiently represent the associated promoted in-app purchase and/or win back offer. Specifically, we found the following issue with your promotional image: – You submitted duplicate or identical promotional images for different promoted in-app purchase products and/or win back offers. Next Steps To resolve this issue, please revise your promotional image to ensure it is unique and accurately represents the associated promoted in-app purchase and/or win back offer. If you have no future plans on promoting this in-app purchase product, you can delete the associated promotional image in App Store Connect. Resources Learn how to view and edit in-app purchase information in App Store Connect. Discover more best practices for promoting your in-app purchases on the App Store.   Support Reply to this message in your preferred language if you need assistance. If you need additional support, use the Contact Us module. Consult with fellow developers and Apple engineers on the Apple Developer Forums. Request an App Review Appointment at Meet with Apple to discuss your app's review. Appointments subject to availability during your local business hours on Tuesdays and Thursdays. Provide feedback on this message and your review experience by completing a short survey.     ​

Dear all, This is my first post in this forum - and, in fact, my first app, too! I'm glad to be here, and thanks in advance for your help. I'm looking to offer an app for a one-time payment. I'd also like people to be able to try the app for a week. It seems that the "Pricing and Availability" section in App Store Connect is not the right place to configure this kind of offer. It does allow me to set a one-time price, but I cannot find a trial-period there (or am I missing something?) Two different strategies seem possible here: Using in-app-purchases: make the actual app free, but ask users after a week to buy a non-consumable IAP. The problem with that: I need to verify that the app has been installed for seven days ... even if it has been uninstalled at some point. Using subscriptions: There is a "free trial" option for subscriptions. But after that free trial, subscriptions are being payed periodically. I'd rather have the user only pay once for lifetime-access. Some apps seem to use strategy 1 - I believe the "Lap swim" app does. But still it seems like a bit of a hack - is there a more elegant way to achieve this?

Hello, I’m developing an app that provides physical services such as equipment storage, maintenance, pickup, and delivery. The app does not provide any digital content, digital features, or any form of digital subscription. For payments, we are using an external payment gateway (similar to Stripe Billing or Braintree): iOS: Users are redirected to Safari to complete the payment. We also plan to support annual automatic renewal billing, using the payment gateway’s “billing key” or “recurring billing” feature. This is essentially a card auto-charge for a physical service, and it is not an in-app subscription. I want to ensure that our implementation is fully compliant with Apple’s App Store Review Guidelines, especially 3.1.5(a) regarding physical goods and services. I would appreciate guidance on the following: For apps providing physical services, is it acceptable to process payments through an external browser (Safari) instead of using In-App Purchase? Is recurring billing / automatic renewal with an external payment provider allowed, as long as the service being billed is physical and not digital? For apps offering only physical services, should we completely avoid using the Monetization → Subscriptions section in App Store Connect, since those subscription products apply only to digital content? Our goal is to ensure that the app follows Apple’s policies correctly and does not mistakenly fall under the category of digital subscriptions. Thank you very much for your help.

I would like to inquire about the originalTransactionId of StoreKit2. Users who purchase auto-renewal subscription products To re-purchase the same subscription item after cancellation and prior to refund If you receive a refund after cancellation and re-purchase the same subscription item If you do not renew immediately after expiration and re-purchase the same subscription after a long period of time I would like to ask if 1, 2, and 3 all use the same value as the original Transaction Id at the initial subscription. In the case of 3, if you re-purchase more than a few days after the last subscription purchase, please let me know if there are any detailed conditions such as the original Transaction Id not maintained.

Hi all, I’m currently testing an auto-renewable subscription whose availability is restricted to Japan only (all other territories disabled in App Store Connect). However, when testing in the Sandbox environment, the behavior does not match the availability settings: Sandbox Apple ID storefront: Taiwan Subscription availability: Japan only StoreKit 2 (Product.products(for:)) still returns the product Sandbox purchase succeeds even though it should be unavailable in this region. Questions Is this expected behavior in the Sandbox environment? Does Sandbox not enforce subscription territory availability? Is this a known limitation where Sandbox validates the purchase flow only, without applying real storefront availability rules? Will territory restrictions be enforced correctly in production once the app and subscriptions are “Ready for Sale”? Is there any recommended way to test storefront-based availability before release? Thanks in advance!

Hello, Apple Developer Community! I am attempting to test a user upgrade scenario from an existing monthly subscription to a yearly subscription, applying a Promotional Offer within the sandbox environment. When trying to process the transaction, I consistently receive the following errors from StoreKit: <SKPaymentQueue: 0x...>: Payment completed with error: Error Domain=ASDServerErrorDomain Code=3903 "Unable to Purchase" UserInfo={NSLocalizedFailureReason=Unable to Purchase, client-environment-type=Sandbox, AMSServerErrorCode=3903, storefront-country-code=USA} [...]: Finishing transaction <SKPaymentTransaction: 0x...> with no identifier Additionally, the standard dialog shown to the user displays: Unable to Purchase Contact the developer for more information. [Environment: Sandbox] My Implementation Details: Scenario: The user has an active monthly subscription and attempts to upgrade to a yearly subscription with a Promotional Offer (discount). Signature Generation: I use a custom backend written in Go to generate the signature, nonce, and timestamp. The code follows Apple’s documentation requirements, including proper encoding and formatting. Client (iOS): On the Swift side, I correctly initialize the SKPaymentDiscount and add it to the SKMutablePayment before adding the payment to the queue. The applicationUsername property is used and matches on both server and client sides. What I Have Already Verified and Ruled Out: New Test Accounts: I have created multiple fresh sandbox tester accounts in different regions (USA, Canada, Germany) and used them. Time Synchronization: The time on my server and the test device is synchronized. Parameters: Bundle ID, Product ID, and Offer ID match exactly with the configurations in App Store Connect. App Store Connect Agreements: The Paid Applications Agreement is active. Testing Environment: Testing is conducted on a physical device (iPhone), not a simulator. It seems the issue may not be related to my code but rather a potential glitch within the Apple sandbox environment itself when processing complex upgrade requests with a promotional offer. Has anyone encountered a similar issue when testing Promotional Offers? I would appreciate any help or guidance.

I’m trying to enroll in the Apple Developer Program, but when I attempt to make the payment, the only option displayed is for UAE/AED. My actual region is India, so I’m unable to complete the payment or finish the enrollment. I’ve already tried changing the region in my Apple ID and updated both my payment and delivery addresses to India, but it still only shows UAE and AED as the payment option. I urgently need the developer account because my client is waiting. Please help me change the region to India, or update it on your end if possible. I have already submitted a support request, but I haven’t received a response yet. My support request ID is: 102757573285. Thank you for your assistance.

Hello, I’m experiencing an issue with StoreKit 2 when passing a new appAccountToken for each purchase request. Case-ID: 15948169 (for DTS reference) Description of the Problem When initiating a purchase, I generate a new UUID to use as the appAccountToken: let serverTransactionId = UUID() let options: Set<Product.PurchaseOption> = [ .appAccountToken(serverTransactionId) ] let result = try await product.purchase(options: options) Expected Behavior: Each new purchase should return the updated appAccountToken that I pass into the purchase options. Actual Behavior: The payload response after success always contains the same appAccountToken from the very first transaction. It ignores subsequent UUIDs I pass and keeps reusing the original one. This causes issues because the same identifier is being reused across multiple transactions, making it difficult to map purchases to the correct user session. Steps to Reproduce Generate a fresh UUID using UUID(). Pass it as .appAccountToken when calling purchase(). Complete the transaction in the sandbox environment. Inspect the payload response → The appAccountToken value is always the same as the first one used, not the newly provided one. Additional Info I do have a focused test project that reproduces this issue. The issue appears specific to appAccountToken persistence across multiple transactions. Has anyone else experienced this behavior with StoreKit 2? Is this expected (Apple caching the first token) or could this be a bug?

I added my first subscription to my app using StoreKit's SubscriptionStoreView. Everything worked as expected in the debug environment and also in TestFlight. So I submitted my app and subscriptions to App Store Connect, got everything Approved and released. After updating my app through App Store and checking the Subscription View, it just says "Subscription Unavailable. The subscription is unavailable in the current storefront." I waited around 3 days and still getting the same message. Now the very strange behavior starts. I went to App Store Connect, I made and edit to the subscription description, saved, removed the edit, saved, and submitted to review. 15 minutes later the subscriptions appear in my app and everything works as expected. After getting the edit approved, the Subscription View in my app again only showed the message "Subscription Unavailable. The subscription is unavailable in the current storefront." No user is able to see the subscriptions anymore, even though it worked as expected before the edit was approved. So I did the same as before. Again, make an edit to the subscription description, save, remove the edit, save, submit to review. 15 minutes later the subscriptions are again available in my app and it works as expected. This is definitely not the expected behavior and submitting the subscription edits every day is wasting the App Review Team's time as well as mine. I contacted Apple Developer Support but I didn't get any reply back (at least yet). I am not the only one experiencing this. I found a friend online who has the exact same issue, and is able to temporarily solve it by making an edit to the subscription description as well. So far it has been a huge headache, and we are losing customers this way. Please if anyone has experience with this problem, or has any suggestions, they will be greatly appreciated. Thank you so much, Tomas

I need help understanding how the In-App purchase subscription works within the same subscription group and how the Order plays a role at the time of auto-renewal. In my case, I have 5 in-app products in the same group as given below with their Order, Order Product ---------------------- 1 Gold Annual 2 Gold Monthly 3 Silver Annual Old, 3 Silver Annual New 4 Silver Monthly One user purchased Silver annual New, at the time of expiry, after a year, it auto-renewed to Silver annual Old. My understanding is that if a user has purchased Silver annual New, at the time of renewal, it should renew with the same product, not with different product id. Is this behaviour expected? Is there any official document which can explain this behaviour? Note: There was no Order given before, recently we have changed the Order to manage Upgrade and Downgrade for In-App subscriptions.

My app offers auto renewable subscriptions, I have couple of questions regarding how to model the subscriptions at server side, Is originalTransactionId will ever change for a subscription? Will it stay same in case of subscription upgrade/downgrade/crossgrade? If it changes on product change then how do i keep track that the subscription was a continuous subscription and not a new one? Is the webhook payload contains any identifier of which apple account purchase the subscription? I am having issues maintaining sync between the app account's current subscription and the local apple account's subscription, is there any doc regarding this? Will be really helpful

What we're trying to implement is not a new subscription promotion It has implemented a function that allows certain members to experience the membership of the application by providing promotional codes. With the offer code provided by Apple, we are currently implemented Log in => Membership provided by the member entering the promotion code => I'm inquiring because I think the next logic will be difficult. There is no way we can identify the member when entering from the app store with Offer code I would like to inquire about developing it so that it does not violate Apple's review regulations as much as possible.

I am finding that the verifyReceipt endpoint used to verify a receipt is failing on occassion starting around October 27, 2015. I realize this API is deprecated. I am using cURL to call verifyReceipt. The specific errors are 52 - Empty reply from server and 56 - Connection closed abruptly. This indicates an issue with Apple's server as I understand it. Is anyone else experiencing this as well?

I already created subscription in appstore connect with proper metadata still when I am using product id to purchase the subscription using flutter package in_app_purchase: ^3.2.3 it say's no subscription found with product id x. I observed everything minutely all seems fine than why ?? I try to test with storekit that works btw. I also have sandbox account and same signed in my iPhone 12 mini but much please look into this.. Flutter code : Future<void> _loadSubscriptions() async { Set<String> kSubscriptionIds = {'monthly_plan_test_iop_81'}; ProductDetailsResponse response = await _inAppPurchase.queryProductDetails(kSubscriptionIds); if (response.notFoundIDs.isNotEmpty) { kLog("Subscription IDs not found: ${response.notFoundIDs}"); } kLog("God it works seriously"); kLog(response.notFoundIDs); kLog(response.productDetails); kLog(response.error); subscriptions.value = response.productDetails; }