works perfectly on android but doesn't work at all on IOS and i have used the same bundle id and product ids on both stores. The error that i get on IOS is : "IAP initialization failed: NoProductsAvailable - No Product returned from store" Here are the things that i've done: Created an App ID on the apple developer portal with the correct capabilities I have enabled the correct capabilities on the xcode project Unity Framework is embed and signed, Storekit (do not embed) In singin and capabilities in-app purchases is there I am using testflight to submit the app with a distribution certificate that appears to be valid I've checked the the bundle identifier and it's the same everywhere (unity project, xcode project, App ID) All of the products are cleared for sale and are in the status "ready to submit" I always uninstall the old app version before testing the new one My banking updates are still processing does this effect TestFlight IAP Paid Apps Agreement is in Pending User Info state does this effect also I still haven't filled out the tax forms, so I'm wondering if I need to complete them before my app's in-app purchases (IAPs) work in TestFlight.

We are currently integrating In-App Purchases for our app and have configured App Store Server Notifications (v2) in the Sandbox environment. During testing, we observed the following issue: When a transaction is cancelled, declined, or pending (e.g., Ask to Buy flows or authorization pending), No App Store Server Notification is sent to our webhook endpoint. We only receive webhook events where the status is "purchased". This becomes a critical problem for us because our backend must accurately track transaction states including failed and pending purchases, especially for wallet top-up use cases. Additionally, we tried mocking failed transactions (via Xcode local environment and turning off In-App Purchases from Developer Settings) to simulate a technical failure scenario. Even in these cases, no webhook notification was received when the purchase failed server-side. Is it expected behavior in Sandbox that only successful transactions ("purchased") trigger webhooks? Are failed or pending transactions suppressed in Sandbox intentionally? Will webhook behavior be different in Production (i.e., will we receive webhook notifications for failures there)? Is there any extra configuration or entitlement needed to fully test failure scenarios via webhooks in Sandbox?

We are currently integrating In-App Purchases for our app and have configured App Store Server Notifications (v2) in the Sandbox environment. During testing, we observed the following issue: When a transaction is cancelled, declined, or pending (e.g., Ask to Buy flows or authorization pending), No App Store Server Notification is sent to our webhook endpoint. We only receive webhook events where the status is "purchased". This becomes a critical problem for us because our backend must accurately track transaction states including failed and pending purchases, especially for wallet top-up use cases. Additionally, we tried mocking failed transactions (via Xcode local environment and turning off In-App Purchases from Developer Settings) to simulate a technical failure scenario. Even in these cases, no webhook notification was received when the purchase failed server-side. Is it expected behavior in Sandbox that only successful transactions ("purchased") trigger webhooks? Are failed or pending transactions suppressed in Sandbox intentionally? Will webhook behavior be different in Production (i.e., will we receive webhook notifications for failures there)? Is there any extra configuration or entitlement needed to fully test failure scenarios via webhooks in Sandbox?

In my APP for now contains IAP for one time purchase. By adding to APP auto-renewable subscriptions can I ask from customers(that purchased on App Store and IAP ) to purchase subscription. For customers that purchase IAP, ask to purchase subscription after year from IAP was purchased.

Hello, Does a customer may redeem the same promotional offer multiples times? For example, get 25% of our app subscription for one year, and then we give the customer the same promotional offer for a second year at 25% off? Thank you

Hello everyone, I’d like to ask for your input regarding best practices for implementing In-App Purchases (IAP) across both the frontend and backend. Here’s our current flow: -Frontend (Mobile) The user opens a specific page. We initiate a payment request using react-native-iap. After the user completes the payment, we send the purchase data (receipt) to our backend. Backend: Accept the purchase receipt from the app. Validate the receipt with Apple’s server. (GET https://api.storekit.itunes.apple.com/inApps/v1/transactions/{transactionId}) If the receipt is valid and the response indicates success, we mark the payment status as PAID. We store the transaction ID in our payment module. The Issue: We recently encountered a situation where Apple returned a valid receipt, so we marked the transaction as PAID. However, later we realized that the payment status was actually Pending. { transactionId: '70002676245699', originalTransactionId: '70002676245639', bundleId: '', productId: '', purchaseDate: 1745560404000, originalPurchaseDate: 1745560404000, quantity: 1, type: 'Consumable', inAppOwnershipType: 'PURCHASED', signedDate: 1745981078460, environment: 'Production', transactionReason: 'PURCHASE', storefront: 'SGP', storefrontId: '', price: 5000, currency: 'SGD', appTransactionId: '' } This raised a few questions: Does a Pending status always resolve to Paid, or is there a risk that Apple may later mark it as Failed or Unpaid? Is there a specific field in Apple's receipt response that reliably indicates whether the purchase is truly active? Should we hold off on granting access or product delivery until the status transitions from Pending to Paid? We’d really appreciate any insights or recommendations on how to handle this edge case to avoid granting access prematurely. Thanks in advance!

Hey everyone, I’m submitting my first version of an iOS app to the App Store and ran into an issue I can’t seem to resolve. The app was rejected because during review, Apple couldn’t see the In-App Purchase product on the purchase screen. That’s their only complaint — everything else works fine. Here’s what’s going on: • In debug mode via Xcode, the product shows up correctly, and everything works as expected. • In TestFlight builds, the product doesn’t show up at all — neither for me nor for Apple. • The IAP is currently marked as “Waiting for Review”, not “Ready to Submit”, and it is linked to the current app version in App Store Connect. I’m not sure if the IAP being in “Waiting for Review” is the reason it doesn’t show up in the TestFlight version — but I assumed Apple would still be able to access it for testing. Has anyone experienced this? Do I need to wait for the IAP itself to be approved before it works in TestFlight and can be reviewed? Any insights would be super helpful. Thanks!

We have had a small number of users of our mac app complaining that the app suddenly can't detect their subscription or previous purchase history. These users are not new, and have been using the app successfully for some time. In the app we do this using the following (very standard) code at app startup: let result: VerificationResult<AppTransaction> = try await AppTransaction.shared For those users experiencing the failure, the result is coming back as unverified. So far we've been unable to find the cause or a solution, but it seems to have become worse with the release of macOS 15.4. We've tried resetting, rebooting and reinstalling the app. It's worth adding the (probably obvious) that it's impossible to test or fault-find with this, because we can't replicate the issue in a development environment. Any suggestions gratefully received.

Hi, I have added widgets to my iOS app and I would like to make this feature only accessible to "pro" users that have made a non-consumable in-app purchase. Currently, I am doing the following: I store an "isUnlocked" property in the Keychain after the purchase is made I read data to be displayed in the widget and here I also query the Keychain and store whether the widget is unlocked I have no refresh policy, but only change the widget data on a significant time change a different view is displayed when the app is locked Some dummy code snippets: func getTimeline(in context: Context, completion: @escaping (Timeline<Entry>) -> Void) { &#9;&#9;let entry = readContents() &#9;&#9;let timeline = Timeline(entries: [entry], policy: .never) &#9;&#9;completion(timeline) } struct WidgetEntryView: View { &#9;&#9;let entry: Provider.Entry     @Environment(\.widgetFamily) var family     @ViewBuilder     var body: some View {         switch family {         case .systemSmall:             if !entry.isUnlocked {                 LockedWidgetView()             } else if let event = entry.event {                 SmallWidgetEventView(event: event)             } else {                 NoDataWidgetView()             } ... func applicationSignificantTimeChange(_ application: UIApplication) { &#9;&#9;if #available(iOS 14.0, *) { &#9;&#9;&#9;&#9;WidgetCenter.shared.reloadAllTimelines() &#9;&#9;} ... However, 2 unexpected things happen: the view is refreshed intraday (not only at midnight i.e. at significant time change) sometimes the LockedWidgetView is displayed. Especially the latter is problematic, because it gives false information to a user that has already made the in-app purchase. How can I achieve my goal of only displaying info when the user has made the in-app purchase? Thanks in advance. P.S. Although it would not have my preference, I would also find it acceptable if the widget is only shown as option to add once the purchase is made. In other words, I was considering changing the Widget itself: struct MyWidget: Widget {     private var supportedFamilies: [WidgetFamily] = isUnlocked() ? [.systemSmall, .systemMedium] : [] but I believe I cannot re-initialise the widget from the app when the user makes the in-app purchase, because the only refresh option that I have is WidgetCenter.shared.reloadAllTimelines()

Hello I recently discovered that Denmark's (and soon the rest of the Nordic countries) biggest mobile payment service - MobilePay - is seemingly getting away with selling digital products in their app without using IAP. I am confused how this is possible, as I spent a lot of time making sure I understand the rules -- and I'm quite confident I do, so the only conclusion I can reach from this is that this is a violation that has not been discovered. If it isn't, I would like an explanation. So, what am I talking about? First; MobilePay is an app that lets you send money to whoever, essentially a Danish version of CashApp. You attach a credit card, and you can transfer funds using people's phone numbers. Nothing about this is problematic. There are some fees involved, which is also fine. But. You can select to "wrap your money in digital wrapping paper", which can be unwrapped by the recipient to reveal the amount you transferred. This is, no matter how you spin it, a digital product. It adds about 1 USD to the transferred amount, but that amount goes directly to MobilePay, not to the recipient - and isn't a transaction fee. To me that sounds exactly like the kind of payment that is absolutely mandatory to process via IAP - so how are they not? How does it pass app review? Is there something I'm missing? As someone who has been forced to use IAP for a service I would much rather not share the revenue of with Apple, I find this frustrating, and I'd prefer that everyone was subject to the same rules, especially when it comes to big corporate players like the developers of this app. You can read about the conditions of buying digital wrapping paper here: https://mobilepay.dk/app/legal/trading-conditions-da-dk - this page is in Danish but should be easily translatable. A theory I had is that maybe this wrapping paper feature is just not available to the test user they provided to Apple, as it is only sold to customers in Denmark and Greenland. But that's almost worse than an oversight, because in that case, they deliberately hid it from app reviewers. I have attached some photos of how it looks when you select the product in the app and how it just adds the cost on top of the amount you chose to transfer. I just chose a sample transfer of 1 DKK for the amount itself, and the 7 DKK for the "paper" is then added on top. It's not a lot, but given the size of the app's userbase (over 4.5 million according to themselves), we're likely talking a significant chunk of change they're essentially (if you're being cynical) stealing from Apple. What gives? For reference, the app in question is this one: https://apps.apple.com/dk/app/mobilepay/id624499138?l=da (currently ranked 4th in Finance in Denmark)

In my understanding, with the latest court ruling in the US, iOS apps may decide to support web-based payments for subscriptions and in-app purchases. However, are we allowed to exclusively support web-based payments and not implement StoreKit at all?

As of today we seem to continuously get back 21 of the product IDs we have defined when the shop initializes. This is causing what looks like intermittent bug behavior in our shop. The IDs sent each time are random (not always the same 21). So sometimes they match shop offers and the packs look right and can be bought and sometimes the ones our current shop offers need are not sent and so the offers in game look wrong and error when you try to buy. Is anyone else seeing this new behavior of not getting down all their product IDs successfully?

There is an issue with StoreKit. The line let products = try await StoreKit.Product.products(for: ids) doesn't always work correctly. Sometimes it returns an array with the correct data, and sometimes it returns an empty array. I'm passing the correct ids to products(for:). This problem only occurs when using the sandbox environment (in TestFlight builds). In the App Store version, everything works fine. StoreKit configuration is none. All IAPs are approved. Everything was working fine before this. The problem was discovered on May 1, 2025.

The sample code provided in https://developer.apple.com/wwdc21/10114 doesn't appear to call finish() on unverified transactions, and I haven't been able to find any documentation regarding what to do with unfinished transactions. However, Apple has always emphasized the importance of finishing transactions, and since a transaction object is provided even with the unverified state, I'd love some guidance!

I'm using TestFlight to test an app with payment/subscription functionality. I created sandbox accounts in AppStore Connect accordingly to be able to test the subscriptions. I'm logged in with the sandbox account. When I try to subscribe in the App the wrong account (this is my actual real AppleID) is used for the subscription although it is recognized that this is just a sandbox subscription. I tried: logging off/on into the sandbox account creating a totally new sandbox account trying to trigger the payment with no logged in sandbox account The result is always: in the payment popup it is stated that the purchase account will be my original AppleID and not a sandbox account. How can I switch the accounts? Is this a bug at Apple's side somehow?

I've recently published an app, and while developing it, I could always get consistent entitlements from Transaction.currentEntitlements. But now I see some inconsistent behaviour for a subscribed device in the AppStore version. It looks like sometimes the entitlements do not emit value for the subscriptions. It usually happens on the first couple tries when the device goes offline, or on the first couple tries when the device goes online. But it also happens randomly at other times as well. Can there be a problem with Transaction.currentEntitlements when the connectivity was just changed? Of course my implementation may also be broken. I will give you the details of my implementation below. I have a SubscriptionManager that is observable (irrelevant parts of the entity is omitted): final class SubscriptionManager: NSObject, ObservableObject { private let productIds = ["yearly", "monthly"] private(set) var purchasedProductIDs = Set<String>() var hasUnlockedPro: Bool { return !self.purchasedProductIDs.isEmpty } @MainActor func updatePurchasedProducts() async { var purchasedProductIDs = Set<String>() for await result in Transaction.currentEntitlements { guard case .verified(let transaction) = result else { continue } if transaction.revocationDate == nil { purchasedProductIDs.insert(transaction.productID) } else { purchasedProductIDs.remove(transaction.productID) } } // only update if changed to avoid unnecessary published triggers if purchasedProductIDs != self.purchasedProductIDs { self.purchasedProductIDs = purchasedProductIDs } } } And I call the updatePurchasedProducts() when the app first launches in AppDelegate, before returning true on didFinishLaunchingWithOptions as: Task(priority: .high) { await DependencyContainer.shared.subscriptionManager.updatePurchasedProducts() } You may be wondering maybe the request is not finished yet and I fail to refresh my UI, but it is not the case. Because later on, every time I do something related to a subscribed content, I check the hasUnlockedPro computed property of the subscription manager, which still returns false, meaning the purchasedProductIDs is empty. You may also be curious about the dependency container approach, but I ensured by testing multiple times that there is only one instance of the SubscriptionManager at all times in the app. Which makes me think maybe there is something wrong with Transaction.currentEntitlements I would appreciate any help regarding this problem, or would like to know if anyone else experienced similar problems.

We’ve recently encountered an increased rate of purchase errors StoreKit.InvalidRequestError error 1 (https://developer.apple.com/documentation/storekit/invalidrequesterror) specifically on iOS 18.4. We suspect this might be related to the new Advanced Commerce API introduced by Apple, although we haven’t made any changes related to this API in our app. Have you experienced similar issues since the release of iOS 18.4 or when integrating the Advanced Commerce API? Any insights or suggestions would be greatly appreciated. Thanks!

Hello, I’ve uploaded a new build of my macOS app with the first two in-app purchases, but it was rejected under 2.1.0 Performance: App Completeness. After further investigation, it seems that the Apple review team is unable to fetch products. The following code: private let productIDs = ["co.app.freetrial", "co.app.full"] self.products = try await Product.products(for: productIDs) is returning an empty array. (In the TestFlight build, it correctly returns the products.) For me, everything works as expected via Xcode and on a fresh machine using TestFlight. Here’s what I’ve tried so far: The in-app purchases were added to the binary with the first build. I confirmed that each in-app purchase is free of any yellow or red warning messages. Downloaded the app from TestFlight and confirmed that all in-app purchases are available. Updated the in-app purchase price in App Store Connect and verified that the new price is reflected in the app (to rule out any ID mismatches). Reviewed all agreements to ensure no missing signatures. (A few sources online suggested that this could potentially cause issues with in-app purchases for the review team.) I created a new build using a 3rd-party certificate and a provision profile. (Older builds - before adding in-app purchases - were signed with a development certificate and no provision profile, yet they still made it to the App Store. I’m not sure how that was possible or if it contributed to this issue.). Despite these steps, the app continues to be rejected for the same reason. I’m struggling to understand how products are successfully fetched for testers via TestFlight while the review team repeatedly sees zero products. Any guidance on how to resolve this would be greatly appreciated. Thank you

https://developer.apple.com/documentation/appstoreservernotifications/app-store-server-notifications-changelog#June-10-2024 ONE_TIME_CHARGE notify type running in a sandbox environment for almost a year, the feature is not yet available for production environment. The notification is already available in Google subscriptions. Our services often miss orders because of the absence of this notification. Can you give us an approximate time range?

Hello, I am encountering an issue where I receive an App Store Server Notification V2 upon the purchase of a consumable item. I have configured the App Store Server Notification V2 endpoint to handle notifications related to subscription products. However, I did not expect to receive notifications for consumable purchases. The notification includes the following signedPayload decoded into the ResponseBodyV2DecodedPayload object with the following values: notificationUUID: 3cd6410b-0c89-4247-aba5-20710e79895e notificationType: null subtype: null The transaction information decoded from the ResponseBodyV2DecodedPayload object is as follows: transactionId: 2000000633622618 webOrderLineItemId: null productId: heart_2 To debug, I called the Get Notification History API of the App Store Server API, and the mentioned notification for the consumable product purchase is not included in the history. Only notifications related to subscription product purchases are retrieved. According to the notification type documentation, there is no explanation for cases where both notificationType and subtype are null, nor is there any mention of receiving notifications for consumable purchases. Therefore, I am uncertain how to interpret and handle this notification. Could you please provide an explanation or guidance on this issue? Thank you. References: https://developer.apple.com/forums/thread/737592 https://developer.apple.com/documentation/appstoreservernotifications/notificationtype