I had a two CS from customers that they couldn't buy a cookies(IAP). they got an alert "Purchases in this app are already purchased items." I was wondering if anyone has any similar experiences.

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

Hey everyone, We're looking for the best way to handle App Store Server Notifications in our development setup and would appreciate some guidance. Our Setup: We use a single App Store Connect account for development, which supports multiple environments (e.g., staging1, staging2). Our production app lives in a separate account, so that's not an issue. The Challenge: We have only one configurable sandbox notification URL. This makes it difficult to route notifications to the correct development server (staging1 vs. staging2 vs developments) when a sandbox event occurs. We're considering using a proxy server to catch all notifications and then forward them to the appropriate environment. However, we're not sure how to determine the correct destination. Our Questions: What's the recommended approach for managing a single sandbox notification URL across multiple development environments? If a proxy is the best method, which parameter in the responseBodyV2 payload should we use to route the notification? How can we differentiate between our various dev environments? Is it possible to add custom properties to the App Store Server Notification V2 body to facilitate routing? Any advice or best practices you've implemented would be greatly appreciated.

Hello, We have been approved for the Advanced commerce API and we are trying to implement dynamically created subscriptions via the SubscriptionCreateRequest. We followed the Sending Advanced Commerce API requests from your app (https://developer.apple.com/documentation/storekit/sending-advanced-commerce-api-requests-from-your-app) documentation but we are not able to make it work correctly. We created a generic subscription in the Appstore connect, product ID: com.example.subscription Then in the app we load the subscription: try await Product.products(for: ["com.example.subscription"]) We do the JWS serialization on our backend and then we wrap the jwt and convert it to Data in the app as this: let request = """ { "signatureInfo": { "token": "\(result.signedPayload)" } } """ let advancedCommerceRequestData = Data(request.utf8) Lastly, we apply the purchase options on the generic product as this: try await product.purchase( options: [ Product.PurchaseOption.custom( key: "advancedCommerceData", value: advancedCommerceRequestData ) ] ) It doesn't show any error, but on the payment sheet it shows the data from the generic subscription and not the data that was in the SubscriptionCreateRequest. Here is an example of the generated jwt: eyJraWQiOiI4V0tNQjhLWTI0IiwidHlwIjoiSldUIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiI0MDZkYmEyOS04ZjIyLTQ3ZDUtYWI1Mi1kY2M2NTQ5OTE1Y2MiLCJiaWQiOiJjby5oZXJvaGVyby5IZXJvaGVybyIsImlhdCI6MTc0NjQzNTcxNCwiYXVkIjoiYWR2YW5jZWQtY29tbWVyY2UtYXBpIiwibm9uY2UiOiJhMzY2MGIwMS1kMDcyLTRlZDYtYmYyMS01MWU1Y2U5MDRmYTUiLCJyZXF1ZXN0IjoiZXlKdmNHVnlZWFJwYjI0aU9pSkRVa1ZCVkVWZlUxVkNVME5TU1ZCVVNVOU9JaXdpY21WeGRXVnpkRWx1Wm04aU9uc2ljbVZ4ZFdWemRGSmxabVZ5Wlc1alpVbGtJam9pTVdSaVlqZG1ZbVl0WWpFNE55MDBZMlJoTFRrNE16WXRNalUzTTJZeU1UaGpOekZpSW4wc0luTjBiM0psWm5KdmJuUWlPaUpEV2tVaUxDSjJaWEp6YVc5dUlqb2lNU0lzSW1OMWNuSmxibU41SWpvaVExcExJaXdpZEdGNFEyOWtaU0k2SWxNd01qRXRNRGd0TVNJc0ltUmxjMk55YVhCMGIzSnpJanA3SW1ScGMzQnNZWGxPWVcxbElqb2lVM1ZpYzJOeWFYQjBhVzl1SUZCbGRISWc0b0tzSURVaUxDSmtaWE5qY21sd2RHbHZiaUk2SWxOMVluTmpjbWx3ZEdsdmJpQlFaWFJ5SU9LQ3JDQTFJbjBzSW5CbGNtbHZaQ0k2SWxBeFRTSXNJbWwwWlcxeklqcGJleUprYVhOd2JHRjVUbUZ0WlNJNklsTjFZbk5qY21sd2RHbHZiaUJRWlhSeUlPS0NyQ0ExSWl3aVpHVnpZM0pwY0hScGIyNGlPaUpUZFdKelkzSnBjSFJwYjI0Z1VHVjBjaURpZ3F3Z05TSXNJbkJ5YVdObElqb3hOVEF3TUN3aWMydDFJam9pY1dkeGIzUnNlSEY1WVdGaFlsOTRiV3RvWlhWdGFHWjJhbXhtWDBWVlVqQTFJbjFkZlE9PSJ9.kJ0f_q2A11Mn9OBmvX6SRmtW5P--volFTVcq_Gohs3N51ECfZqS3WHOxOZc7aojq_qiUHGFp_evmHP51f3LzSw

StoreKit ask to buy should have more data in pending state. When user try to purchase ask to buy, we should get at least transactionID, product itself, and time that user start the request. So we can keep track of the whole transaction flow jwsRepresentation should always available for every state, actually even failing state. And should attach state inside of it. Instead of only available after verified purchase. So we can use transactionID and everything relate to transaction for both waiting for purchase and clearing up the cancel or invalid purchase Currently we only have jwsRepresentation after complete purchase, which is very limited its usage

Hello, We are having an issue with the RequestReview API and were hoping to get some help. We know that there is no guarantee that the in-app review modal will show and we know that there are 3 circumstances in which it will definitely not appear: if the user has turned off in-app review/ratings in their settings if the user has submitted a review for that app on that device within the last 365 days if the user has been asked for a review >3 times in the last 365 days When testing our implementation, every single one of our testers did not receive the rating modal despite the fact that we had all our testers turn on the app rating setting and that we have never asked for reviews from our app before. So that seems suspicious. While it is possible that something is up with our code (and I have provided some snippets below) we are also concerned that apple maybe is suppressing it for another reason. We really want to go live with our app review code but unfortunately we are not able to get confidence that it will ever appear for the user. Can you please help us understand why this isn't working. The code: We are using the SwiftUI approach to requesting review. Here are some relevant code snippets Important to note, we have a modal that appears when the user is in our list of active, targeted users. If they tap yes on this modal, it should show the in app rate the app system modal. If they tap no, we present them with an airship survey so that they can give feedback. Here is the code for the Yes button action: @Environment(\.requestReview) private var requestReview private var yesButton: some View { Button( action: { dismiss() requestReview() }, label: { Text(Lingua.General.appRateFirstButton) .regularParagraph() .frame(width: 180, height: 35) } ) .customButtonStyle( foregroundColor: .black, backgroundColor: Color(.powderBlue), radius: 36 ) } and this is the logic we use to determine whether we want to show them the modal in the first place. Obviously, a lot of this code leads to deeper areas in our logic and code but to give an idea... private func showAppRateModalIfNeeded() { if preferencesManager.appRateReviewShown == nil, accountManager.userAccount?.permissions.rateTheApp == true { let appReviewModalVC = UIHostingController(rootView: AppReviewModal()) appReviewModalVC.view.backgroundColor = .init(white: 0, alpha: 0.6) appReviewModalVC.modalPresentationStyle = .overFullScreen appReviewModalVC.modalTransitionStyle = .crossDissolve parentVC?.navigationController?.present(appReviewModalVC, animated: true) preferencesManager.appRateReviewShown = true } } When testing in debug, we do find that the modal appears and works as expected. However, on release builds nobody is able to trigger it. Why? Are we doing something wrong here or is Apple just suppressing it. We are thinking about implementing the button taking the user directly into the app store review but we'd prefer to do the lower-friction dialog in-app if we can get it work so the user doesn't get sent out of the app.

Hello, I recently saw this error from StoreKit in the Console - 'Invalid value for purchase intake' - while debugging a SKPayment subscription issue (where a valid receipt should be verified and restored, but isn't for one user). I haven't been able to find any documentation about this message and wondered if it was related at all. There were two other logs from StoreKit right before saying: 'Found 3 products in receipt with ID' 'Processing ad attribution purchase intake' Does anyone know what 'invalid value for purchase intake' is referencing? We don't have the AdAttributionKit implemented. It sounds like it might be related to that instead? Thank you

I am a new dev in this space. I need to know how you guys setup a trial period correctly. I am using React Native and RevenueCat SDK. It seems a lot more complicated than it should be. Any assistance is greatly appreciated.

We are facing a serious issues with in app purchases in our app. We offer 3 IAP: auto-renewable subscription 1W, auto-renewable subscription 1Y, non-consumable one-time purchase (LifeTime access) In our case 90-95% of transactions fail and we mostly get SKError code=2 . Sometime purchase fails several times for the same user so it’s very hard to believe that user intentionally cancels transaction for the same product 4 or even 5 times in a row. It happens regardless iOS version, device model, our app version. We've checked multiple threads with the same issue but coudn't find any solution. We do not offer any promotions, product identifiers are valid... Some users are able to make a purchases without any issues.

Problem: I'm implementing StoreKit 2 in my SwiftUI app. Products load successfully when I rebuild in Xcode, but on a fresh install, Product.products(for:) returns an empty array. The paywall shows "Unable to load pricing." Setup: Using StoreKit Configuration File ( .storekit ) for testing Product IDs match exactly between config and code: com..premium.lifetime (non-consumable) com..premium.monthly (auto-renewable subscription) com.****.premium.yearly (auto-renewable subscription) StoreKitManager is a @MainActor singleton with @Published properties What I've Tried: Initial delay before loading - Added 1-second delay in init before calling loadProducts() Product ID verification - Confirmed IDs match exactly between StoreKitConfig.storekit and code Retry logic with exponential backoff - Implemented 3 retry attempts with 0.5s/1s/1.5s delays Multiple calls to updatePurchasedProducts() - Called twice after initial load Verified StoreKit configuration - File is properly added to project, has valid product definitions Code Structure: swift @MainActor final class StoreKitManager: ObservableObject { static let shared = StoreKitManager() @Published private(set) var products: [Product] = [] private init() { updateListenerTask = listenForTransactions() Task { try? await Task.sleep(nanoseconds: 1_000_000_000) await loadProducts() // Returns empty on fresh install await updatePurchasedProducts() } } } Observations: ✅ Works perfectly after Xcode rebuild ❌ Fails on fresh app install (simulator & device) ❌ Product.products(for:) returns empty array (no error thrown) ✅ StoreKit configuration file is valid and properly configured Question: Why does StoreKit need a rebuild to recognize products? Is there a proper initialization sequence I'm missing for fresh installs? Environment: Xcode [Version 26.0 beta 7] iOS [IOS +17.0] Testing with StoreKit Configuration File

Hello 👋! I'm trying to switch the business model in my app from premium to freemium, gracefully so that existing users aren't bothered. I'd like to provide newly-paywalled content for original paid users. For this to work, I need to use originalAppVersion in AppTransaction, and support iOS 16 at minimum. I've asked about originalAppVersion earlier here. I've upped to iOS 16 already, but I don't exactly know how to call AppTransaction.shared to get originalAppVersion. The issue lies in the fact that my app is based on SpriteKit, so the operative areas I have available to call AppTransaction are ostensibly limited to AppDelegate and GameViewController. I'm using the code from Supporting business model changes by using the app transaction, but if I place it in either GameViewController or AppDelegate, for example in application(_:didFinishLaunchingWithOptions:) or viewDidLoad(), I get an error concerning async/await. Now, I understand the gist of it: these are not asynchronous methods. So I'm trying to understand how to do it perhaps outside of these methods. How do I call AppTransaction.shared (and fetch originalAppVersion) in a SpriteKit based app?

We have 2 monthly subscription tiers that are part of a subscription group, and always have been part of this group. Both are configured with a 1 month trial introductory offer. According to the documentation for auto-renewable subscriptions,: Users can subscribe to one subscription product per group at a time. And yet several users have managed to start trials of both products in this group simultaneously, which converted to paid subscriptions after the expiration of the trials, and now are being concurrently billed by Apple for both. How do we completely prevent this from happening?

While using react-native-iap and being successfully connected with initConnection() I'm not receiving information on subscriptions with requestSubscription(). Attaching the code here, if anyone could assist asap please would be really grateful thanks! Been at it all day and just can't figure. const handleBuySubscription = async (productId) => { try { await requestSubscription({ sku: productId, }); setLoading(false); } catch (error) { setLoading(false); if (error instanceof PurchaseError) { errorLog({ message: [${error.code}]: ${error.message}, error }); } else { errorLog({ message: "handleBuySubscription", error }); } } }; but the requestSubscription({ sku: productId, })

We got Advanced Commerce API and the generic product identifiers approved. When I was try to migrate a sandbox subscription to ACA enabled subscription I hit an error Request payload (Hid some info but the requestReferenceId is the real) { "descriptors": { "description": "Migrated", "displayName": "Migration" }, "items": [ { "sku": "product_1mo_999", "description": "description", "displayName": "Product" } ], "requestInfo": { "requestReferenceId": "3b0b8e67-d8a0-45f4-8f6d-06bffa9a2c08" }, "storefront": "USA", "targetProductId": "com.company.generic.subscription", "taxCode": "C003-00-1" } Response { "errorCode": 5000000, "errorMessage": "An unknown error occurred." }

We are using consumable in-app purchases. Starting from May 27th, we began receiving refund callbacks with the notificationType set to ONE_TIME_CHARGE immediately after users successfully completed a payment. { "notificationType": "ONE_TIME_CHARGE", "signedPayload": "..." } During this period, we did not make any changes to our App release or server-side purchase handling logic. Could this issue result in actual refunds being processed? What steps should we take to resolve this issue? We also noticed in your changelog that a new notification type ONE_TIME_CHARGE has been introduced. Can we safely ignore callbacks with the ONE_TIME_CHARGE notification type without affecting refund processing or user experience?

I set up a sandbox account to test in-app purchases in my development app. I went to settings > dev > sandbox accounts and updated my login in the app store. But I received a 'block'; I can no longer download new versions or anything from the store. I've already removed the sandbox account, and even using my real Apple ID, I can't use the functions.

I have created a Python app and built it with pyinstaller and codesigned everything. Now I want to Sandbox test it. In my appstore connect account i have created a subscriptions id. I read that if I am logged out from the AppStore and have codesigned my .app file with a Developer Certificate i should be able to run the app on my local mac and when i click on the "Buy" button it should connect to my app store connect setup. I have implemented StoreKit in my app and use a storekit_bridge to combine the .swift code with my python app. However when i run the app. I get this: "25-07-24 21:01:12,557 - FEC - WARNING - StoreKit: fetchProducts returned empty result 2025-07-24 21:01:12,557 - FEC - INFO - StoreKit fetch_products returned: {"products": []} 2025-07-24 21:01:12,557 - FEC - ERROR - StoreKit: Failed to parse product info: No products returned from JSON" And no login screen appears where I should be able to enter my Sandbox email adress and password. Anyone here who has experience with a Python app combined with In App Purchases? Hope someone can help me out with this.

I'm encountering an issue with In-App Purchases on Apple TV (tvOS): When a user initiates an IAP for the first time, the system prompts them to sign in with their Apple ID, and the purchase proceeds normally. However, on subsequent purchase attempts, if the Apple ID session has expired or additional verification is required, the system redirects the user to the Settings app to sign in again. After the user signs in via Settings, the app does not automatically return to the foreground. The user must manually press the Menu button to come back. Is this is the normal behaviour of apple tv for InApp purchase? or did I need any code improvement to solve this? What I'm trying to achieve: I'd like the app to automatically return to the foreground once the user has completed the Apple ID login in Settings. Is this behavior supported on tvOS? If not, is there any known workaround or best practice to guide the user back to the app smoothly? Any advice or guidance from Apple or other developers would be greatly appreciated!

Received error that does not have a corresponding StoreKit Error: Error Domain=AMSErrorDomain Code=305 "Purchase Failed Server canceled the purchase More details: Error Domain=AMSErrorDomain Code=305 "Purchase Failed Server canceled the purchase" UserInfo={AMSFailureReason=Server canceled the purchase, AMSURL=https://sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy?guid=00008110-000A4DC10E51401E, AMSDescription=Purchase Failed, AMSStatusCode=200, AMSServerPayload={ "cancel-purchase-batch" = 1; customerMessage = "Unable to process your request."; dialog = { defaultButton = ok; explanation = "Please try again later.\n\n[Environment: Sandbox]"; initialCheckboxValue = 1; isFree = 1; "m-allowed" = 0; message = "Unable to process your request."; okButtonString = OK; }; failureType = ""; "m-allowed" = 0; metrics = { actionUrl = "sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy"; asnState = 0; dialogId = "MZCommerce.SystemError"; eventType = dialog; message = "Unable to process your re"; mtEventTime = "2025-07-28 12:34:22 Etc/GMT"; mtTopic = "xp_its_main"; options = ( OK ); }; pings = ( ); }, NSDebugDescription=Purchase Failed Server canceled the purchase} Received error that does not have a corresponding StoreKit Error: Error Domain=ASDErrorDomain Code=500 "(null)" UserInfo={client-environment-type=Sandbox, storefront-country-code=IND, NSUnderlyingError=0x1276116e0 {Error Domain=AMSErrorDomain Code=305 "Purchase Failed Server canceled the purchase" UserInfo={AMSFailureReason=Server canceled the purchase, AMSURL=https://sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy?guid=00008110-000A4DC10E51401E, AMSDescription=Purchase Failed, AMSStatusCode=200, AMSServerPayload={ "cancel-purchase-batch" = 1; customerMessage = "Unable to process your request."; dialog = { defaultButton = ok; explanation = "Please try again later.\n\n[Environment: Sandbox]"; initialCheckboxValue = 1; isFree = 1; "m-allowed" = 0; message = "Unable to process your request."; okButtonString = OK; }; failureType = ""; "m-allowed" = 0; metrics = { actionUrl = "sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy"; asnState = 0; dialogId = "MZCommerce.SystemError"; eventType = dialog; message = "Unable to process your re"; mtEventTime = "2025-07-28 12:34:22 Etc/GMT"; mtTopic = "xp_its_main"; options = ( OK ); }; pings = ( ); }, NSDebugDescription=Purchase Failed Server canceled the purchase}}} Purchase did not return a transaction: Error Domain=ASDErrorDomain Code=500 "(null)" UserInfo={client-environment-type=Sandbox, storefront-country-code=IND, NSUnderlyingError=0x1276116e0 {Error Domain=AMSErrorDomain Code=305 "Purchase Failed Server canceled the purchase" UserInfo={AMSFailureReason=Server canceled the purchase, AMSURL=https://sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy?guid=00008110-000A4DC10E51401E, AMSDescription=Purchase Failed, AMSStatusCode=200, AMSServerPayload={ "cancel-purchase-batch" = 1; customerMessage = "Unable to process your request."; dialog = { defaultButton = ok; explanation = "Please try again later.\n\n[Environment: Sandbox]"; initialCheckboxValue = 1; isFree = 1; "m-allowed" = 0; message = "Unable to process your request."; okButtonString = OK; }; failureType = ""; "m-allowed" = 0; metrics = { actionUrl = "sandbox.itunes.apple.com/WebObjects/MZBuy.woa/wa/inAppBuy"; asnState = 0; dialogId = "MZCommerce.SystemError"; eventType = dialog; message = "Unable to process your re"; mtEventTime = "2025-07-28 12:34:22 Etc/GMT"; mtTopic = "xp_its_main"; options = ( OK ); }; pings = ( ); }, NSDebugDescription=Purchase Failed Server canceled the purchase}}}

Hello, My app "MyCourses" (bundle id: com.ahmedbaqer.mycourses) was rejected under Guideline 2.1 because "No action followed when we tapped the button to subscribe to a course" on iPadOS 26.1. When I run the same code (version 1.0.0 (11)) from Xcode on a real device using a StoreKit configuration file (In App Purchase.storekit), the purchase flow works correctly: When I tap the "Subscribe via Apple" button, the App Store purchase sheet appears. The purchase completes successfully and unlocks the course. I use the in_app_purchase Flutter plugin and queryProductDetails to load products. However, when I install the build via TestFlight (and in App Review), tapping the same "Subscribe via Apple" button does nothing – which matches the behavior described by App Review. From my logs it looks like queryProductDetails is returning an empty productDetails list in that environment. For In‑App Purchases: I created 7 non‑consumable products in App Store Connect. Their Product IDs exactly match the IDs in my In App Purchase.storekit file (used only for local Xcode testing). All IAPs are now in "Waiting for Review" status and are linked to the iOS app version 1.0.0 (11) in the “In‑App Purchases and Subscriptions” section. At the time of the original review, some IAPs were in "Developer Action Needed / Rejected" state, so I suspect queryProductDetails may have returned no products and the reviewer saw no action after tapping the button. My questions: When IAP products are in "Waiting for Review" and linked to the app version, should queryProductDetails return them during App Review / TestFlight, or do they need to be fully approved first? Is there any additional configuration required so that the subscribe button reliably shows the App Store purchase sheet for reviewers (for example, any specific StoreKit / sandbox settings)? Are there recommended best practices to show a clearer error state when queryProductDetails returns no products, so that App Review understands this is a configuration / IAP-status issue rather than a UI bug? Any guidance from Apple engineers or other developers who faced a similar situation would be greatly appreciated. Thanks in advance.