Hello, We are preparing to transfer an App Store app from one Apple Developer account/team to another. Our iOS app uses Sign in with Apple. However, in our legacy implementation, we did not store the Apple user subject identifier (sub) for many existing Apple login users. Our service primarily matched users by email. After reviewing Apple’s app transfer and Sign in with Apple migration documentation, we understood that we should generate a transfer identifier for each Sign in with Apple user before transferring the app. We have now started collecting and storing the sub value, but many legacy Apple login users still do not have their original sub value stored in our database. We are concerned about two main cases: Legacy users whose original Apple sub value was never stored For these users, we may not be able to generate the required transfer identifier before the app transfer. If the user uses Private Relay, we are also concerned that the email address we receive after the transfer may not match the email address we previously stored. In that case, our backend may not be able to match the post-transfer Sign in with Apple login to the user’s existing account, and the user may be treated as a new account. Users whose sub value is stored, but who do not sign in during the migration period For some users, we do have the Apple sub value and may be able to generate the transfer identifier before the app transfer. However, we are not sure what happens if those users do not sign in during the available Sign in with Apple migration period after the app transfer. If they sign in only after that period has ended, will the post-transfer Sign in with Apple user still be reliably mapped to the original pre-transfer user? The scenario we are worried about is: A user originally signed in with Apple before the app transfer. The app is transferred to another Apple Developer account/team. The user does not sign in during the Sign in with Apple migration period. After the migration period has ended, the same user signs in with Apple again. Our backend receives a new Apple user identifier and/or a different Private Relay email address. Our backend cannot correlate that login with the user’s original service account. The user may be treated as a new user and may lose access to their existing profile, activity history, chats, purchases, or other account data. Could someone confirm the expected behavior? Questions: If we have a legacy sub value and generate the transfer identifier before the app transfer, can the user still be mapped to the original account if they do not sign in during the Sign in with Apple migration period? After the migration period has ended, does Apple provide any identifier, token claim, API response, or other mechanism that allows us to correlate the post-transfer Sign in with Apple user with the pre-transfer user? For legacy users whose original sub value was never stored, is there any Apple-provided way to recover or map those users after the app transfer? Can a Private Relay email address change as part of or after an App Store app transfer? Should we avoid using email as a stable identifier for this migration? Should we delay the app transfer until we implement our own account recovery and account re-linking flow for all Sign in with Apple users? Environment: Platform: iOS Development environment: Xcode Runtime: iOS Framework: AuthenticationServices Feature: Sign in with Apple Context: App Store Connect app transfer between Apple Developer teams/accounts This issue does not appear to be specific to a particular iOS or Xcode version. We expect the development and runtime environments to be using the latest available versions of Xcode, macOS, and iOS at the time of submission. Any guidance on the correct migration behavior and the recommended implementation approach would be greatly appreciated.

Hello everyone, We are currently preparing for an App Transfer to a new Apple Developer account due to a corporate merger. We are trying to figure out the best way to handle Apple Sign-In user migration and would love to get some advice on our proposed fallback plan. 📌 Current Situation We need to transfer our app's ownership to a new corporate entity. The app heavily relies on Apple Sign-In. The Issue: We did not collect the transfer_sub values during our initial development phase. Although we started collecting them recently, we will not have them for all existing users by the time the transfer happens. 🚨 The Risk (The 60-Day Rule) Based on Apple's documentation, even if we provide the transfer_sub, users must log into the app within 60 days of the transfer to successfully migrate their accounts. This means that users who log in after 60 days, or those whose transfer_sub is missing, will fail the Apple migration process. They will be treated as "new users" and will lose access to their existing account data. 💡 Our Proposed Custom Recovery Flow Since we cannot rely entirely on Apple's automated migration, we are planning to build a custom internal account recovery process to prevent user drop-off: A user (who failed the migration or logged in after 60 days) attempts to use Apple Sign-In on the transferred app. Since the existing account isn't linked, Apple generates a new identifier (sub), and the user enters the new sign-up flow. During the sign-up process, we enforce a mandatory identity verification step (e.g., SMS phone number verification). We query our existing user database using this verified information. If a matching existing user is found: We interrupt the sign-up process and display a prompt: "An existing account was found. We will link your account." We then update our database by mapping the new Apple sub value to their existing account record, allowing them to log in seamlessly. ❓ My Questions App Review Risk: Could this manual mapping approach—overwriting the Apple sub on an existing account based on internal identity verification—violate any Apple guidelines or result in an App Store rejection? Shared Experiences: Has anyone dealt with missing transfer_sub values or the 60-day migration limit during an App Transfer? How did you mitigate user loss? Best Practices: Are there any alternative, safer, or more recommended workarounds for this scenario?

Hello everyone, I’m trying to better understand the expected behavior of Sign in with Apple after an app is transferred to another Apple Developer Team. Specifically, my question is about users who do not open or sign in to the app during the 60-day migration period after the app transfer. Here is the scenario we are concerned about: An existing user created an account using Sign in with Apple. The user is using a private relay email address. The app is transferred to another Apple Developer Team. The user does not sign in during the 60-day migration period. The user signs in again only after the 60-day period has ended. In this situation, is there any possibility that Apple may provide different user-related values compared to the values before the app transfer? For example, I am referring to values such as: sub private relay email address ID token claims any other API response value that may be used to identify the user The reason I’m asking is that if any of these values change after the transfer, our backend may not be able to match the user to the existing account in our database. In that case, the user could incorrectly be treated as a new user. My understanding is that the purpose of the Sign in with Apple migration process after an app transfer is to associate the user identifier from the original Team with the user identifier for the new Team. However, I would like to confirm what happens if the user was not processed during the 60-day migration period and signs in later. Do the values provided by Apple remain consistent in this case, or can they change after the migration period ends? If they can change, should we prepare our own account recovery or re-linking flow to handle these users? I would appreciate any clarification on Apple’s expected behavior and the recommended approach for this case. Thank you.

Hello everyone, I’m trying to better understand how to safely handle user entitlements around the exact renewal timing for auto-renewable subscriptions. In our app, when a user subscribes through the App Store, our backend retrieves the subscription status using the App Store Server API. We then use the subscription expiration date from Apple to set the user’s entitlement expiration time in our own database. For example, if Apple’s subscription expiration date is: June 24, 8:00 PM we also set the user’s app entitlement to expire at: June 24, 8:00 PM My question is about what happens around the exact renewal moment. From my understanding, Apple attempts to renew an auto-renewable subscription shortly before the subscription expires. However, I’m not fully clear on how precise this timing is in practice, especially from the perspective of a backend service that depends on updated subscription data from Apple. For example, suppose the user’s subscription is expected to renew at 8:00 PM. If the renewal transaction is completed immediately and the updated expiration date is available right away, there is no issue. However, if the renewal transaction or the updated subscription status is delayed by a few seconds or a few minutes due to server timing, network latency, App Store Server Notification delay, or any other processing delay, our backend may still only have the previous expiration date. In that case, our system could temporarily treat the user as expired even though the user expects their subscription to renew automatically. The scenario we are concerned about is: A user has an active auto-renewable subscription. Our backend stores the entitlement expiration time based on Apple’s current expiration date. The subscription reaches the stored expiration time. The renewal is expected around that same time. The updated renewal data has not yet reached our backend. The user temporarily loses access even though the subscription may have renewed or may be in the process of renewing. In this kind of situation, what is the recommended backend design? Should we apply a small internal grace buffer after the expiration time before removing access? For example: a few minutes 30 minutes 1 hour longer Or is it better to strictly expire the user’s entitlement at the exact expiration date provided by Apple and wait until the next verified renewal transaction is received? I understand that Apple has separate concepts such as billing retry and Billing Grace Period, but my question here is more about normal renewal timing and short delays in receiving updated subscription data. For developers who have designed subscription entitlement systems using the App Store Server API and App Store Server Notifications, how do you usually handle this edge case? Do you rely strictly on Apple’s expiration date, or do you keep a short backend-side buffer to avoid incorrectly interrupting access during renewal? Any guidance, best practices, or real-world implementation experience would be appreciated. Thank you.

Hello, We are currently testing subscription purchases in the Sandbox environment, and we are seeing an issue that we do not fully understand. When we attempt a single subscription purchase, multiple purchase signals or transaction events are sometimes delivered from Sandbox for what appears to be just one payment attempt. In some cases this happens twice, and in other cases we have seen it occur as many as five to seven times. The number is inconsistent each time, and we have not been able to identify any clear pattern. At this point, we are not sure whether this is a known instability or limitation of the Sandbox testing environment, or whether there may be something incorrect in our own implementation or configuration. Has anyone experienced similar behavior when testing auto-renewable subscriptions in Sandbox? If so, we would really appreciate any guidance on what to check. Thank you.

Hello, I have a question regarding how prorated refunds are reflected when a user upgrades a subscription. From my understanding, when a user upgrades to a higher-tier subscription, the remaining value of the current subscription is refunded as a prorated amount, typically represented as REFUND_PRORATED or PRORATED_CREDIT. However, when reviewing the available transaction history and refund-related data (including the App Store Server API and transaction history endpoints), I cannot find any field or record that clearly indicates: the actual prorated refund amount, or the credit applied when upgrading to another subscription In other words, while the concept of REFUND_PRORATED seems to exist conceptually, I cannot identify where the actual prorated value or credit applied to the upgrade is exposed in the transaction or refund history. My questions are: Is there any way to retrieve the actual prorated refund or credit amount when a user upgrades a subscription? Is this information available through the App Store Server API (e.g., Get Transaction History) or any other API endpoint? If not, is there any recommended method to determine how much of the previous subscription was credited toward the upgraded subscription? Any clarification would be greatly appreciated. Thank you for your help.

Hello, I am currently testing In-App Purchases for my app in the Sandbox environment. Our app has two types of products: Auto-renewable subscriptions Non-renewing subscriptions When testing auto-renewable subscriptions, I can see the subscription in the Sandbox account management screen, and I can perform actions such as: Viewing the active subscription Cancelling the subscription Upgrading or downgrading the subscription However, when testing non-renewing subscriptions, I cannot find the purchase history anywhere in the Sandbox account management screen. Because of this, I cannot verify whether the non-renewing subscription purchase was recorded correctly. My question is: Where can I check the purchase history for Non-Renewing Subscriptions in the Sandbox environment? Is there a specific place in: App Store Connect Sandbox account settings Or somewhere else where these purchases can be reviewed? Thank you in advance for your help.