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"

Apple Developer Account — Access & Subscription Issue Hello Apple Developer Support, I am writing to resolve a critical access and subscription issue with my Apple Developer account. My Apple ID (lich666black@gmail.com, Person ID: 1669634243, Developer ID: L2B6257ZS2) is the Account Holder for my organization, Khasanshin Rinat Ildarovich, IP (Team ID: DNQ8PB6F6V, App Store Connect Legal Entity ID: 90331734). Current Blocking State In App Store Connect, the organization team DNQ8PB6F6V shows that the membership has expired and prompts me to accept the updated Apple Developer Program License Agreement on the Apple Developer website. However, when I log into developer.apple.com/account, the portal backend returns an empty teams array (teams: []) with isAgentOfAnyActiveTeam: false, and defaults my web session to an old duplicate profile ("Rinat khasanshin", marked as Deprecated in ASC). Because of this, the web portal hides my organization team and only displays the "Enroll today" button. When I try to use it, the system blocks me with the error: "Your Apple Account is already associated with the Account Holder of a membership." Additionally, I cannot use the native macOS Apple Developer app to resolve this, because the app requires a newer version of macOS than what is currently running on my Mac. Request Could you please assist in: Unlinking or merging the deprecated profile; Re-syncing my active organization team (DNQ8PB6F6V); Updating the membership status so I can properly access the portal and sign the updated agreement? Thank you for your help.

We are interested in using a hardware-bound key in a launch daemon. In a previous post, Quinn explicitly told me this is not possible to use an SE keypair outside of the system context and my reading of the Apple documentation also supports that. That said, we have gotten the following key-creation and persistence flow to work, so we have some questions as to how this fits in with the above. (1) In a launch daemon (running thus as root), we do: let key = SecureEnclave.P256.Signing.PrivateKey() (2) We then use key.dataRepresentation to store a reference to the key in the system keychain as a kSecClassGenericPassword. (3) When we want to use the key, we fetch the data representation from system keychain and we "rehydrate" the key using: SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: data) (4) We then use the output of the above to sign whatever we want. My questions: in the above flow, are we actually getting a hardware-bound key from the Secure Enclave or is this working because it's actually defaulting to a non-hardware-backed key? if it is an SE key, is it that the Apple documentation stating that you can only use the SE with the Data Protection Keychain in the user context is outdated (or wrong)? does the above work, but is not an approach sanctioned by Apple? Any feedback on this would be greatly appreciated.

Hello Apple Developer community, I'm investigating an unexpected metadata representation returned by Apple's Security framework while inspecting an existing Secure Enclave-associated Keychain item on macOS. A read-only inspection using SecItemCopyMatching returns one matching key record with a successful status, a Secure Enclave token identifier (com.apple.setoken), and a 256-bit key size. However, direct Core Foundation type inspection reports: kSecAttrKeyType: CFNumber kSecAttrKeyClass: CFNumber kSecAttrSynchronizable: CFNumber The raw Core Foundation observations and bridged observations agree. Our current validator rejects these unexpected types and returns UNSUPPORTED_OR_INCOMPLETE_METADATA. We have deliberately stopped further key operations pending clarification. Questions: Can these CFNumber values legitimately appear in a dictionary returned by SecItemCopyMatching for Secure Enclave-associated key items on macOS? What returned value types should be expected for these three attributes, and are they dependent on the query or Keychain implementation? Is there an Apple-recommended way to normalize or validate these attributes without incorrectly accepting incompatible metadata? How should an application distinguish an existing Secure Enclave-backed key from an incomplete or unsupported Keychain record without performing a private-key operation? Are there relevant Security framework documentation references or known implementation differences we should consult? Our aim is to validate the existing record safely without regenerating, deleting, or using the private key. Thank you for your guidance.

Overview We are investigating repeated "login" Keychain prompts affecting our macOS application on macOS 26.6.x. The issue appears after upgrading an existing installation. A clean uninstall/reinstall of the same version resolves it. Changing the affected Keychain item's Access Control from "Confirm before allowing access" to explicitly allowing our application/process also stops the prompts. On one affected machine, Apple Support observed a securityd crash followed by: SecKeyCreateSignature failed CSSMERR_DL_INVALID_DB_HANDLE Our code uses some legacy SecKeychain* APIs, so we are currently investigating whether this is related. Questions Were there any changes in macOS 26.6.x around securityd, Keychain ACL handling, or legacy SecKeychain* APIs that could explain this? Could an existing Keychain ACL become stale after an application upgrade, even when both versions are signed with the same Developer ID?

Hello everyone, I'm trying to understand the actual limitations of the Secure Enclave (SEP) regarding cryptographic key capabilities, and more specifically how to generate and store the following key types in the keychain: Sign only: The key can only be used for digital signatures. Key agreement only: The key can only be used for key agreement operations. All operations: The key can be used for both signing and key agreement. I've noticed some apparent differences between Apple's Security framework and CryptoKit, and I'm trying to understand whether these differences reflect actual SEP limitations or simply framework-level restrictions. 1. Security framework: dual purpose keys I'm currently using SecKeyCreateRandomKey to generate Secure Enclave-backed keys. Here is the relevant code: NSDictionary *privateAttributes = @{ (__bridge id)kSecAttrIsPermanent : @YES, (__bridge id)kSecAttrAccessControl : ..., (__bridge id)kSecAttrApplicationTag : ..., // key agreement only (__bridge id)kSecAttrCanSign: @NO, (__bridge id)kSecAttrCanDerive: @YES }; NSMutableDictionary *attributes = [ @{ (__bridge id)kSecAttrKeyType : (__bridge id)kSecAttrKeyTypeECSECPrimeRandom, (__bridge id)kSecAttrTokenID : (__bridge id)kSecAttrTokenIDSecureEnclave, (__bridge id)kSecAttrKeySizeInBits : @256, (__bridge id)kSecPrivateKeyAttrs : privateAttributes } mutableCopy ]; CFErrorRef generationError = nullptr; SecKeyRef privateKey = SecKeyCreateRandomKey( (__bridge CFDictionaryRef)attributes, &generationError );However, when experimenting with these attributes, I encountered the following error: SecKeyCreateRandomKey failed: Error Domain=NSOSStatusErrorDomain Code=-50 "Failed to generate keypair" Underlying error: Error Domain=CryptoTokenKit Code=-8 "sepkey: sign requires '1' value when present"Using signing-only attributes results in the same kind of error. This makes me wonder whether the Security framework actually allows generating (and adding entries in the keyChain) only keys with both capabilities enabled. It is possible to create siging only key or key agreement only key with Security framework? 2. CryptoKit: Separate key types On the other hand, CryptoKit seems to expose two distinct Secure Enclave key types: P256.SecureEnclave.Signing.PrivateKey P256.SecureEnclave.KeyAgreement.PrivateKeyFrom the API design, it appears that CryptoKit only allows creating keys dedicated to one operation or the other. For example, a Signing.PrivateKey cannot be used for key agreement, and a KeyAgreement.PrivateKey cannot be used for signing. Is it possible to create both capabilities keys with CryptoKit framework? 3. Actual Secure Enclave limitations What are the actual cryptographic capability limitations imposed by the SEP itself? I'd particularly like to understand which restrictions originate from: The Secure Enclave hardware. Security and CryptoKit frameworks. Is there a documented way to generate and store in the keychain: A signing-only Secure Enclave key? A key-agreement-only Secure Enclave key? A Secure Enclave key supporting both operations? Thanks in advance, Idopte

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?

Hi, I'm integrating the TrustInsights framework (Impersonation Risk Detection, IsLikelyBeingCoachedInsight) announced at WWDC26. I'd like to confirm whether the behavior below is expected regional gating or a misconfiguration on my side. Environment Real device: iPhone 15 , iOS 27.2 Xcode 27.2 , SDK iOS 27.2 App has the Trust Insights capability added in Xcode; the embedded provisioning profile includes com.apple.developer.trustinsights.base (verified via security cms -D) Deployment target and device OS both satisfy the framework requirements Code (standard usage) **Observed behavior** 1. `authorizationStatus(for:)` always returns `.unavailable`. 2. `requestAuthorization(for:)` also returns `.unavailable` — no system permission alert is shown. 3. `requestEvaluation(context:)` throws with the framework log: 4. The Settings entry described in the user-facing docs (Settings → Privacy & Security → Impersonation Risk Detection → "Share with App Developers") **does not exist on this device**, including after search and after a failed evaluation attempt. 5. The documented testing launch argument does reach the process — `UserDefaults.standard.string(forKey: "TrustInsights.IsLikelyBeingCoachedValue")` returns `medium` when launched with `-TrustInsights.IsLikelyBeingCoachedValue medium` — but evaluation still fails with the same `denied`. **Questions** 1. Is TrustInsights / Impersonation Risk Detection currently unavailable in China mainland (or gated by region/Apple Account storefront)? Is that why `authorizationStatus` returns `.unavailable`? 2. Why do `authorizationStatus` and `requestAuthorization` return `.unavailable` while `requestEvaluation` gets far enough to return `.denied`? Which one reflects the actual gate? 3. If the per-app permission row in Settings is only created after the first `requestAuthorization` flow, how is that supposed to happen when the API returns `.unavailable` without presenting any UI? 4. Is there a supported way to exercise the evaluation pipeline (including the launch-argument overrides) on a device where the Settings entry is absent, so UI/UX work can proceed before regional rollout? 5. Is developer-side enablement required (entitlement request / Feedback) for regions where the feature is not yet live? Thanks!

Hello, We use Sign in with Apple on the web with an existing Services ID that is already in production. We plan to keep using the same Services ID and change its configuration as follows: Migration rehearsal: Add a new domain and Return URL, while keeping the current ones. Production cutover: Change the name shown to users, and remove the old domain and Return URL. We would appreciate guidance on the following two points: If we add a new domain and Return URL while keeping the existing ones, will sign-in through the existing Return URL continue to work without any impact on existing users? Do any of these changes (adding or removing domains and Return URLs, or changing the name shown to users) require a review or approval by Apple before they take effect? Thank you in advance.

Our iOS app uses shm_open to create an app-owned, App Group-scoped POSIX shared-memory object. Before allowing access to previously authorized offline data, we call fstat on its file descriptor to verify the object's size, owner UID, and permission mode. We do not access file timestamps, use this information for fingerprinting, or send the metadata off-device. Apple's approved reason C617.1 refers to files inside app or App Group containers. However, POSIX shared-memory objects have no filesystem entry. Does C617.1 cover this specific use of fstat? If not, should we request a new approved reason?

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.

Hi, are there any known issues with delayed iCloud Keychain synchronization to macOS? I have an app for iOS and macOS that supports creating, reading, updating, and deleting synchronizable Keychain items. Both versions are signed with the same Team ID, and all test devices are signed in to the same Apple Account. I’m observing a significant difference depending on the direction of synchronization: macOS → iOS: approximately 30 seconds. iOS → other iOS devices: approximately 30 seconds. iOS → macOS: approximately 30 minutes, with some variation. Changes eventually appear on the Macs, but incoming updates take much longer. Is this expected behavior, a known issue, or something that could be caused by my implementation? What diagnostics would help investigate it? Devices are on iOS 26 and macOS 26.

I am being robbed and denigrated in Romania. Chitac Costel Danut 29/04/1977.. passport-066839639 and CNP-1770429072623 ...

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!