Hello, Our app supports family sharing skus, we successfully ran tests on family sharing features in sandbox, we noticed the feature does not work on live builds. The family member (child account) do see the subscription as "Shared with you". We attempted to restore multiple time and there is nothing to restore.

Im building a small iphone app with StoreKit and currently testing it in testflight right on my mac, not on iphone. StoreKit part almost exactly copied from SKDemo from one of the Apple's WWDC. For some users and for myself Transaction.currentEntitlements always returns .unverified results. I double-checked Apple Connect settings, i checked my internet connection and everything is fine. Is there some pitfalls for testflight on mac? How can I find out what is causing this problem?

I am experiencing an issue with my iOS app where StoreKit 2 in-app subscriptions are not appearing when using Product.products(for:). I have done all the necessary configurations, but the products still return an empty array ([]). Here are the details of my setup: • App ID / Bundle ID: com.tstore.vocabely • Product IDs: • com.tstore.vocabely.base • com.tstore.vocabely.pro • com.tstore.vocabely.ultimate • Paid Apps Agreement: Active • IAP Status in App Store Connect: Ready to Submit / Approved • Testing Environment: • Device: iPhone (real device) • iOS Version: [insert your iOS version] • Xcode Version: [insert your Xcode version] • Sandbox Tester Account used • Code Snippet: Using Product.products(for: productIDs) in StoreKitManager to fetch products I have verified: • Product IDs match exactly with App Store Connect • Paid Apps Agreement is Active • Using a real device, not a simulator • Sandbox account is properly signed in Despite all of this, fetchProducts() still returns an empty array. Could you please assist me in troubleshooting why my subscriptions are not appearing in the Sandbox environment? Thank you for your support.

关于通过Advanced commerce API 创建SKU，有几个问题： 1、通过Advanced commerce API创建的自动续费订阅的SKU是否支持推介优惠、促销优惠？如果可以，是在苹果connect设置吗？ 2、已订阅通过connect创建的SKU的用户，是否可以重复订阅通过Advanced commerce API创建的SKU？还是要通过Advanced commerce API变更订阅？ 3、Advanced commerce API创建的SKU ,用户订阅成功后，续费的扣款是否仍由苹果发起？还是由开发者自行发起？

Hi everyone, After my app was initially rejected, all my IAPs now show the status “Developer Action Needed.” There’s nothing I need to change on them — they were just returned because it was the first submission and the app itself was rejected. Do I need to do anything with the IAPs before I resubmit, or will they still be attached and reviewed automatically with the next binary? I’ve seen conflicting answers, so I’d like to confirm the correct process. Thanks, Cris

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!

One of our customers subscribed to a monthly plan on August 16 but the server-to-server notification seems to have been sent on August 18. What could be the reasons for such a delay between the purchase and the server-to-server notification which are usually sent right after the purchase? The receipt sent along with the notification seems to confirm that the receipt has only been created 2 days after the purchase. Here is an extract: { "environment": "Production", "receipt": { "receipt_type": "Production", "bundle_id": "fr.gaumontvideo.gaumontclassique", "application_version": "613", "receipt_creation_date": "2025-08-18 13:00:16 Etc/GMT", "receipt_creation_date_ms": "1755522016000", "receipt_creation_date_pst": "2025-08-18 06:00:16 America/Los_Angeles", "request_date": "2025-08-25 13:08:27 Etc/GMT", "request_date_ms": "1756127307346", "request_date_pst": "2025-08-25 06:08:27 America/Los_Angeles", "original_purchase_date": "2022-05-11 06:14:37 Etc/GMT", "original_purchase_date_ms": "1652249677000", "original_purchase_date_pst": "2022-05-10 23:14:37 America/Los_Angeles", "original_application_version": "265", "in_app": [ { "quantity": "1", "product_id": "fr.gaumontvideo.gaumontclassique.subscription.monthly.apple", "transaction_id": "270002386706194", "original_transaction_id": "270002386706194", "purchase_date": "2025-08-16 08:02:06 Etc/GMT", "purchase_date_ms": "1755331326000", "purchase_date_pst": "2025-08-16 01:02:06 America/Los_Angeles", "original_purchase_date": "2025-08-16 08:02:08 Etc/GMT", "original_purchase_date_ms": "1755331328000", "original_purchase_date_pst": "2025-08-16 01:02:08 America/Los_Angeles", "expires_date": "2025-09-16 08:02:06 Etc/GMT", "expires_date_ms": "1758009726000", "expires_date_pst": "2025-09-16 01:02:06 America/Los_Angeles" } }

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.

When submitting an app for review, will any unreviewed auto-renewing subscriptions within the app be reviewed simultaneously? I own an app that has passed review and offers an auto-renewing subscription A within the app that has also passed review. To test a new service, I plan to create a new auto-renewing subscription B, which I do not intend to submit for review. After creating Subscription B, I plan to submit the app for review as part of an app update. In that case, is there a possibility that Subscription B will also be reviewed?

I'm developing an app and I think I've implemented what I need to in the swift code. However, when I click the Purchase button in my app, I see "Cannot connect to App Store" when the App Store app opens. Attached are images showing how I've configured the Sandbox user. What am I doing wrong? I expect to be able to do a fake purchase to test subscription activation in the app, but it doesn't work.

Hello all, We developed an iOS app which we started advertising now. In our iOS app we already implemented the updatePostbackConversionValue(_:completionHandler:) to send in-app events in increasing numbers (first open -> 1, lead ->2, conversion -> 3). From our understanding this should be enough for alle ad networks (Apple Ads, Google Ads, Meta Ads, Microsoft Ads and Reddit Ads) to receive those numbers - at least they receive the app installs from the SKAN already. Is this correct or do we miss something here in the integration? We currently really struggle to assure that everything is working and we do not see any conversions coming in - even though two weeks of advertising have passed already. I look forward for any feedback or discussion and I am also happy to share more details if needed. Best regards, Manuel

I tried deleting the configuration file, but I ended up with an alert asking me to sign in with my sandbox ID. I did, and it returned an error: "Request Canceled". It is as if the purchase function doesn't update the currentEntitlements. This is my purchase function. Am I doing something wrong? func purchase(_ product: Product) async throws { let result = try await product.purchase() switch result { case .success(let verificationResult): switch verificationResult { case .verified(let transaction): // Successful purchase - deliver content await updatePurchasedProducts() await transaction.finish() // Go back to the map integratePlanAhead() case .unverified(_, let error): // Purchase failed verification throw error } case .userCancelled: // User cancelled the purchase break case .pending: // Purchase is pending (e.g., parental approval needed) break @unknown default: break } } It looks like purchases are never updated for my sandbox user... Thanks for any help :)

hi, when i test an in app purchase with my sandbox acount i get: "ask permission. a request to buy ** will be sent to your parent or gardian (environment: sandbox)" When i made the sandbox account, i didnt see any option to set my age. What am i missing here, I dont seem to be able to fully test in app purchases since my sandbox accounts always defualt to this family sharing thing? Thanks

There is a warning message displays in my itune connect's In App Purchase page but there is nothing highlighted in the table. This is very stange. Is there anyone having the same problem? Or can anyone help?

I’m implementing subscriptions and running tests, and I noticed a behavior I’d like to confirm. Plans in the app Basic — Monthly Basic — Annual Premium — Monthly Premium — Annual Test environment Sandbox (where ~1 day ≈ under 1 minute of real time) steps Start Basic (Monthly) using an introductory offer (free trial). Create a crossgrade to Basic (Annual) (scheduled/queued). After receiving a RENEWAL App Store Server Notification indicating the plan will move from trial to paid Basic (Annual), but before the trial actually expires, upgrade the user to Premium (Monthly). Observed behavior (Sandbox) & questions Even though there is still up to ~1 day of trial remaining (≈ under 1 minute in Sandbox), upgrading to Premium (Monthly) immediately ends the trial and activates the paid Premium plan right away. Will this same behavior occur in Production? If yes, is this the expected/acceptable behavior when upgrading during an active trial after a pending crossgrade? Note: If we upgrade to Premium before the RENEWAL notification arrives, the remaining trial time is carried over in our tests. In this flow, we see a RENEWAL notification for Basic (Annual) (moving from trial → paid), but then the user immediately upgrades to Premium (Monthly) and the trial ends at that moment. In Production, would the charge for Basic (Annual) be refunded automatically since the user effectively switches to Premium immediately (and Basic Annual does not remain active)? In Sandbox there’s no real charge, but I want to ensure we won’t see a situation in Production where Basic (Annual) is billed and not refunded, even though the subscription effectively moved to Premium right away. Thanks in advance!

Dear Apple Developer Support Team, I hope you are doing well. We are reaching out to request clarification and guidance regarding the In-App Purchase (IAP) requirements for our upcoming iOS application. Our app offers paid access to digital video content. Each video has a dynamic price determined by our backend based on multiple factors (such as duration, category, and promotions). Additionally, users are allowed to select and purchase multiple videos at the same time, which results in a combined total price that varies per transaction. Challenges we face with IAP on iOS Dynamic pricing: Apple requires IAP products to have static pricing defined in App Store Connect. Our video prices change frequently and cannot be represented by fixed IAP product SKUs. Multiple-item purchases: iOS does not support a single purchase that includes multiple different IAP products. Processing many separate IAP transactions in sequence results in a poor user experience and is likely to cause failures. Product creation limitations: Since our catalog contains many videos with frequently changing prices, it is not feasible to create individual IAP products per video. Given these restrictions, we are unclear how to remain compliant while still providing a functional purchase flow for our users. Question In this scenario, where: video prices are dynamic, users may purchase multiple videos together, and IAP does not support multi-item purchases or dynamic pricing, are we allowed to use Stripe or another external payment provider to handle these purchases? If not, we would appreciate Apple’s guidance on what the recommended and compliant approach would be for apps that must price digital content dynamically and allow bulk purchasing. We want to ensure full compliance with App Store Review Guidelines and would like confirmation on the correct implementation strategy before proceeding. Thank you for your time, and we look forward to your clarification. Kind regards, Muhammad Adnan Koderlabs

When trying to login with sandbox account in my simulator, nothing happens, it just become inactive for few seconds and then it become active again prompting that I can login, again and again.

I am using Store Kit 2 to implement In App Purchases for my app. I need to maintain a pending state in the UI for all my pending purchases. Is there a way to get a list of all pending purchases? If not, is there a way to know if my pending purchase was cancelled?

In my app’s IAP products, before enabling free trials, the App Store Server Notifications V2 callbacks all returned the correct notificationType. For auto-renewable subscriptions, when they were about to expire, the notificationType was either DID_RENEW or EXPIRED. A small number of cases(DID_FAIL_TO_RENEW) failed to renew due to billing issues, which was expected. However, after I enabled a 7-day free trial for the auto-renewable products, I noticed that in the App Store Server Notifications V2 callbacks, almost all users (except those who manually turned off auto-renewal) received notificationType = DID_FAIL_TO_RENEW. According to the documentation, DID_FAIL_TO_RENEW indicates a billing issue renewal failure, but in this case it seems like all renewals are being marked as failed. I’ve observed that for users who cancel during the free trial, the callbacks look normal: first a DID_CHANGE_RENEWAL_STATUS notification, then an EXPIRED notification when the trial ends. That flow seems correct. However, for users who do not cancel the trial, almost all callbacks show DID_FAIL_TO_RENEW. Does this mean every remaining user has a billing issue? I also noticed on the Developer Forums that other developers have reported the same issue — receiving a large number of DID_FAIL_TO_RENEW notifications specifically when free trials convert to paid subscriptions: https://developer.apple.com/forums/search?q=DID_FAIL_TO_RENEW Could someone clarify: under normal circumstances, when a free trial transitions to a paid subscription and fails, should the App Store Server Notifications V2 notificationType indeed be DID_FAIL_TO_RENEW, or should it be a different type(e.g. EXPIRED)? And is it expected behavior that almost all free trial conversions return DID_FAIL_TO_RENEW?

The same store kit configuration file works in iOS and iPadOS, but not in macOS for the same multi platform application project with a single scheme. Here’s a more detailed write up with the sample code and screenshots. When the simple app is run on https://www.reddit.com/r/SwiftUI/s/KJsYcggWOa EDIT: I’m using Xcode 16.4