We have in-app purchases live and working fine for standard subscriptions. We also have promotional offers active for existing users (to give existing users a discount as a thank you). Yet, regardless of the user type (existing vs new... we have tested with all types), we get the "Your account is not eligible for this offer" error message when clicking the discounted offer. What is the logic for determining eligibility? I'm trying to debug as it's not clear to me why this message would show up. We are using React Native IAP. In general, how does the eligibility check work? What conditions are being evaluated and compared? And what could break those conditions? I appreciate your help! DDD

Hi apple team, I'm using Apple Root Certificates from https://www.apple.com/certificateauthority/ for communicating with App Store Server Library for receipt validation API. Apple Computer, Inc Root certificate from the website is Not Valid After: Monday, 10 February 2025 at 01:18:14 Central European Standard Time. When we can expect update of this certificate. Thank you

We are in the process of implementing promotional offers for auto-renewable subscriptions in our app using StoreKit 2. For testing, we use a sandbox user alongside a new user on our platform. I can successfully purchase an Introductory Offer through the app. Once the user is eligible for a Promotional Offer (based on a previous purchase), we retrieve the Promotional Offer identifier and signature from our backend and display the offer. After initiating the purchase and having the user enter their Sandbox password, the transaction is added to the Payment Queue. However, it fails with the following error: Purchase failed error: invalidOfferSignature Additionally, the error returned is: "Purchase did not return a transaction: Error Domain=ASDServerErrorDomain Code=3903 "Unable to Purchase" UserInfo={NSLocalizedFailureReason=Unable to Purchase, client-environment-type=Sandbox, AMSServerErrorCode=3903, storefront-country-code=IND}" We are using StoreKit 2 APIs for this process. Has anyone encountered this issue when working with StoreKit 2, or found a solution to resolve it?

I am working on a banking application (includes iPhone and iPad) which includes add to wallet feature. During the implementation I saw one document it is mentioned that for iPad app, the app must be extended to support Apple pay functionality. Details from document says "Card Issuers with an iOS mobile banking app must support Card Issuer iOS Wallet extension functionality to enable Card issuer mobile app customers to provision new cards directly from the iOS Wallet app with all eligible Apple iOS devices. If the Card Issuer has a dedicated iPad App, that App must be extended to support Apple Pay functionality. " Is wallet extension implementation required for Apple pay to work in iPhone and iPad? Is wallet extension a mandatory implementation for Add to Apple Wallet feature to work and approved by Apple? I am little confused in this. Anyone who integrated Apple pay or done add to Apple Wallet feature recently without wallet extension faced any rejection? Any help would be much appreciated.

I got some crashes on firebase console Fatal Exception: NSInvalidArgumentException -[NSNull length] the code stack show the StoreKit and the systems are all 18.2. I haven't update to storekit2, but it shouldn't crash for storekit1.

Hello, We have received three CONSUMPTION_REQUEST notifications for the same transactionId. We sent a response to each CONSUMPTION_REQUEST notification to the API and received a 202 Accepted response. Why do we receive multiple CONSUMPTION_REQUEST notifications even though we have sent a ConsumptionRequest to the Apple Store Server API? Do we need to respond to each CONSUMPTION_REQUEST for the same transactionId? Thanks

I use [[SKPaymentQueue defaultQueue] restoreCompletedTransactions]. Works on my App which is in the store (compiled pre-iOS 26). If I compile the same App now, same codebase with Xcode Version 26.0, restore does not work. Nothing happens. Tested on real device (iOS 26). Documentation says its deprecated, but my deployment target is iOS 12. Anyone has similar issues? Any recommendations?

Hi all, I am adding the following StoreKit 2 code to my app, and I don't see anything in Apple's documentation that explains the unverified case. When is that case exercised? Is it when someone has tampered with the app receipt? Or is it for more mundane things like poor network connectivity? // Apple's docstring on `shared` states: // If your app fails to get an AppTransaction by accessing the shared property, see refresh(). // Source: https://developer.apple.com/documentation/storekit/apptransaction/shared var appTransaction: VerificationResult<AppTransaction>? do { appTransaction = try await AppTransaction.shared } catch { appTransaction = try? await AppTransaction.refresh() } guard let appTransaction = appTransaction else { AppLogger.error("Couldn't get the app store transaction") return false } switch appTransaction { case .unverified(appTransaction, verificationError): // For what reasons should I expect this branch to be entered in production? return await inspectAppTransaction(appTransaction, verifiedByApple: false) case .verified(let appTransaction): return await inspectAppTransaction(appTransaction, verifiedByApple: true) } Thank you, Lou

We’re testing SKAN postbacks via AdAttributionKit but aren’t receiving any requests on our server even after generating development impressions and triggering a postback. Setup: Domain: https://linkrunner-skan.com Configured in Info.plist as: <key>NSAdvertisingAttributionReportEndpoint</key> <string>https://linkrunner-skan.com</string> <key>AttributionCopyEndpoint</key> <string>https://linkrunner-skan.com</string> Apple automatically appends the .well-known paths: /.well-known/private-click-measurement/report-attribution/ /.well-known/skadnetwork/report-attribution/ ATS diagnostics for the domain: PASS for all tests (TLS 1.0–1.3, PFS disabled, arbitrary loads allowed, etc.) Both .well-known paths are publicly accessible and return 200 OK Testing Flow: Enabled Developer → AdAttributionKit Developer Mode on iOS (15+) Followed Apple’s official guide: Testing AdAttributionKit with Developer Mode Generated test impression using: createAdAttributionKitDevelopmentImpression implemented in SKANManager.swift Called Postback.updateConversionValue with lockPostback: true Created Development Postback from Developer Settings Waited 30+ minutes while intercepting server requests (proxy + backend logs) What We’ve Tried So Far: Confirmed ATS compliance with nscurl --ats-diagnostics (all PASS) Verified .well-known paths are accessible publicly without redirects Tested endpoints manually with a POST request – server responds 200 OK Confirmed Info.plist entries exactly match Apple’s required keys Double-checked iOS device is running iOS 15+ with Developer Mode enabled Repeated test flow multiple times with fresh impressions and postbacks Waited up to 1 hour for postback (in case of delays) Issue: No POST requests are being received from Apple to either .well-known endpoint, even though the setup appears correct and ATS tests pass. References Used: Configuring an Advertised App Generating JWS Impressions Question: Has anyone faced a similar issue where AdAttributionKit Development Postbacks are not firing despite correct Info.plist setup, ATS compliance, and reachable .well-known endpoints? Any insight into possible missing configuration steps or testing nuances would be greatly appreciated.

This is a copy of a reply to this post. https://developer.apple.com/forums/thread/722222?page=1 I'm posting as new in the hope someone might have more up-to-date information, as I'm pulling out what little hair I have left. I'm using Storekit 2, testing in Xcode with a local Storekit config file. I have created a very minimal system to investigate this issue. I have a SwiftUI-based window using SubscriptionStoreView, and my app set up with the usual listener. I have four types of auto renewing subscription, configured in the local Storekit config file. With my app running, I subscribe to the lowest-level subscription I offer, via the SubscriptionStoreView. Notification of the inital purchase arrives, but subsequent auto-renewals do not trigger any action in my listener for Transaction.updates. They arrive as expected in the Transaction Manager. Radio silence in my listener. If I upgrade one subscription (via my SubscriptionStoreView) I see this reflected in the UI immediately, and also in the Transaction Manager, but the update that arrives in Transaction.updates refers to the old subscription, and has the isUpgraded flag set to false. Also, can anyone remind me what the grey warning triangle next to entries in the Transaction Manager means. I'm assuming it means unfinished, as that's what the sidebar indicates. Can the testing system really be this broken, or am I wildly off the mark? Unless I'm doing something fundamentally wrong this all seems extremely flakey, but happy to be proved wrong. I find this all rather unsettling if I can't test reliably, and am concerned that I my app may end up in this situation if I use storekit 2: https://stackoverflow.com/questions/73530849/storekit-renewal-transactions-missing-in-transaction-all-or-transaction-updates

What happens after 12 renewals? Does the subscription expire completely? The next day when I try to manage settings for my sandbox account it says it cannot connect. I cannot see the status of subscription in: Settings-> App Store -> Sandbox Account -> Manage Logging out and logging in of my regular account does not fix that. When I login with a different non-testflight sandbox account I can finally edit those settings. There are some missing details in documentation explaining testflight sandbox accounts. Do these accounts stop working after 12 auto-renewals? I need more specific details in order to ensure subscriptions will work properly during production.

Hi, I'm using the AppTransaction.shared API to retrieve the originalAppVersion, but I'm encountering issues for users who originally installed the app in 2017. Specifically, the property doesn't seem to return the expected value (or returns nil) for these older accounts. I have verified this issue using a real App Store purchase from 2017. Steps to Reproduce: Use a test account that originally downloaded the app in 2017. Call: let shared = try await AppTransaction.shared print(shared.originalAppVersion) Observe that originalAppVersion is missing or not returned correctly. Any insights on whether this is expected behavior for very old App Store purchases, or if there is a workaround to reliably detect the original app version? Thanks in advance!

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!

We are utilizing the StoreKit external purchase link within the app and have configured the necessary keys in the entitlements according to the documentation. The Info.plist file has also been updated with the required key and a single destination URL, following the guidelines from this documentation. However, when we click the link in the app, it redirects to the default browser, and the in-app system disclosure sheet does not appear. Should the in-app disclosure sheet appear automatically, or do we need to design and implement it ourselves?

After the release of StoreKit 2.0, the in-app purchase failure rate increased by 63.19%, with the majority of errors being StoreKitError.unknown. When encountering this error, many users repeatedly attempt to make a purchase, but the outcome remains unchanged, resulting in the same unknown error. In some cases, users who wait approximately 2 minutes before retrying the purchase may either succeed or encounter the following error: “StoreKit.StoreKitError.systemError(Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.storekitd”)”. This issue has directly impacted our app's purchasing flow. Because our app only displays the promotional purchase offer once, these issues have significantly reduced the number of users successfully completing the offer. As a result, the conversion rate for this promotion has dropped well below expectations, negatively impacting our business metrics.

I don't know if this is a iOS 18.1 beta bug or some StoreKit server issues but Product.SubscriptionInfo.Status is returning an empty array in production even if the user has a valid subscription that is months away from expiring or renewing. I myself ran into this issue this morning but of course everything is fine in development mode so that makes it quite challenging to debug. Anyone else has this issue?

I want to add in-app purchasing to my app, but I can't figure out what part of my workflow is wrong. I created a product for my app in iTunes Connect (the product ID is com.mycompany.products.***) and it's in "Ready to submit" status. I created a sandbox test user for this app. I connected to iTunes on a real device using the sandbox AppleID. I went back to XCode and added in-app purchasing to my app. I turned on developer mode on the real device and logged in as the sandbox user. I built the app and ran it on a real device (not the simulator). I tried to get product information (com.mycompany.products.***) but nothing was returned. In-app purchasing is registered in App Store Connect and the status is "Ready to submit". The code only retrieves product information in a simple way, so I don't think there's a problem. inAppPurchase.getProducts(["com.mycompany.products.***"]).then(console.log).catch(console.error); But it only returns an empty array. What could be wrong? Any help would be much appreciated.

I did an in app purchase in my development app and now I cannot get rid of it. It is a "monthly" subscription that seems to renew every 1 day. I can see the subscription when I go to settings then tap on Subscriptions. Then I tap the item and choose "Cancel Subscription", revealing a new modal sheet saying "Confirm Cancellation". When I "Confirm", I get the popup: "Your request is temporarily unable to be processed, please try again later". However, this is anything BUT temporary, has gone on for a couple weeks now. As such, I am unable to test subscriptions in my development app. I've tried logging out, restarting, different devices, etc. The phone is logged in under my primary user account, and I may not have been logged into sandbox email when I did the purchase. Can someone forcibly remove it for me?

I am working on a paywall, and SubscriptionStoreView seems to work just fine when using the XCode environment but goes bonkers when using Sandbox. Specfically, after making a subscription, I don't get the "Your plan" flag, and the subscription buttons fail to do anything. Hitting one of those the app just sits there....mocking me with its silence. "Clear purchase history" does nothing when done either the iPhone or the Sandbox account page on the website. Nor does the subscription seem to expire after the expiration time of 3 minutes that I am using. Anyone else see this? is this similar to the TestFlight issues people had a year ago?

We're experiencing an unusual issue with SKProductsRequest in our app's in-app purchases. Despite confirming that all our product IDs are correct, the invalidProductIdentifiers property of SKProductsResponse sometimes contains all the requested product IDs. Here are the specifics: The issue occurs randomly and is not persistent. For instance, around 2024-12-26 -8.0 01:06:04, this problem occurred 3 times in quick succession. The didFailWithError method of SKRequestDelegate is not triggered, reporting no errors. Some users report that after encountering this issue, it resolves itself after about an hour. However, other users have reported this problem persisting for several days. We have repeatedly verified the correctness of our product IDs. Given the intermittent nature of the problem, we suspect this might be an issue on the App Store server side. We're looking for suggestions to resolve or mitigate this issue to improve the reliability of in-app purchases in our application. Has anyone encountered a similar issue? Or does anyone have suggestions that could help us further diagnose and resolve this problem?