I've been testing the offer code feature for my non consumable in app purchase using a sandbox account, with sandbox offer codes and in the sandbox environment. However, the codes don't appear to work despite everything being in the sandbox. Any idea what I'm missing?

Hello, I'm suddenly encountering errors with In-App Purchases (IAP) and my sandbox webhooks, which were working correctly just a few days ago. Specifically: Product Information Error: I'm receiving the following error when trying to fetch product information: { "type": "product_info", "result": "error", "error": "An unknown error occurred" } This API call was functioning normally until today. Sandbox Webhook Failure: I have configured a sandbox webhook, but my server is not receiving any notifications from the App Store. Test API 401: When I attempt to call the test API (https://api.storekit-sandbox.itunes.apple.com/inApps/v1/notifications/test), I consistently receive a 401 (Unauthorized) error. Could you please provide some guidance on how to troubleshoot these issues? Thank you.

According to Apple's documentation, SKOverlay is designed to recommend other applications to users. I'm seeking clarification on whether it also supports displaying update prompts for the host application itself. Use case: My app (for example, HelloDeveloper) is live at version 2.0, but some users are still on version 1.0. I want to display a soft update prompt that allows users to remain in the app. Question: Is it possible to use SKOverlay with my app's App Store ID to present an update option without requiring users to leave the app?

I just spent way too many hours trying to figure out why my in-app subscription was stuck in “Missing Metadata” in App Store Connect, even though I had filled out everything. If you're here because you're in the same boat, this is the solution Apple doesn't make obvious. The Problem I created an auto-renewable subscription (Kanabloom Premium) and filled in all required fields. The subscription was still marked "Missing Metadata", preventing me from submitting it. The “In-App Purchases” section wasn’t showing up in my App Store version submission, which meant I couldn't even attach the subscription to my app version. I triple-checked the metadata, pricing, tax settings, review screenshot, and even resaved everything, but nothing worked. What I Tried (Before Finding the Fix) Checked that pricing was set up correctly for all countries. Uploaded the required review screenshot for the subscription. Made sure the subscription group existed and was linked properly. Refreshed, logged out/in, and tried different browsers. Read every Stack Overflow, Reddit, and Apple Developer Forum post I could find. Even tried creating a dummy subscription to see if that would reset the system. The Solution: Localizing the Subscription Group Here’s the stupidly hidden requirement that finally fixed it: ✅ Your subscription group itself (not just the subscription) needs a localized display name. App Store Connect requires each subscription group to have at least one localized display name for it to be valid. If this is missing, all subscriptions inside that group will stay stuck in “Missing Metadata” no matter how complete they are. How to Fix It: Go to App Store Connect > Subscriptions > Subscription Group Click on your subscription group (not the individual subscription). Check if there's a localization added under "Group Reference Name." If missing, add a localization (e.g., English) and save. Refresh the page and boom – the subscription will finally be "Ready to Submit." Conclusion Apple really needs to make this requirement clearer. Now that I’ve finally figured it out, hopefully, this post helps someone else avoid losing hours of their life to the same issue. If you're still stuck, double-check that: You’ve set pricing and enabled "Cleared for Sale." You’ve uploaded a review screenshot for the subscription. You’ve signed all App Store agreements and banking/tax documents. Your app's In-App Purchase capability is enabled in Xcode. Let me know if this helped you! I wish I had found a post like this sooner. 😂 This should make for a useful and searchable post in case other devs run into the same headache. Let me know if you want any tweaks before posting! 🚀

Issue: SKOverlay configured with a Custom Product Page identifier opens the default product page instead of the custom one on iOS 26. This works correctly on iOS 18 and earlier. Details: Custom Product Page is published and valid in App Store Connect customProductPageIdentifier is correctly set on SKOverlayAppConfiguration Same code works fine on iOS 18 and lower Code: - (void)presentSKOverlayInWindowScene:(UIWindowScene *)scene { SKOverlayAppConfiguration *config = [[SKOverlayAppConfiguration alloc] initWithAppIdentifier:@"my_app_id" position:SKOverlayPositionBottom]; config.userDismissible = YES; if (@available(iOS 15.0, *)) { [config setCustomProductPageIdentifier:@"my_apps_custom_product_page_id"]; } SKOverlay *overlay = [[SKOverlay alloc] initWithConfiguration:config]; overlay.delegate = self; [overlay presentInScene:scene]; } Are there any known iOS 26 changes affecting Custom Product Pages with SKOverlay, or is additional configuration now required. Thank you

Hello all, I am new to implementing payments in an app, and thus completely at sea here. I have created a small app that I have set a one-time (non-consumable) payment for a premium version. In the Xcode simulator (on all platforms) and on any physical test devices I have tried, the payment works as expected. I have a sandbox account and various test accounts, both dummy and actual real accounts (friends and family). Everywhere everything works perfectly fine. Yet, when I submit for review I get a rejection with this contents: We found that your in-app purchase products exhibited one or more bugs which create a poor user experience. Specifically, the app still failed to load the in-app purchase. Please review the details and resources below and complete the next steps. Review device details: Device type: iPad Air (5th generation) OS version: iPadOS 18.6 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. Additionally, 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. Resources Learn how to set up and test in-app purchase products in >the sandbox environment. Learn more about validating receipts with the App Store. Steps I have done: I have signed all agreements and all bank account details are in order. Everything in the In-app-purchases section of the AppStoreConnect in an Active state. I have triple checked that the configuration of the in-app purchases is correct (product IDs, amounts, etc.) I have created test accounts and tested in sandbox What I don't understand from the reviewer's response is what receipts validation are they talking about? I have no payment servers (the whole concept of using Apple's in-app-purchases service is to not have to deal with my own payment implementation). The StoreKit documentation specifically reads: For each transaction that represents a current purchase, your app delivers the purchased products. To validate purchases, you can verify transactions on your server, or rely on StoreKit’s verification. So now I am confused. The reviewer's response is so vague, and so completely deprived of details that I have no idea what to do... Does the problem concern the product purchase trigger and the that in production environment it does not trigger? Is it that I haven't implemented a receipt validation? Do I need to? Although the documentation mentions that it can be done by StoreKit, I couldn't find anything concerning how to do it :( Can someone give me a hand please? Cheers, Alex

Hi everyone, After updating to Xcode 16.4, my StoreKit configuration stopped working. Whenever I run the app with a .storekit file set as the active scheme, I immediately get this alert: “The file has been changed. Do you want to save your changes or revert to the file on disk?” No matter if I choose Save Anyway or Revert, StoreKit testing does not work - the purchases are not simulated, and the scheme is basically broken. This issue didn’t exist in Xcode 15.4 - the same StoreKit configuration file works fine there. What I tried so far: Clearing Derived Data - no effect Making sure no scripts/tools modify the .storekit file - still happens Restarting Xcode and macOS - no change Environment: Xcode 16.4 Happens in both Simulator and on device Reproducible 100% Has anyone else seen this in 16.4? Any known workarounds until Apple fixes it? Thanks!

Hi, I just having an issue with Revenue Cat paywall and react native purchases library when app is downloaded from TestFlight. All my subscriptions are in ready for submit state and most likely should be available in sandbox TestFlight but in fact revenue cat sends error about no products are available in App Store Connect (Revenue Cat configured properly, and i event imported froducts from App Store) Also, locally, with StoreKit product sync everything working properly Tried different accounts like sandbox and live - still the same error Can anyone help with this?

Hello, is it allowed to include the action=write-review URL parameter in customer support emails to direct users to the App Store review page? Example: https://apps.apple.com/app/id[APP_ID]?action=write-review I want to make it easy for customers to leave feedback after positive support interactions, but only if it's compliant.

I have added an in-app purchase function into my app, and have enabled in-app purchase profile in developer portal(it's on by default and is marked gray in developer portal, I don't know if that's how it supposed to look like). I have issued the agreements and tried signing the app both manually and automatically, but neither of that worked. App can be built successfully in simulator but does not show the simulation window, but cannot build on real device or archive. Errors: Missing com.apple.developer.in-app-purchase, com.apple.developer.in-app-purchase.non-consumable, and com.apple.developer.in-app-purchase.subscription entitlements. Automatic signing failed Xcode failed to provision this target.

revenuecat is asking for the in app subscriptions to be approved first in order for the pay wall to display and function properly, but apple support keeps flagging them as "developer action needed" and complaining that they can't access in app subscriptions. what do I do?

I have added an in-app purchase function into my app, and have enabled in-app purchase profile in developer portal(it's on by default and is marked gray in developer portal, I don't know if that's how it supposed to look like). I have issued the agreements and tried signing the app both manually and automatically, but neither of that worked. App can be built successfully in simulator but does not show the simulation window, but cannot build on real device or archive. Errors: Missing com.apple.developer.in-app-purchase, com.apple.developer.in-app-purchase.non-consumable, and com.apple.developer.in-app-purchase.subscription entitlements. Automatic signing failed Xcode failed to provision this target.

I’m seeing an issue with subscriptions in TestFlight builds on iOS 26. Running from Xcode works as expected, and the App Store build looks fine. But when I install the same build via TestFlight, transaction.subscriptionStatus is nil. The identical binary behaves correctly on an iOS 18 device. Is this expected behavior on iOS 26 TestFlight, or am I missing something? Thanks!

In SwiftUI I am using the manageSubscriptionsSheet modifier to open the iOS subscription screen. When this is presented it immediately flashes a white view and then animated the subscription screen up from the bottom, it looks pretty bad. The view I am calling manageSubscriptionsSheet on is presented in a sheet, so maybe trying to present the subscriptions view as well is causing the visual glitch. Any way to not have this white flashing view when opening the subscription screen?

Starting around October 12, 2025 at 19:51 UTC, we're seeing intermittent failures when verifying StoreKit transaction JWTs. The issue appears to be related to certificate expiration in the x5c chain in the JWT tokens provided by Apple. What We're Seeing Some JWTs are being signed with different certificates. Some work, some fail certificate validation. Old Certificate (Expired - causing failures): Subject: Prod ECC Mac App Store and iTunes Store Receipt Signing Issuer: Apple Worldwide Developer Relations Certification Authority (G6) Serial: 166451396673336810269824643773700992094 Valid From: 2023-09-12 19:51:53 UTC Valid To: 2025-10-11 19:51:52 UTC ❌ EXPIRED New Certificate (Valid - working): Subject: Prod ECC Mac App Store and iTunes Store Receipt Signing Issuer: Apple Worldwide Developer Relations Certification Authority (G6) Serial: 95385247725814954943813376527885434295 Valid From: 2025-09-19 19:44:51 UTC Valid To: 2027-10-13 17:47:23 UTC ✓ VALID Current Status Most JWTs use the new valid certificate. Some JWTs still use the expired certificate. This appears inconsistent/random. I don't know if it's an issue with some of Apple's servers, or an issue with StoreKit on-device cache, but seems to me like a bug on Apple's side either way. Are we missing something? Is this a known issue? Any guidance or timeline from Apple would be greatly appreciated, as this is blocking legitimate paying users.

After creating a new weekly subscription option, I get inconsistent results for subscriptionPeriod. In local testing with a synced or a un-synced StoreKit file I am getting unit == .week (as expected) whereas in TestFlight I am getting unit == .day. This makes unit.localizedDescriptionsomewhat unusable in the paywall. Am I missing something? Or is this bug or a limitation of StoreKit and/or TestFlight and/or newly created subscription options? Affected code (in a custom SubscriptionStoreControlStyle): private func priceDisplay(for pickerOption: Configuration.PickerOption) -> String { var result = "" if pickerOption.introductoryOffer != nil { result += NSLocalizedString("then", comment: "") + " " } result += pickerOption.displayPrice if let unit = pickerOption.subscriptionPeriod?.unit { result += " / " + unit.localizedDescription } return result } private func percentageSaved(for pickerOption: Configuration.PickerOption, allOptions: [Product]) -> Int? { guard let subscriptionPeriod = pickerOption.subscriptionPeriod, subscriptionPeriod != .weekly else { return nil } let weeklyOption = allOptions.first { otherOption in otherOption.subscription?.subscriptionPeriod == .weekly } guard let weeklyOption, weeklyOption.price > 0 else { return nil } let percentageSaved = 100 - (pickerOption.price / (weeklyOption.price * 52)) * 100 return Int((percentageSaved as NSNumber).doubleValue) }

Hi everyone, I’m encountering an issue with my in-app subscriptions setup. When I test using the StoreKit configuration file in Xcode, everything works correctly — the subscriptions are fetched and I can simulate purchases without any issues. However, when I switch to the Sandbox or Production environment, my app fails to fetch the available products from Apple’s servers. The call to fetchProducts (from the expo-iap library) returns an empty array. Here’s some context about my setup: Framework: React Native (Expo Bare Workflow) Library: expo-iap Products: Auto-renewable subscriptions StoreKit Configuration: Synced with App Store Connect Status: Subscription Plans are approved in App Store Connect I’ve verified the following: The product identifiers in code match exactly with those in App Store Connect. The app is signed with the correct bundle ID. I’m testing with a Sandbox account (logged in via Settings -> Developer -> Sandbox Tester Account). Despite this, the response from Apple’s servers still contains an empty array. Has anyone experienced something similar with expo-iap or in general when moving from StoreKit configuration to Sandbox/Production? Any suggestions on what else I could check or common pitfalls I might be missing? Thanks in advance!

Problem Description: 1、I have two sandbox accounts from different countries. Account A is from Mainland China (CHN), and Account B is from the United States (USA). When I switch the sandbox account from Account A (CHN) to Account B (USA) in the system settings and restart the app, the value of SKPaymentQueue.defaultQueue.storefront.countryCode always returns "CHN" instead of the expected "USA". 2、This issue only occurs on iOS 18.2 and above. 3、On the same device running iOS 17.5.1, the behavior is correct. However, after upgrading the system to iOS 18.3.2, the error occurs. 4、In the sandbox environment, although SKStorefront.countryCode returns the wrong value, the currency type for Apple's in-app purchase is correct when initiating the payment. 5、The issue only exists in the sandbox environment and does not occur in the App Store-downloaded package. Demo Code: - (IBAction)clickButton:(id)sender { NSString *appStoreCountryCode3 = SKPaymentQueue.defaultQueue.storefront.countryCode; NSLog(@"%@",appStoreCountryCode3); } Demo Testing Steps and Results: 1、Sandbox Account A (China) will print "CHN". 2、Go to Settings - Developer - (at the bottom) SANDBOX APPLE ACCOUNT, and switch to another sandbox account B (USA). 3、Restart the Demo App. 4、Print results: iOS 17.5.1: "USA" ✅ → Upgrade the system of the same device to iOS 18.3.2 → "CHN" ❌ iOS 18.2.1: "CHN" ❌ iOS 18.3.1: "CHN" ❌ iOS 18.3.2: "CHN" ❌ Possible Clues: Starting with iOS 18.2, Apple changed the entry point for setting up sandbox accounts, which introduced this bug. It seems that when users switch sandbox accounts on iOS 18.2, Apple engineers forgot to notify the SKStorefront class to update the countryCode value. Before iOS 18.2: Settings - App Store - Sandbox Account iOS 18.2 and later: Settings - Developer - (at the bottom) Sandbox Account Although it doesn't affect the App Store package, it does impact our development and testing process. We hope this issue can be fixed in future versions. Thank you!

Both the legacy StoreKit API and the new StoreKit 2 API return the incorrect storefront countryCode. My actual Apple ID region is Germany, and my Sandbox test user is set to France, yet the SDK consistently returns USA. Expected Results: The returned storefront countryCode should reflect the correct region - sandbox user region if signed in and real user region if not signed in with sandbox). Actual Results: Returned country code is USA with both SKPaymentQueue.default().storefront?.countryCode and await Storefront.current?.countryCode. Signing out/in, device reboot and even reset do not help, I'm stuck with USA storefront.

I am currently developing a feature to support global privacy compliance, which relies on accurately obtaining the user’s App Store country/region. Based on this country/region information, out App dynamically display privacy policies that comply with local regulations. To retrieve this information, I use the relevant StoreKit APIs. API usage examples: Objective-C: NSString *countryCode = [SKPaymentQueue defaultQueue].storefront.countryCode; Swift let storefront = await Storefront.current let code = storefront?.countryCode However, during sandbox account testing on iOS 18.0 and above, I noticed that the returned country code does not match the actual country/region configured in the sandbox Apple ID. This issue does not occur on systems below iOS 18.0, where the country code returned by the API matches the account setting. Since this discrepancy can directly affect the accuracy of our compliance logic, I would appreciate your clarification on the following points: Is this a known change in behavior for iOS 18? In production environments, does the country code returned by the above APIs accurately reflect the App Store region of the user’s signed-in Apple ID? Is there a recommended approach to reliably obtain the user’s App Store account country/region?