Keychain access after an A → B → A round-trip transfer: can a new build signed by Team A still read the items the original Team A build wrote?

Hello,

We have an app that was transferred from Team A to Team B. We are now considering transferring it back to Team A, and we would like to confirm what happens to the keychain items that the original Team A build wrote, before we commit to that plan.

• The app is currently owned by Team B.
• No build has ever been released or distributed from Team B — no App Store release and no TestFlight distribution. Every user on the App Store is still running the build that Team A signed.
• The app stores a login token 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.
• Some of our users are guest accounts. A guest account has no recoverable credential — no email, no phone number, no third-party identifier — so the token in the keychain is the only thing tying them to their progress.
• The plan would be: transfer the app back to Team A, then have Team A create a new distribution certificate and a new provisioning profile, and ship a new build.

We read the documentation as follows.

1. An access group is "a logical collection of apps tagged with a particular group name string", and each keychain item is "always part of exactly one group".
2. The group name is the string declared in the entitlements with the App ID Prefix prepended — "Xcode automatically prefixes keychain groups with your team ID" — and that prefix is resolved at build time from the provisioning profile.
3. Access is decided by comparing the group string in the binary's entitlements against the item's kSecAttrAccessGroup. If the group is not one the app belongs to, a write returns errSecMissingEntitlement and a read returns errSecItemNotFound.
4. A provisioning profile's DeveloperCertificates property lists "the certificates of each developer who can sign code covered by the profile" (TN3125). So the certificate decides who may sign, not which access group the app belongs to.
5. When the app is transferred back to Team A, its App ID returns to Team A, and therefore the App ID Prefix — and with it the group name — should be the same string as before.

If all five hold, a new build signed by Team A with a newly issued certificate should still be able to read the items written by the original Team A build, and our guest users would not be affected at all.

Q1 — Does the App ID Prefix revert?
When an app is transferred back to its original team, is the App ID Prefix guaranteed to return to the value it had before? Or can a team end up with a different prefix than it had originally,This is the one step in our reasoning that we have not been able to find stated anywhere.

Q2 — Does a newly issued certificate or profile have any bearing?
Team A would create a new distribution certificate and a new provisioning profile rather than reuse the previous ones. Does that affect keychain access in any way? Our reading is that it does not, because the access check compares group strings and the signing certificate is not an input to that comparison. Could you confirm?

Q3 — Are the original items still present and readable?
Assuming no Team B–signed build ever reached any device, are the items written by the original Team A build still on the device and readable by a Team A–signed build after the round trip? "Overview of app transfer" says keychain sharing "continues to work only until the app is updated" — we read that as meaning the trigger is a build from the new team reaching the device, not the transfer itself.

Q4 — 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 or distributed it, does that affect the app's eligibility to be transferred back?

Q5 — Guest accounts.
Because our guest users have no recoverable credential, "just ask the user to sign in again" is not available to them. Is there a recommended approach for this case that we should follow?

Thanks!