General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

We operate a website-only service using Sign in with Apple. On iPhone Safari, the native authorization sheet displays a gray tile containing “N” beside our service name. We would like that tile to display our company logo. This concerns the service icon inside Apple’s native sheet, not the Sign in with Apple button on our website. Our Services ID is associated with an existing primary App ID enabled for Sign in with Apple. As of our latest account review on October 15, 2026, our team had no App Store Connect app record for this service. We have not found a separate logo upload field in the Services ID or primary App ID settings. Apple Developer Support directed us here for technical guidance. Could Apple clarify the currently supported approach? Can a website-only service configure this logo independently? If so, what exact setting or process, asset specifications, and eligibility requirements apply? If the icon must come from a native app, what is the earliest qualifying stage: an App Store Connect record, a processed build upload, TestFlight availability, App Review submission, approval, or public release? Does a build that is never publicly released qualify? What determines the gray letter tile when the company logo is unavailable? After a qualifying icon is added or changed, what propagation/cache time should we expect, and how can we verify or refresh it safely on a physical iPhone without revoking existing users’ authorizations? If there is currently no supported solution for a website-only service, could you confirm that limitation and any supported alternative? We need to retain the existing Services ID, primary App ID, and user associations. We reviewed the web configuration guide, WWDC22 session 10122, the historical Apple Staff replies in thread 123054, and Add an app icon. These describe the primary app icon, but do not clearly establish the supported website-only path or the precise eligibility stage for this native sheet. Thank you.

⚠ It'd be great to get some Apple Dev eyes on this -- it's one of my last remaining issues before submission. Regarding migrating Sign In with Apple users from team PLR8R96VKA to team Y76F338229... I'm following the migration steps at the bottom of https://developer.apple.com/documentation/signinwithapple, in the Transfers Across Teams section. My call to the /auth/usermigrationinfo endpoint results in a 400 error: invalid_request, but my request params all look correct: transfer_sub is set to the the value I got from a successful /auth/usermigrationinfo response. client_id is set to Services ID of the new team's Sign In with Apple service. client_secret was built from the new team's Key ID, Team ID and Services ID. I know it's content and format is valid because it worked fine when calling the /auth/token endpoint. I know my auth token is fine (the one I got from /auth/token)--I'm sure I'd see an auth error if it wasn't. Is there any way I can get more information about what is invalid about the request?

I am preparing a data-preserving, same-bundle-identifier update of my own development-signed iOS/iPadOS app (Target Keeper). Existing installations contain records that must be preserved. No update has been attempted, and no Keychain loss or entitlement incompatibility has been demonstrated. Environment: iOS/iPadOS 27.0.1 and Xcode 27.1. The original signed packages/archives for the installed older builds are no longer available. The proposed update has a valid Development signature and a profile covering the test devices. Its signed application identifier, Team identifier and Keychain groups have been inspected locally. The current and a retained later source snapshot use a bundle-derived service and a generic-password query without an explicit kSecAttrAccessGroup, with kSecAttrSynchronizable false and WhenUnlockedThisDeviceOnly accessibility. However, those source snapshots are not authenticated as the source used to produce the older installed binaries. I am therefore not assuming they prove the older effective groups or App ID prefix. I have read Sharing access to keychain items among a collection of apps, TN2415, QA1726, TN2311, and SecItem: Pitfalls and Best Practices: https://developer.apple.com/documentation/security/sharing-access-to-keychain-items-among-a-collection-of-apps https://developer.apple.com/library/archive/technotes/tn2415/_index.html https://developer.apple.com/library/archive/qa/qa1726/_index.html https://developer.apple.com/library/archive/technotes/tn2311/_index.html https://developer.apple.com/forums/thread/724013 These explain the access-group rules, first-group default and service/query distinctions. My remaining question is how to obtain authoritative evidence for the already-installed older app when its original signed package is missing. Is there a supported Xcode, Device Hub, devicectl or other Apple workflow to read/authenticate the effective application-identifier, Team and keychain-access-groups (including relevant App Groups) of an existing development installation without replacing it or extracting any Keychain values? If a local provisioning/install receipt can help, what establishes that it belongs to the installed binary rather than merely showing what a candidate profile permits? If no supported read-only method exists, what minimal controlled diagnostic does Apple recommend to qualify same-app Keychain continuity while preserving the original installation? Please distinguish methods requiring app launch/debugger attachment from genuinely read-only device-management inspection. Available app metadata and an exported app-data container have not supplied a signed entitlement list in the checks performed. Matching the candidate Team and bundle ID alone is not being treated as proof. A cross-bundle shipping migration is a separate problem and is not being attempted here. I am not asking to bypass code-signing or Keychain access controls, broaden access groups, uninstall the old app, or dump credentials. No passwords, certificates/private keys, device identifiers, backup files or application records are attached.

I'd like to prevent an attacker who uses a jailbroken iPhone or iPad from reading the contents of the Keychain of my app. Is there any point in using the Secure Enclave to generate a public-private key pair if an attacker with a jailbroken device can easily attach a debugger to my app, read from the Keychain of my app and also request decryption via the Secure Enclave while appearing to the Secure Enclave as my genuine app? Doesn't the whole security of the Keychain stand on the assumption that an attacker cannot attach a debugger to my app? Is there really no reliable way how to prevent someone from attaching a debugger to my app? I think that using PT_DENY_ATTACH is very easily bypassed by attackers. I don't mind if someone attaches a debugger to a re-signed version of my app, because such re-signed app would have a different Team ID, so the Secure Enclave would fail when attempting to use the key generated by my genuine app. I just want to prevent the situation when an attacker could read from the Keychain of my app and request the Secure Enclave to apply the private keys which were generated by my genuine app. Is the Keychain and the Secure Enclave essentially worthless on jailbroken devices if a determined attacker wants to take control of my app running on their jailbroken device?

in this weeks i received this error: ITMS-91055: Invalid API reason declaration - The PrivacyInfo.xcprivacy for the “VanigliaPro” file contains “App Functionality” as the value for a NSPrivacyAccessedAPITypeReasons key instead of a valid reason code for using an API in the NSPrivacyAccessedAPICategoryFileTimestamp category. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, values for NSPrivacyAccessedAPITypeReasons keys in your app’s privacy manifest must be valid reason codes for the corresponding API category. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. ITMS-91053: Missing API declaration - Your app’s code in the “xxxx” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryUserDefaults. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. ITMS-91053: Missing API declaration - Your app’s code in the “xxxx” file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryFileTimestamp. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app’s privacy manifest to provide approved reasons for these APIs used by your app’s code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api. any help for make correct privacy file?

Hello, I currently have an app that includes the "Sign in with Apple" feature, and I need to transfer this app to another app team. I have reviewed all official documentation but have not found the answer I need. My situation has some specificities, and I hope to receive assistance. The .p8 key created by the original developer team has been lost, and the app’s backend does not use a .p8 key for verification—instead, it verifies by obtaining Apple’s public key. However, according to the official documentation I reviewed, obtaining a transfer identifier during the app transfer process requires a client_secret generated from the original team’s .p8 key. This has left us facing a challenge, and we have two potential approaches to address this issue: Q1: During the transfer, is it possible to skip obtaining the transfer identifier and proceed directly with the app transfer, without performing any backend operations? Is this approach feasible? Q2: If the above approach is not feasible, should we create a new .p8 key in the original team’s account and use this new key for the transfer? If a new key is generated, do we need to re-release a new version of the app before initiating the transfer? If neither of the above approaches is feasible, are there better solutions to resolve our issue? I hope to receive a response. Thank you. TN3159: Migrating Sign in with Apple users for an app transfer | Apple Developer Documentation/ https://developer.apple.com/documentation/signinwithapple/transferring-your-apps-and-users-to-another-team

Hello Apple Developer Support, We need assistance with migrating Sign in with Apple users after completing an app transfer between two Apple Developer Teams. Current situation The app transfer has been completed and accepted by the recipient team. The recipient team has not yet released a new version on the App Store. Our production server, database, API domain, Bundle ID, and existing application user accounts remain unchanged. Before the transfer, we had never created a Sign in with Apple private key under the transferor team. Therefore, we do not have a previously generated .p8 private key for this app. This is not a case of a lost or revoked key. After the transfer, the app’s identifier is no longer listed under the transferor team’s Certificates, Identifiers & Profiles. When attempting to create a Sign in with Apple key under that team, we cannot select the transferred App ID as the primary App ID. Migration blocker According to Apple’s migration documentation, the transferor team must use its own client_secret to obtain a migration access token and generate a transfer_sub for each existing user. We are unsure how to obtain valid transferor-team credentials now that the App ID has moved to the recipient team and no private key was created before the transfer. Questions What is the supported procedure for obtaining valid transferor-team migration credentials in this situation? Can the transferor team create or configure a new Sign in with Apple private key for the transferred App ID after the transfer has been completed? If this cannot be done through the developer portal, can Apple Developer Support assist, or is there another supported migration method? Is transferring the app back to the original team, preparing the migration credentials and user transfer identifiers, and then transferring it again necessary in this situation? We would like to confirm whether this is required before making any further changes to the app’s ownership. We understand that the user migration process has a 60-day transfer window. We would appreciate guidance on resolving this credential issue promptly so that existing users can continue signing in to their original application accounts. Thank you for your assistance.

Hi everyone! We recently integrated "Sign in with Apple" into our application using standard social login flows. For the vast majority of our users, the integration works perfectly—we receive the user's email during sign-in and sign-up. However, we are noticing an edge case where a small subset of users are returning an ID token that is completely missing the email. We can't seem to reproduce this error ourselves during testing. Every time we test a sign-up or sign-in, the email payload is included exactly as expected. My Questions: Is there a specific reason why Apple would omit the email claim from the ID token? Any insights or guidance would be greatly appreciated. Thank you!

We are in the process of transferring our existing Apple account to a new account. We read the documentation and we realized that "Sign in with Apple" users needs to be migrated via API. This API seems to require "sub" which we are not currently storing in our systems. So we are planning to "collect subs" over a period before we can start transfer. I want to make sure we are collecting correct data so I am looking for confirmation from Apple engineers on this. Should we get "sub" from "user" property in ASAuthorizationAppleIDCredential or by decoding identityToken and get "sub" from the token? I think both are same but wanted to double check. Thank you!

We’re trying to determine whether an iOS authentication flow is safe for production when ASWebAuthenticationSession ultimately returns a reusable backend bearer token because the authentication provider does not support a native authorization-code/PKCE exchange. We have an iOS app built with React + Capacitor that uses @capgo/capacitor-inappbrowser for Apple/Google social login. The iOS flow uses ASWebAuthenticationSession. Our backend/auth provider is Base44. Base44 supports web OAuth, but they have confirmed they do not provide a supported native authorization-code / PKCE session exchange for externally wrapped Capacitor apps. Current flow: The app starts Base44 OAuth in ASWebAuthenticationSession. Base44 completes Apple or Google authentication. Base44 redirects to an HTTPS bridge page hosted on our Base44 app domain. The bridge receives the Base44 access token. The bridge redirects to our app callback URL scheme and includes that Base44 bearer token in the callback. The active ASWebAuthenticationSession receives the callback. The app validates the callback URL, verifies a one-time random state, sets the Base44 token and immediately calls auth.me() to confirm the authenticated account. We have already hardened the flow by: using a 256-bit random one-time state expiring pending login attempts after 10 minutes binding the state to the provider and locally stored return path validating callback scheme/host/path removing unsolicited/global deep-link authentication listeners using prefersEphemeralWebBrowserSession = true scrubbing token artifacts from the hosted bridge URL/local storage not trusting callback-supplied return paths verifying the Base44 account before marking native login complete We understand that the preferred native OAuth model is authorization code + PKCE, but the backend provider does not expose that capability for this integration. My question is: Given that ASWebAuthenticationSession delivers the authentication callback to the initiating session, is passing a reusable backend bearer token through that callback still considered unsuitable for a production iOS app? If it is unsuitable, is there any secure pattern available when the authentication provider does not support a native one-time code / PKCE exchange? We also need to preserve existing Apple/Google-linked Base44 accounts, user data and subscription entitlements, so replacing the authentication backend is not a simple migration. I would particularly appreciate guidance on whether: ASWebAuthenticationSession materially mitigates custom-scheme interception in this scenario changing to a Universal Link callback would materially improve the design if the bearer token still has to be transferred this architecture would be considered acceptable for an App Store production release

Hello, I am experiencing a persistent Sign in with Apple issue for our production web application, Sai＊aus. When Sign in with Apple is initiated using our registered custom-domain return URL, Apple returns: invalid_request Invalid web redirect url. Configuration: Services ID: com.saiaus.app.auth Production domain: sai-aus.com Registered Return URL: https://sai-aus.com/__/auth/handler We have verified that the redirect_uri sent in the authorization request exactly matches the registered Return URL. As a comparison test, using the Firebase-hosted handler URL https://sai-aus.firebaseapp.com/__/auth/handler with the same Services ID proceeds successfully to the Apple Account sign-in screen. The failure occurs with the registered custom-domain handler. We previously contacted Apple Developer Support regarding this issue: Support Case: 102958526964 Support Case: 102960544416 Feedback Assistant: FB24784951 We submitted the issue through Feedback Assistant as directed and also provided follow-up information, but the issue remains unresolved. We tested the production flow again on October 4, 2026, and the same invalid_request / Invalid web redirect url. error is still reproducible. Could an Apple engineer please review FB24784951 and advise why the registered custom-domain Return URL is being rejected while the Firebase-hosted Return URL works? Thank you.

We have an iOS app built with React + Capacitor that uses @capgo/capacitor-inappbrowser for Apple/Google social login. The iOS flow uses ASWebAuthenticationSession. Our backend/auth provider is Base44. Base44 supports web OAuth, but they have confirmed they do not provide a supported native authorization-code / PKCE session exchange for externally wrapped Capacitor apps. Current flow: The app starts Base44 OAuth in ASWebAuthenticationSession. Base44 completes Apple or Google authentication. Base44 redirects to an HTTPS bridge page hosted on our Base44 app domain. The bridge receives the Base44 access token. The bridge redirects to our app callback URL scheme and includes that Base44 bearer token in the callback. The active ASWebAuthenticationSession receives the callback. The app validates the callback URL, verifies a one-time random state, sets the Base44 token and immediately calls auth.me() to confirm the authenticated account. We have already hardened the flow by: using a 256-bit random one-time state expiring pending login attempts after 10 minutes binding the state to the provider and locally stored return path validating callback scheme/host/path removing unsolicited/global deep-link authentication listeners using prefersEphemeralWebBrowserSession = true scrubbing token artifacts from the hosted bridge URL/local storage not trusting callback-supplied return paths verifying the Base44 account before marking native login complete We understand that the preferred native OAuth model is authorization code + PKCE, but the backend provider does not expose that capability for this integration. My question is: Given that ASWebAuthenticationSession delivers the authentication callback to the initiating session, is passing a reusable backend bearer token through that callback still considered unsuitable for a production iOS app? If it is unsuitable, is there any secure pattern available when the authentication provider does not support a native one-time code / PKCE exchange? We also need to preserve existing Apple/Google-linked Base44 accounts, user data and subscription entitlements, so replacing the authentication backend is not a simple migration. I would particularly appreciate guidance on whether: ASWebAuthenticationSession materially mitigates custom-scheme interception in this scenario changing to a Universal Link callback would materially improve the design if the bearer token still has to be transferred this architecture would be considered acceptable for an App Store production release

The issue below affects every partner app embedding our SDK, so we'd appreciate DTS taking a deeper look. We're happy to open a code-level support request and provide screen recordings and a sysdiagnose. Details are in FB25326312. We ship an SMS filtering SDK (a Message Filter app extension) that partner apps embed. Password AutoFill is treating the SDK's messagefilter: associated domain as a credential domain for the host app, so unrelated saved logins appear on the partner app's sign-in screen. Configuration Apple validates Message Filter network deferral against the containing app (an unauthorized containing app gets ILMessageFilterError.Code.networkURLUnauthorized), so the entitlement must be declared on each host app, not the extension: messagefilter:messagefilter.example.comThe AASA file at messagefilter.example.com lists the host app IDs under messagefilter only. It has no webcredentials key. Network deferral works as expected. (The real domain is in FB25326312.) Observed behavior On the host app's sign-in screen, saved logins for the SDK provider's domain (example.com) are suggested in the QuickType bar and the QuickType suggestions list: No webcredentials: domain: only example.com logins are suggested. App's own webcredentials: domain added (valid AASA entry): the app's logins appear, but example.com logins are still suggested alongside them. Password managers Reproduces with Apple Passwords and third-party password managers (tested with 1Password, Dashlane, and Norton Password Manager): Credential providers appear to receive the messagefilter domain in the serviceIdentifiers array passed to prepareCredentialList(for:). Some use only the first identifier, others use all of them. QuickType suggestions come from iOS itself, so the unrelated credentials appear regardless of which password manager is used. Seen on iOS 26 and iOS 27 in a production partner app. Questions Is it intended that a messagefilter: domain contributes to Password AutoFill credential matching? Is there a supported way to exclude it from AutoFill without breaking Message Filter network deferral?

Hello Apple engineers and fellow developers, We plan to distribute our iOS / iPadOS games in Germany, France, Italy, Poland, Romania, and other EU countries. We would like to clarify whether the ATT changes introduced in iOS / iPadOS 27.2 require developers to adopt the new authorization API. We currently request tracking authorization using: ATTrackingManager.requestTrackingAuthorization(completionHandler:)We access IDFA only after the user grants ATT authorization. We reviewed the following official documentation: User Privacy and Data Use — ATT in the European UnionThis page states that, beginning with iOS / iPadOS 27.2, only the alternative ATT system prompt is available for apps distributed in the five countries listed above due to legal requirements. requestTrackingAuthorization(completionHandler:) — API DocumentationThe documentation states that the system presents a full-page sheet in these five countries when this existing API is called. Based on these documents, our understanding is that the existing API automatically presents the appropriate alternative ATT prompt in these countries. Therefore, developers do not need to migrate to the new API with the preferExpandedInterface and additionalInformationAction parameters solely to request authorization and access IDFA. Could you please clarify the following? Is this understanding correct? Can games distributed in these five countries continue using the existing API and access IDFA after the user grants authorization? Is adopting the new API also optional in other EU countries? If migration is mandatory, could you point us to the official requirement, applicable OS versions, and effective date? Our question concerns Apple’s ATT API integration and migration requirements, so we can plan the necessary SDK updates. Thank you for your help!

Sign in with Apple fails for every App ID in our team (K9UFUZF2XW), on every device and every Apple ID we have tried. The system sheet appears, the user authenticates successfully, the sheet then shows "Sign Up Not Completed", and no credential is returned. The failure happens after authentication — this is not a client-side rejection. I have spent several days isolating this and have ruled out everything on my side. Posting the full evidence in case an Apple engineer can look at the server-side state for our team, and in case it helps others hitting the same wall. WHAT THE FRAMEWORK ACTUALLY RETURNS The client library we use (expo-apple-authentication) discards the original NSError, so I patched its native layer to surface the raw error verbatim. This is what ASAuthorizationController hands back to didCompleteWithError, immediately after the user authenticated and the sheet displayed "Sign Up Not Completed": ASAuthorizationError .canceled (rawValue = 1001) domain = com.apple.AuthenticationServices.AuthorizationError code = 1001 desc = The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError, error 1001) userInfo: NSUnderlyingError: So the framework reports a user cancellation that never happened, with a completely empty userInfo and no underlying error. There is no diagnostic information on the client at all — I cannot debug this any further from my side, because the information does not exist there. Note: the same failure surfaces as a different error code depending on the client library version — .unknown (1000) with the older version, .canceled (1001) with the current one. The user-visible behaviour ("Sign Up Not Completed") is identical in both. So the error code is not a reliable signal here. WHAT I RULED OUT Not the App ID. I created a brand-new App ID (kz.auraai.ios) with Sign in with Apple enabled as a primary App ID, built a fresh binary, tested on the same device with the same Apple ID — identical failure. Two independent App IDs in the same team fail the same way. Not the entitlement. Verified inside the signed binary, not just in the portal: application-identifier = K9UFUZF2XW.kz.auraai.ios com.apple.developer.applesignin = ["Default"] I also tried the workaround suggested elsewhere on these forums (removing the entitlement while keeping the capability in the portal). That made it strictly worse: iOS then rejects the request instantly, without showing the sheet at all. Which confirms iOS reads the entitlement correctly, the sheet works, and the user authenticates — the failure is downstream of all of that. No stray or wildcard App IDs. A commonly cited cause is other App IDs in the team lacking the entitlement. I enumerated the whole team via the App Store Connect API: it contains exactly two App IDs, both with APPLE_ID_AUTH = PRIMARY_APP_CONSENT. No wildcard identifiers exist. Not the Apple ID, the device, or the iOS version. The same Apple ID, on the same device, with the same iOS, signs in successfully through another app belonging to a different team (Expo Go, host.exp.Exponent) — a valid identity token is returned. A second, unrelated Apple ID on another device fails in my app in exactly the same way. So this is not scoped to one account: it affects every user of the app. Agreements and membership are in good standing. Program License Agreement accepted 30 June 2026; Developer Agreement accepted 26 June 2026; membership active. Both distribution types fail. TestFlight and ad-hoc. WHAT IS LEFT After all of the above, the only variable that differs between the working case (a different team's app, same device, same Apple ID) and the failing case (my app) is the Apple Developer team itself. This exact signature — sheet renders fully, final server submit fails, "Sign Up Not Completed", delegate reports canceled with no userInfo, not reproducible in other apps on the same device — is documented in thread 122458 ("Error: Sign-Up Not Completed"). In that case it affected multiple developers, including Apple's own sample app, and was ultimately resolved by Apple on the server side, with a recurrence reported in June 2025. THE ASK Could someone from Apple check the server-side Sign in with Apple registration for team K9UFUZF2XW (App IDs kz.auraai.app and kz.auraai.ios)? I am not looking for configuration advice — I have exhausted the client side and there is nothing left to configure. This looks like the same server-side state that was fixed in the referenced cases. Feedback Assistant: FB23716661 (includes sysdiagnose with the Accounts/AuthKit profile, timestamp, and video of the failure). This is currently blocking us: because Sign in with Apple works for none of our users, guideline 4.8 prevents us from offering Google Sign-In, so we are shipping with email-only login. Happy to provide the binary, entitlements dump, or a fresh sysdiagnose on request.

Sign-In with Apple stopped returning the email property in my backend service for about 40% of new users who sign up for my app. My app requires email property on initial signup for accounts to work correctly. The changes I made leading up to this problem were: I updated my app's capabilities by enabling the com.apple.developer.authentication-services.account-creation-requires-phone-number I regenerated the provisioning profiles through the Apple developer portal I tried reverted the capability and regenerated the provisioning profiles but the email field is still missing. The response includes: iss, aud, exp, iat, sub, c_hash, auth_time, and nonce_supported properties but is missing the email, email_verified and is_private_email properties. For users who already have an account, I can use the sub property to locate their account. But the experience is now broken for a lot of new users and I fail to log them in. Does anyone know if I'm doing something incorrectly? Thanks so much for the help!

On macOS 27.0.1, SecItemCopyMatching returns -25293 (errSecAuthFailed) when a native app reads an existing login keychain item. We have verified that the app signature matches and that the user has added the app to the list of allowed applications. This occurs with user interaction disabled, and execution stops before connecting to the mail server. Is there an officially recommended diagnostic method to distinguish whether the cause is app authorization, the execution session, or the internal state of the keychain, without reading secret information, changing permissions, or unlocking the keychain?

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!

I'm investigating the boundary between Documents TCC protection and the app-created-file/user-intent exceptions on macOS 27.0.1. This is a request for supported diagnostics and revocation guidance, not a claim of a security bypass. Paths and process labels below are anonymised; the trace summaries describe observations, not a complete reproducer. Observed behaviour With Documents access disabled for a ChatGPT/Codex desktop app in Privacy & Security, its direct file tool created a workspace directory under ~/Documents and a new text file inside it. The file and contents were independently verified in Terminal. After the workspace was deleted manually and its absence verified, the tool recreated the directory and another test file without a new consent prompt. Restarting the app did not prevent this. No access to unrelated, pre-existing personal documents has been established. An fs_usage capture during a successful test showed an open for writing followed by WrData[A] on the test path, attributed to a local process named codex. The numeric suffix in that capture has NOT been conclusively correlated to the executor PID; it should not be treated as proof of the exact process chain. Process and signing observations A separate launchctl procinfo inspection of a local Codex exec-server showed sandboxed = no, with the desktop app as its responsible process. This establishes the inspected executor's state, not necessarily the dynamic restrictions of the exact writer or its children. The desktop bundle identifier is com.openai.codex. The embedded CLI has signing identifier codex and application identifier 2DC432GLL2.com.openai.codex.cli. These are vendor identifiers, not account identifiers. Embedded entitlement XML was read directly from the Mach-O LC_CODE_SIGNATURE superblob, because codesign diagnostics inside a later restricted tool environment were inconclusive. The desktop executable declares com.apple.security.app-sandbox = false, com.apple.security.files.user-selected.read-write = true and com.apple.security.automation.apple-events = true. The CLI's embedded entitlements include its application/team identifiers and JIT/unsigned-executable-memory permissions, with no app-sandbox entitlement. These are embedded declarations, not a claim that runtime validation or every effective grant has been verified. Being outside App Sandbox does not itself remove TCC protection. TCC chronology Earlier, a Python operation attributed to com.openai.codex requested kTCCServiceSystemPolicyDocumentsFolder. Its AUTHREQ_RESULT had authValue=0 and authReason=2. A later log recorded deletion of a Documents TCC record for that app, before the successful Codex write. Thus the earlier Python denial does not establish the decision applicable to the later write. Filtered TCC logs around the successful write contained app identity information but no matching Documents decision; a sandbox-log search found no relevant entry. Those are search results, not proof that no security check occurred. Extended attributes and application policy The parent Documents directory had a 216-byte com.apple.macl; the workspace had a 72-byte com.apple.macl. The parent's attribute remained when the child directory was deleted, and the recreated child acquired an attribute again. The identities represented by those records and their causal role are unknown. A Codex task configuration separately allowed the workspace as writable. That explains an application-policy allowance, not automatically the macOS authorisation. Filename searches did not identify a definite security-scoped bookmark; that does not rule one out. TCC database queries were inaccessible. No Full Disk Access was granted to inspect them. Questions Apple's WWDC19 session 701 explains that creating new documents in protected locations needs no consent, and that apps can access files they created or the user selected: https://developer.apple.com/videos/play/wwdc2019/701/ Does that documented exception also explain creating/recreating a directory and then accessing its descendants while the Documents switch is off on current macOS? What supported read-only diagnostics distinguish app-created-item access, a parent-directory MACL grant, security-scoped bookmarks, dynamic sandbox extensions and TCC responsible-process attribution? Is there a supported way to revoke per-item/user-intent access? Does the Documents switch intentionally leave new-file creation possible? For a user who wants to prohibit all Documents writes while retaining the desktop app, is an independently enforced filesystem sandbox required? How should that boundary be tested across direct file tools, shell children and GUI automation? I would appreciate guidance before any further disposable-file tests, attribute changes or TCC resets. No general Documents bypass or access beyond the workspace has been demonstrated.

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. Current state 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. Our understanding We read the documentation as follows. 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". 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. 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. 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. 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. Our questions 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!