login sandbox account at setting > app store > sandbox account. download my app from testflight purchase subscription is fine. stop renew subscription. after subscription expired, delete app, then download from testflight again. tried to restore purchase, the result count always zero

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.

We’ve been approved for the Advanced Commerce API and are setting up the generic product identifiers per the guide: https://developer.apple.com/documentation/advancedcommerceapi/setting-up-your-project-for-advanced-commerce#Set-up-generic-product-identifiers We have multiple auto-renewable subscriptions (for simplicity: Product 1, Product 2, etc.). We created a new subscription group for Advanced Commerce and are about to add the subscription(s) inside that group. Should we create one auto-renewable subscription (generic, e.g. subscription.ac) to represent all of our subscriptions, or one generic per product family (e.g., product1.ac, product2.ac, …)? If the answer depends on whether subscribers can hold multiple products simultaneously, please advise which structure supports that (e.g., separate groups). Reporting identifiers / segmentation: In Sales and Trends and Payments & Financial Reports, which identifier(s) will appear after migration: the legacy StoreKit product_id, the new generic product id, and/or the SKU? If we use a single generic subscription for all products, what’s Apple’s recommended way to segment revenue by product (Product 1 vs. Product 2)? If SKUs don’t surface in these reports, should we prefer multiple generics/groups to preserve report-level segmentation?

The tutorial only says a notification will be sent, but what happens next..? what should we do about the child account..? are we blocking them..? what happens on the child account? https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox

Hello! We are implementing consumable IAP for iOS using StoreKit 2 together with our own server backend. Our happy path looks like this: 1. Call /prepare on our server • We only allow one purchase at a time, so this fails if a pending transaction already exists. 2. Call /purchase via StoreKit 3. If successful, call /complete on our server 4. Call .finish() on the Transaction ⸻ The Problem Some users report being charged by Apple but not receiving coins. I suspect this happens in rare cases where the purchase flow throws an exception: • Every time we throw, we immediately cancel the transaction on our server. • However, some errors may actually be temporary. StoreKit seems to recover by later sending an update through Transactions.updates. • When that happens, since the transaction was already canceled on our server, we cannot match it. As a result, we just call .finish() without granting consumables. ⸻ Additional Observations From user logs, the issue tends to appear when the following errors are reported: • リクエストを完了できません。 • Triggered by: StoreKit.notEntitled • Triggered by: StoreKit.unknown • ヘルパーアプリケーションと通信できませんでした。 I was not able to reproduce the last one, even when testing all possible StoreKit configuration errors. Some sources suggest this may be a rare case where the app cannot communicate with the App Store itself. Additionally, affected users often seem to be using non-standard payment methods (PayPay, gift cards, carrier billing, etc.) rather than credit cards. ⸻ My Question What is the best practice for handling StoreKitError and PurchaseError? Specifically: • Should some of these errors be treated as temporary instead of final? • How should we ensure users always receive their consumables in such cases? ⸻ Code do { let result = try await wrapper.product.purchase() switch result { case .success(let result): let transaction = try StoreKitVerifier.checkVerified(result) let iOSPurchase = IOSPurchase(transaction: transaction, jws: result.jwsRepresentation) return .Success(purchase: iOSPurchase) case .userCancelled: return .Canceled() case .pending: return .Pending() @unknown default: return .Error( message: "Purchase result doesn't match with anything. This must not be executed") } } catch { return .Error(message: error.localizedDescription) }

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?

I am attempting to test non-consumable sandbox purchases, however I am unable to select the "Approve Transaction" option after initiating a purchase. Leaving the transaction in a permanent pending state. I can view the transaction in the transaction manager by navigating to Debug -> Storekit -> Manage Transactions.. but the only available options to select are "Refund Transaction" or "Delete Transaction". What am I missing about Xcode or my environment that is preventing me from testing this purchase flow? Some more information about my set up. I have a .storekit file synced to AppStore Connect with my product Id. There's a StoreKitTestCertificate.cert saved in the project. I've tried running the build on my phone as Debug, Release and ReleaseForRunning all with the same behavior after making a purchase. My phone is logged into a sandbox test user apple account in the developer iOS settings

Trying to test IAP in sandbox. I created the test group and tester accounts. Accepted the invite downloaded the app. Signed into to sandbox in settings with the tester account. In app the purchases are failing and throwing my catch error message product couldn't be found. I decided to test it from settings/ sandbox/ manage/ initiate purchase/ but I've been getting "can't complete transaction. Something went wrong, ant this transaction couldn't be completed. Try again later" since last week. I reached out to dev support over the phone then email and they couldn't or wouldn't provide assistance. I asked my senior at work she took a look at it and confirmed I created the IAP correctly and that my sandbox account could make test purchases in apps she make but couldn't get mine to work. The storekit test work fine in xcode I just don't know what to do now.

Hello. I have setup a StoreKit testing in the app that was and still is perfectly working on iOS 18. Unfortunately when run on iOS 26 the following error gets printed in the console after calling Transaction.currentEntitlement(for:) method: Failed to verify certificate chain due to client recoverable failure: Error Domain=NSOSStatusErrorDomain Code=-67843 "“StoreKit Testing in Xcode” certificate is not trusted" UserInfo={NSLocalizedDescription=“StoreKit Testing in Xcode” certificate is not trusted, NSUnderlyingError=0x109de7e10 {Error Domain=NSOSStatusErrorDomain Code=-67843 "Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;" UserInfo={NSLocalizedDescription=Certificate 0 “StoreKit Testing in Xcode” has errors: Root is not trusted;}}} I'm not seeting any StoreKit Testing certificates in phone's certificate trust settings. This test was performed on iOS 26.0 (23A341) with app built in Xcode 16.4. FB20339145

Looking to update one of my apps that uses SKStoreReviewController +requestReview (deprecated) to AppStore.requestReview(in:) umm...I have a few of questions... Why is an NSViewController parameter required? It's really not so uncommon for an AppKit app to just use NSWindowController with a window that does not use NSViewController... It should be possible to present the review request in a standalone alert (attached to a window is preferred IMO but it still should be possible to ask in separate window). 3)...why Swift..(err nevermind) Ideally: AppStore requestReview should take a NSWindow parameter but that parameter should be optional. If nil the request should be presented in a standalone window (like an alert). If non nil..present as a sheet on the window. Why a view controller? Maybe I'm missing something.

We are seeing an issue with a potential duplicate charge issue regarding our app. We have received two transactions with the same originalTransactionId but different transactionIds: Order A: TransactionId: [Redacted_TID_1] OriginalTransactionId: [Redacted_OID_A] ProductId: weekly_subscription PurchaseDate: [Redacted_Timestamp_1] SignedDate: [Redacted_Timestamp_2] Price: [Redacted_Price] CAD Order B: TransactionId: [Redacted_TID_2] OriginalTransactionId: [Redacted_OID_A] ProductId: weekly_subscription PurchaseDate: [Redacted_Timestamp_1] SignedDate: [Redacted_Timestamp_3] Price: [Redacted_Price] CAD Both transactions share the same originalTransactionId, productId, and expiresDate, but the transactionIds are different. We wanna confirm: Were customers charged once or twice for this subscription renewal? If only one charge was made, how should we programmatically determine the “valid” transaction among multiple records with the same originalTransactionId to avoid confusion in our server-side receipt validation? We appreciate any clarification so we can handle this correctly in our backend.

Hey guys, This is a general question, but I have been working on an app for a while and I would like to to introduce IAP to the app. I have no clue where to start and chat GPT is no help. I also tried to vibe coding the IAP function and that didn't work out well. Any material or advice would help.

Hello, I’m experiencing repeated rejections related to Guideline 2.1 – App Completeness for an iOS app using auto-renewable subscriptions, and I’m struggling to understand what is missing, as the purchase flow works correctly in sandbox and TestFlight. App setup: iOS app built with React Native (Expo + react-native-iap) Auto-renewable subscriptions: • Monthly: €4.99 • Yearly: €39.99 Paid Apps Agreement accepted Subscriptions configured and active in App Store Connect Privacy Policy and Apple Standard EULA included: • Visible inside the app on the subscription screen • Added in App Store metadata What App Review reports: App Review states they are unable to buy the in-app purchase, resulting in a rejection under Guideline 2.1 (App Completeness). What works correctly: getSubscriptions() returns valid products in sandbox Subscription titles, prices, and durations are displayed in the app UI requestSubscription() is triggered when tapping the subscribe button Apple purchase sheet appears and completes successfully in: • Sandbox testing • TestFlight (external testers) What I’ve verified: No conditional logic blocks purchases in review builds Purchase button always calls requestSubscription purchaseUpdatedListener and purchaseErrorListener are correctly registered No hardcoded prices; prices come from StoreKit Same behavior on iPhone and iPad Question: Is there any known limitation or requirement in the App Review environment for auto-renewable subscriptions that differs from sandbox/TestFlight when using a custom subscription UI (not SubscriptionStoreView)? If App Review requires a specific implementation detail (StoreKit 2, SubscriptionStoreView, or something else), I would really appreciate clarification, as this is not explicitly stated in the rejection. Thank you for your help.

I'm on macOS Sequoia Version 15.7.3 (24G419) and using Xcode Version 26.2 (17C52). In my Xcode project, Transaction.updates and Product.SubscriptionInfo.Status.updates don’t seem to emit updates reliably. The code below works consistently in a fresh Xcode project using a minimal setup with a local StoreKit Configuration file containing a single auto-renewable subscription. class InAppPurchaseManager { static let shared = InAppPurchaseManager() var transactionTask: Task<Void, Never>? var subscriptionTask: Task<Void, Never>? init() { print("Launched InAppPurchaseManager...") transactionTask = Task(priority: .background) { for await result in Transaction.updates { print("\nReceived transaction update...") try? await result.payloadValue.finish() } } subscriptionTask = Task(priority: .background) { for await result in Product.SubscriptionInfo.Status.updates { print("\nReceived subscription update...") print("state:", result.state.localizedDescription) } } } } I initialise it in: func applicationDidFinishLaunching(_ aNotification: Notification) { _ = InAppPurchaseManager.shared } I do not build any UI for this test. I open StoreKit Transaction Manager then click Create Transaction → select the product → choose Purchase (Default) → Next → Done. The console shows that it detects the initial purchase, renewals and finishes each transaction. It also works even if I do not add the In-App Purchase capability. In my actual project, the initial purchase is detected and finished, but renewals are not detected. Subsequent transactions then appear as unverified, presumably because the updates are not being observed so the transactions are not being finished. What can I do to make this work reliably in my actual project? For context, in the actual project: I have a StoreKit Configuration file that is synced with App Store Connect The In-App Purchase capability is enabled The configuration file is selected in the scheme The products in App Store Connect show “Ready to Submit” Loading products works: try await Product.products(for: ...) Also, I use ProductView for the purchase UI. The first purchase works and is detected and finished, but subsequent renewals are not finished because the updates do not seem to be emitted.

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.

Hello, I would like to ask about an Apple ID authentication behavior during in-app purchases. Our app uses a StoreKit 1 (SKPaymentQueue-based) implementation, and there are no differences in the in-app purchase logic between the TestFlight build and the App Store production build. However, we have observed that some users are prompted to enter their Apple ID password during in-app purchases. The observed behavior is as follows: On the first in-app purchase, the system prompts for the Apple ID password After the password is entered once, subsequent purchases proceed normally using Face ID (double side-button press) Even after deleting and reinstalling the app, or switching between TestFlight and App Store builds, the password prompt does not reappear if authentication has already occurred This behavior can occur even when the Apple ID already has an active auto-renewable subscription The only confirmed change on our side is: The app is now built with Xcode 26 instead of Xcode 18 Based on this, we are currently considering the following possible causes: A change in purchase authentication behavior due to the Xcode version update Expiration of the Apple ID purchase authentication session after a long period without purchases In addition to these points, we would like to ask: Are there any other common conditions or security policies in iOS or the App Store that may cause the system to require Apple ID password input during in-app purchases? Is this behavior considered expected under certain circumstances? We would appreciate your clarification on whether this is expected system behavior or if there are any implementation aspects we should further review. Thank you for your support.

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

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.

I’m reaching out regarding our existing in-app subscription implementation that currently uses App Store Server Notifications version 1 (v1). Our live application has a significant number of active recurring subscriptions that are being managed through the v1 webhook integration. We have now developed a revamped version of our application, which uses the same Apple Developer Account and App Store Connect setup, but in this new app version, we’ve implemented App Store Server Notifications version 2 (v2). Before moving forward with the migration, I would like to clarify the following points to ensure a smooth transition and avoid any disruptions to ongoing subscriptions: Backward Compatibility: Will existing active subscriptions (originally created and managed via v1 notifications) continue to work seamlessly once we switch to v2, or do we need to maintain both v1 and v2 endpoints during the transition? Notification Delivery: If both webhook versions are configured simultaneously, will Apple send notifications to both endpoints, or only the one currently configured in App Store Connect? Migration Strategy: What is Apple’s recommended best practice for migrating from v1 to v2 in a scenario where the live app still has active subscriptions tied to the v1 webhook? Potential Risks or Considerations: Are there any known limitations, delays, or issues that we should prepare for during this migration (for example, differences in payload structure or event types between v1 and v2 that could affect subscription lifecycle management)? I would greatly appreciate your guidance or documentation links that outline the correct migration steps and recommended approach for ensuring continuity of service for all existing subscribers.

Hello, I have a question regarding the App Store Server API's getTransactionInfo endpoint. Previously, the official documentation for getTransactionInfo mentioned that: “This endpoint doesn’t support an app transaction. To get information about an app transaction, decode the signed app transaction received from the device.” However, as of June 2025, I can no longer find this sentence in the current documentation (link). Now, the docs state that all in-app purchase transaction IDs are supported (consumable, non-consumable, auto-renewable subscriptions, etc.). But in practice, when I call getTransactionInfo with an AppTransactionId (extracted from a signed App Transaction JWS), I receive this error: apiErrorCode: 4000048 “Invalid request. App transactions aren’t supported by this endpoint.” Is this endpoint supposed to support AppTransactionId now, or is the restriction still in place (but not mentioned in the docs)? Is there any official statement about when this restriction was added/removed? Can you clarify if only in-app purchase transaction IDs (and not AppTransactionIds) are supported for this endpoint, or has the policy changed recently? Any clarification or historical context would be greatly appreciated. Additionally, I would like to know about the behavior of an App Transaction in the event of a refund. If a user receives a refund for the app itself (not an in-app purchase), how can changes to the AppTransaction be detected? Does the App Store Server Notification v2 provide notifications for app-level refunds, or are such events only visible by decoding the latest App Transaction JWS on the device? Is there any way to receive app-level refund information server-side, or must we always rely on the device to provide the updated signed app transaction? Any clarification on this refund flow and notification coverage would also be appreciated. Thank you!