Hello, We're a game studio. Our app has already been transferred from Team A to Team B, and no build has been released from Team B yet. We're now deciding how to handle guest accounts in the first update from B, and we'd like to confirm several platform behaviours before we commit to a plan. Current state The app is now owned by Team B. The build currently on the App Store was published while the app was still under Team A, and is the only build users have. No build has been uploaded or released from Team B — including TestFlight. The app signs users in either with a bound credential (phone number or third-party sign-in) or as a guest. A guest account has no recoverable credential: no email, no phone number, no third-party identifier. The only handle tying the user to their progress is a token stored locally on the device. That guest token is stored in the keychain under a plain keychain access group declared in the Xcode project: $(AppIdentifierPrefix)com.example.game.shared. It is not an App Group, and not an AGI keychain access group. The problem From "Overview of app transfer" we understand that keychain sharing "continues to work only until the app is updated", and that after the first update from B the token in the A-prefixed group will no longer be readable. For a user with a bound credential that's a single re-login. For a guest user it means the account becomes unreachable — there is nothing to re-login with. Their progress, purchases and inventory would be orphaned, and we have no way to identify them from the new build. So the first update from B is a one-way decision point for us, and we'd like to get it right. What we're evaluating Option 1 — Ship from B and carry the guest identity in the app container. If the app's sandbox container (Documents / Library / UserDefaults) survives an in-place cross-team update, we could read a guest identifier written there by the old build and exchange it server-side for a fresh B-prefixed token. No further transfer needed. This only helps users who update in place — anyone who deletes and reinstalls loses the container. Option 2 — Transfer back to A, ship a migration build, then transfer to B again. Have Team A publish a build that moves the token into an AGI keychain access group for a dedicated App Group ID, wait until most users have run it, then transfer the app back to B and transfer the App Group ID, as described in "App ID Prefix Change and Keychain Access". Option 3 — Dual-write now and accept loss for users who don't update in time. Our questions Q1 — App container across a cross-team update. Does an app's sandbox container (including UserDefaults, Library and Documents) persist when a user updates in place to a build signed by the recipient team? We can't find this stated anywhere, and Option 1 depends entirely on the answer. Q2 — identifierForVendor. Does identifierForVendor stay stable across an app transfer, i.e. when the signing team changes? We'd like to use it as a secondary anchor for guest accounts, but we're unwilling to rely on undocumented behaviour, and we can't find documentation either way. Q3 — Transferring back. Is transferring an app back to its original team supported? Are there restrictions we should know about — a cooldown, a cap on the number of transfers, or a requirement that the app meet the transfer criteria again? Specifically, if Team B has uploaded a build to App Store Connect but never released it (no App Store release, no TestFlight distribution), does that affect the app's eligibility to be transferred back? And when the app returns to A, is the App ID Prefix guaranteed to revert to the value it had originally, or can a team end up with a different prefix than it had before (for example on legacy accounts that hold more than one prefix)? Q4 — Keychain-only state. Given that the original build never declared an App Group, is there any supported way to recover items from an A-prefixed keychain access group once the app is owned by B and the next build is signed by B? We assume not, and that Option 2 is the only supported path — please confirm. Q5 — Recommended practice. Is there a recommended approach for migrating accounts that have no recoverable credential? We'd rather follow an established pattern than invent one. A separate question: certificate and profile expiry on Team A's side Team A's distribution certificate and provisioning profile will expire at some point, while the app stays under B without an update. We'd like to confirm that this has no effect on sign-in and no effect on payments for the version currently installed from the App Store. Reasoning that applies to both. The App Store re-signs the app during distribution, and the delivered build contains no embedded provisioning profile (TN3125), so neither A's certificate nor A's profile exists on the device. "Certificates overview" also states that an expired App Store distribution certificate does not affect existing App Store apps, and only prevents uploading new builds signed with it — which the transferor can no longer do in any case. Sign-in. Tokens — guest and bound alike — live in the keychain under the A-prefixed access group. Our reading is that certificate expiry has no bearing on keychain access at all, because the access check compares the group string in the binary's entitlements against the item's kSecAttrAccessGroup. The signing certificate isn't an input to that comparison. Is that correct? Payments. Our reading is that payments are unaffected on both sides: StoreKit transactions (purchase, renewal, refund) are handled by Apple's servers and don't depend on the app's signing certificate or provisioning profile; our server-side receipt validation relies on the app-specific shared secret — a 32-character hexadecimal string with no relationship to any certificate — so verifyReceipt and the App Store Server API keep working. Is that correct, or does something break here? One consequence we do care about. For Option 2 we'd need Team A to sign and publish that migration build. We assume A must therefore issue a new, valid certificate and profile before it can ship again — that is, expiry doesn't affect the installed app, but it does affect A's ability to publish anything further. Is that right? We also assume the App Store Server Notifications URLs configured for the app are unchanged by the transfer. Could you confirm that as well? Thanks!