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"

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!

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, 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!

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.

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?

We’re using an Enhanced Security helper extension with AppExtensionProcess and XPCSession to isolate native zero-knowledge proof generation from wallet and signing code. On an iPhone 15 Pro running iOS 26.6.2 (23G90), the helper terminates with: EXC_RESOURCE RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded (limit=35 MB) Terminated due to memory issue Our current prover requires substantially more memory: its public proving key is approximately 402 MiB, and its witness workspace alone is approximately 69 MiB. The same proof engine has completed successfully in a standalone iOS app process. The helper currently processes only synthetic test inputs. We want to preserve the helper’s sandbox and Enhanced Security protections and use a configuration supported for App Store distribution. Is there a supported way to increase the memory limit for this specific helper extension type? Does com.apple.developer.kernel.increased-memory-limit apply to Enhanced Security helper extensions? If so, what provisioning, target configuration, and device/OS requirements apply?

Hello Apple Technical Support, We need a documented feasibility clarification before implementing a native macOS app running in the logged-in user's context. The app needs to generate and persist a software RSA 3072-bit private key in the Data Protection Keychain (DPK), for RS256 (RSASSA-PKCS1-v1_5 with SHA-256). The required properties are effective private-key non-exportability and signing-only use, enforced beyond our app's choice not to call export or other cryptographic operations. We also need a supported way to verify these properties without attempting any private-key export. We distinguish these requirements from access-group authorization, kSecAttrSynchronizable=false, ThisDeviceOnly accessibility, and hardware-bound keys. We recognize that access groups are a different boundary from exact CDHash/build exclusivity; we do not claim that exclusivity is satisfied. Group membership alone does not establish the requested key properties, including for another process legitimately entitled to the same group. Environment: recorded static header provenance is MacOSX27.0.sdk (Command Line Tools), not a successful build or runtime validation. Target macOS version and build: Apple M4, 16GB in memory, macOS Tahoe version 26.6.2. No DPK implementation or experiment is being submitted as evidence. Please clarify these four points: Is there an officially supported API/attribute combination to generate and persist this software RSA3072 key in DPK with enforceable non-exportability and signing-only use (no decrypt, unwrap or derive)? If yes, please identify the exact APIs, attribute placement and values, applicable macOS/SDK versions, and enforcement limits. Please distinguish actual key restrictions from requested attributes or app-side policy. How does that combination, if supported, relate to the generic macOS kSecKeyExtractable=false exception documented for SecKeyCopyExternalRepresentation [1], versus the Apple DTS explanation that raw bytes of standard DPK keys can be obtained through that API [2]? Does the exception apply to software RSA keys generated in DPK, or only to other key implementations? Please distinguish kSecKeyExtractable from kSecAttrIsExtractable where relevant. Which supported attributes, query APIs or other evidence establish effective non-exportability and signing-only restrictions without attempting export? Please specify whether SecKeyCopyAttributes or an item query guarantees the required fields for this key/store combination, and how absent or unsupported fields must be interpreted. We will not treat a missing field as false or infer enforcement from creation inputs. If this combination is not supported for software RSA in DPK, please confirm that limitation explicitly and distinguish it from hardware-bound keys. We are not asking to substitute Secure Enclave/EC or another algorithm, and do not assume hardware guarantees apply to software RSA. References: [1] SecKeyCopyExternalRepresentation https://developer.apple.com/documentation/security/seckeycopyexternalrepresentation(::) [2] Apple DTS reply (June 2023), Developer Forums thread 731001 https://developer.apple.com/forums/thread/731001 [3] TN3137: On Mac keychain APIs and implementations https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains [4] Protecting keys with the Secure Enclave https://developer.apple.com/documentation/security/protecting-keys-with-the-secure-enclave An applicable technical answer with references and limits, or an explicit statement that this combination is unsupported, would resolve the feasibility question. If support or a non-exporting verification method cannot be established, we will keep support NOT_ESTABLISHED and implementation blocked. A successful signature or access-group isolation alone would not close it. Thank you. fapontec

Background: We are loading a web login page inside ASWebAuthenticationSession. For login page, username and password have autofill password options enabled. On click of the username textfield when we tap the system "Passwords" suggestion in the QuickType bar above the keyboard causes the app to become completely unresponsive. No crash occurs and nothing is logged to the console. The only option to get back to the app is we must force-quit to recover. This issue is observed only on OS 26.6.1 and 26.7.1 other variant of the OS-26.x seems to be working fine. We have tested the gmail app having the ASWebAuthenticationSession for login scenario, the similar issue is observed in that too. Does anyone else also have faced similar issue ? Any help/pointers much appreciated.

I'm implementing Apple's App Attest service in a Swift iOS app using DCAppAttestService, with a TypeScript backend hosted on Cloudflare Workers. Key generation and attestation registration both work correctly. The server successfully validates Apple's certificate chain, confirms that the public key matches the key ID, and stores the P-256 public key. However, when the app calls generateAssertion, the server consistently fails to verify the returned signature. Here's what I've checked so far: The app passes SHA256(clientData) to generateAssertion, as Apple's documentation requires. The server constructs the verification message using authenticatorData || SHA256(clientData). I've confirmed that the client and server use matching hashes, assertion data, authenticator data, and verification messages. The stored public key matches the App Attest key ID. The returned signature has a valid DER structure. Signature verification fails using both Web Crypto (with DER-to-P1363 conversion) and a separate Node.js verification method. Both verification methods work correctly with independently generated test signatures. Challenge validation, RP ID checks, environment checks, and extension validation all pass. One thing that stands out: The assertion's authenticator data contains the flags 0xC0 (AT + ED). An extension data map appears immediately after the standard 37-byte header, without the credential data that would normally be expected when the AT flag is set. Apple mentioned new App Attest assertion extensions in WWDC26, but I haven't found documentation explaining whether this specific format is expected on iOS 27. My server includes the entire original authenticator data, including the flags and extensions, when verifying the signature. Nothing is removed or modified. I have three questions: Is 0xC0 a valid flag combination for App Attest assertions on iOS 27 when extension data follows the 37-byte header without a separate credential data section? Does the standard signature verification formula, SHA256(authenticatorData || SHA256(clientData)), still apply when these new extensions are present? Are there any known issues or changes in iOS 27 that could cause generateAssertion to succeed while the server cannot verify its signature using the public key obtained during registration? I'm testing on a physical iPhone using a Debug development build, not the simulator. I've also kept the original App Attest key and registration unchanged throughout testing. At this point, the client and server appear to agree on all the data used for verification, but the signature still fails. I'm trying to determine whether I'm missing something about the new assertion format or whether there is another part of the verification process I should investigate. Any guidance would be appreciated.

Hello, I am developing an application that integrates with Apple Music to provide a personalized music video experience for Apple Music subscribers. We are working on support for many devices like Android TV / Google TV / WebOS / etc. and would like to implement an authorization experience suitable for a television, where entering account credentials with a remote control is cumbersome. Intended authorization flow We would like to implement the following experience: The application on the TV displays a QR code or short activation code. The user scans the QR code with their phone and opens an Apple-hosted authentication and authorization page. The user signs in to their Apple Account if necessary and approves Apple Music access for the application on the TV. The TV application receives or retrieves the resulting authorization and can use it for the supported Apple Music functionality. The objective is for the TV application itself to be authorized following approval on the phone, with no need to enter the Apple Account credentials on the television. Relevant implementation evidence found on Apple’s website While researching this integration, we examined JavaScript publicly served by link.apple.com. In the following OAuth view bundle, we observed these identifiers: PartnerAuthorizationRequest isOffDeviceOAuth2Flow DEVICE_CODE Source: Apple-hosted OAuth view bundle — oauth-views-OAuth-vue.4db9105e.js In the associated OAuth initializer bundle, we observed properties including: client_id scope response_type Source: Apple-hosted OAuth initializer bundle — oauth-views-OAuthInitializer-vue.23605d03.js These elements suggest that Apple’s authorization interface includes an off-device authorization path associated with partner clients. We understand that these implementation details are not public API documentation and do not establish whether this flow is available to third-party developers. We are looking for the officially supported integration and enrollment process, if one is available. Clarification requested 1. Availability for third-party TV applications Does Apple offer a supported Apple Music authorization flow of this kind for third-party applications running on non-Apple devices? If the observed flow is limited to certain integrations or partners, what are the eligibility requirements for obtaining access? 2. Client registration and account configuration What is the official process for registering or obtaining a client_id authorized to use this flow? We have reviewed the standard MusicKit configuration involving Media IDs, Media Services keys, App Services and Capability Requests, but have not identified the configuration or application process for off-device authorization. Could you clarify whether this requires: A standard MusicKit Media ID and Media Services key; An additional service configuration or managed capability request in the Apple Developer account; A separate OAuth client registration; Or approval through an Apple Music partner program? 3. Supported integration documentation If this integration is available, where can we obtain the documentation or SDK covering: The required client configuration, request parameters and permitted scopes; Creation of the authorization request and the QR code or activation link; The mechanism by which the TV checks for completion or receives the result; The resulting token type, its intended use, and its expiration or reauthorization requirements? In particular, we would appreciate clarification on whether the resulting authorization provides a Music User Token usable by the TV application, or another token that requires a documented exchange. 4. Apple Music access on the authorized TV Which Apple Music APIs or SDKs can consume the resulting authorization? We would like to confirm its supported use with Apple Music API and MusicKit for Android, including any separate requirements for playback on the TV. Our intended design is for authorization to be issued for the TV application, rather than transferring a Music User Token issued for the phone. If this access is handled outside the standard MusicKit developer workflow, could you please identify the applicable program and enrollment process, or who to route this request to the Apple Music team responsible for partner authorization and connected-device integrations? Thank you for helping us identify the supported path for this integration. Louis

This is a pre-implementation question about supported direct Keychain service access, based on documentation and SDK-declaration review. No device/Simulator result, runtime failure, compiled sample or verified signing configuration is being reported. Assumed configurations An embedded, app-specific, non-UI ExtensionFoundation extension, restricted to its containing app's extension point. No unrestricted or third-party extension scope is assumed. A: the extension point requires EnhancedSecurity(true). B: the point definition omits EnhancedSecurity. This is not a claim that B is unsandboxed or equivalent to every configuration explicitly declaring EnhancedSecurity(false). Generic-password items, with valid signed membership in the destination Keychain access group assumed for the question only. If that assumption cannot hold for A or B, please identify the unsupported prerequisite. No real identifiers or profiles are supplied. Version scope The API question concerns iOS 26.0 and later only where the relevant symbols/configurations are supported. In the installed iPhoneOS 27.0 SDK declarations inspected, AppExtensionPoint, EnhancedSecurity and UserInterface have iOS 26.0 availability; some binding conveniences have iOS 26.2 availability. Those are declaration observations, not evidence of Keychain authorization or behavior on any OS release. No runtime comparison or final deployment target is selected. Please specify any finer minimum OS/SDK requirement or version-dependent difference; do not infer older-iOS support from the framework name alone. Question For A and B separately, is each of SecItemCopyMatching, SecItemAdd, SecItemUpdate and SecItemDelete supported directly from the extension process for those items, without forwarding the operation to the containing app? Please distinguish the four operations and, for any supported or conditional case, identify: The public sandbox/service rule and required entitlements, separately from access-group membership. Applicable OS/SDK versions and any device-versus-Simulator or development-versus-distribution limits. Lock state, item accessibility, user-interaction or other prerequisites that change the answer. If a case is unsupported or unspecified, stating that and citing the applicable public documentation would resolve that part of the question. API availability or absence of the EnhancedSecurity requirement alone is not being treated as permission to access the service. This asks for the direct API/service boundary only. Relevant public references https://developer.apple.com/documentation/extensionfoundation/adding-support-for-app-extensions-to-your-app https://developer.apple.com/documentation/extensionfoundation/appextensionpoint/enhancedsecurity https://developer.apple.com/documentation/security/sharing-access-to-keychain-items-among-a-collection-of-apps

I am validating a local backup and recovery workflow using artificial files only. I would like guidance on supported quarantine handling, not a way to bypass Gatekeeper. The recorded tests used: Native ditto with --rsrc --extattr --acl --qtn. Native pax-tar creation and restore with --mac-metadata and --fflags. Important limitation: the quarantine markers were seeded manually in the test fixtures. These were not files quarantined through a real browser download, so I have not established that the fixtures represent normal download provenance. Unmarked controls matched their source. In marked copy/restore cases, payload hashes and other checked metadata matched, but com.apple.quarantine differed. One earlier copy recorded a flag-prefix change from 0081 to 0281; other marker fields also changed. Original marker bytes can be retained exactly as archive data, but that does not explain the security effect of the native-restored value. I have not stripped or normalized restored markers, changed Gatekeeper settings, or tested execution of the restored files. An earlier project record lists macOS 26.5.1. The current OS build and exact native-tool versions have not been refreshed for this question. Could you clarify: Is manual marker seeding a supported way to test copy/restore behavior, or should this be evaluated using an OS-managed quarantine event instead? Can these native operations intentionally change quarantine state, and which documented interfaces or guidance establish the meaning and security impact? Is preserving the original bytes as archive evidence while leaving native-restored metadata untouched the supported approach? What checks or supported options should a recovery workflow use without rewriting the marker or weakening Gatekeeper? I am not claiming this is a macOS vulnerability or that the changed value is harmless. No business files, private logs or attachments are included.

We maintain an SFAuthorizationPluginView-based authorization plugin (mechanisms registered in system.login.console) on macOS 26 (Darwin 25.x) and are seeing a cosmetic but user-visible issue at the login window that we believe originates in the host, not our code. We'd like to confirm whether it's expected behavior or a bug worth filing via Feedback. Setup Two local users, A and B. Our plugin adds a custom mechanism to the login chain, so after credential submission the host may present additional UI (our mechanism's view). Each authorization round runs in a fresh SecurityAgentHelper process (verified via PID in logs), so no state of ours survives between rounds. Reproduction Log out of user A at the login window. Select user B and type their password. Submit. Our mechanism (invoked after submission, e.g. an enrollment prompt for a not-yet-enrolled user) presents its UI. Observed For roughly 1.1–1.4 s between our mechanism's window appearing and covering the host's, the login window shows user A's name/avatar tile — the previously selected user — before our panel covers it. Instrumentation confirms: Our process logs willActivate(withUser:) delivering user A (the previous round's user) while the authorization context (GetContextValue on kAuthorizationEnvironmentUsername) correctly contains user B. The stale tile renders inside what appears to be the host's own window (class LUI2Window, created ~300 ms before our surface activates). Our code makes no writes to the engine context at that point (we log every SetContextValue; zero writes occurred during the flip window). The flip only happens when our mechanism round starts after credential submission. If the mechanism round starts before user selection (the normal login path), each user click produces a fresh willActivate with the correct name and no flip is visible. Question Why does the login window display the previous round's user (user A) after I've selected and submitted credentials for user B? The willActivate(withUser:) callback our mechanism receives still carries user A at that moment, while the authorization context already contains user B — the two disagree. Is the host intentionally re-showing the last logged-in user's tile when a mechanism presents UI after credential submission, and can a mechanism do anything to prevent it?

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.

Sign in with Apple fails with "Sign-Up Not Completed" Team A884B34HZR The authorization sheet renders correctly with our app name and the user's Apple Account. After the user authorizes, it ends with "Sign-Up Not Completed" and no credential is returned to the app: our delegate receives no credential, and our server never receives a request. Bundle ID: com.dinogoal.ios (created in 2026) Feedback: FB24978334. Developer Support case: 102979104342 (closed without a resolution) Already tried, with no change: Removing the Sign In with Apple capability from the App ID, saving, re-adding it as a primary App ID and saving again. Regenerating the provisioning profile and shipping a new signed build. Several Apple Accounts, on Wi-Fi and cellular, on iOS 26 and iPadOS 27. Our submission has been rejected under Guideline 2.1(a) because of this. This looks like the same server-side registration failure reported in threads 789452 and 837986.

I'm testing PRF evaluation with a YubiKey Bio through AuthenticationServices on iOS. Registration succeeds, but during later authentication with the enrolled fingerprint, I don't receive a PRF result. Using the key’s FIDO2 PIN works. Environment iPhone 12 iOS 27.0.1 YubiKey Bio connected through USB Firmware: 5.7.0 Steps to reproduce Configure a FIDO2 PIN and enroll a fingerprint on the YubiKey Bio. Connect the key to the iPhone. Register a credential using ASAuthorizationSecurityKeyPublicKeyCredentialProvider with PRF support requested. Request authentication for the registered credential with PRF input and userVerificationPreference = .required. Authenticate using the enrolled fingerprint. Check the returned PRF result. Compare this with authentication using the FIDO2 PIN. Expected result Successful authentication with PRF evaluation returns a 32-byte PRF output. Actual result No PRF result is returned when using fingerprint verification. The PIN flow works. Related report I found WebKit bug #314934, which reports missing PRF results with a YubiKey C Bio in Safari. The reporter observed successful authentication but a null PRF output. Could AuthenticationServices be affected by a similar issue? Is there a known limitation or workaround for PRF evaluation with YubiKey Bio fingerprint verification?

We develop an authorization plugin that replaces password entry at the login window and at screen unlock with a phone-based sign-in. The user scans a QR code with their phone, or the Mac reaches the phone over Bluetooth. Either way the plugin ends up with the user's password, which it hands to the authorization engine as if it had been typed. All networking runs in a LaunchDaemon that the plugin calls over XPC. Setup system.login.console: loginwindow:login → OurPlugin:login system.login.screensaver: rule use-login-window-ui → authenticate-session-owner-or-admin, with screenUnlockMode set to 2 authenticate: builtin:authenticate → OurPlugin:authenticate The UI is an SFAuthorizationPluginView subclass. On success we set username and password in the context (plus home at login) and call SetResult with kAuthorizationResultAllow. What we see on macOS 27 Since moving to macOS 27 on a MacBook Pro (M3 Pro), we hit these more often: Touch ID unlocks the Mac but leaves our view on screen. Open the lid and unlock with Touch ID. The desktop becomes usable, but our plugin view stays on top, and shortly after the screen locks again. Same symptom as thread 819454, where it was filed as FB22289735. Saved passwords disappear from apps after an unlock through our plugin. They come back only after the user logs out and in again. This looks like FB13128730 (thread 796487). The lock screen stays on the desktop after sign-in. The clock, the user picture and our view, with its filled-in password field, stay on screen while the menu bar and Dock are drawn on top of them. Similar to FB12074874. We also saw this once: the password field in our view would not take keyboard input at the lock screen. Every key press just played the system alert sound, and nothing was typed. Questions Is there any workaround for these on macOS 27? Or a supported way to stop macOS offering Touch ID while our plugin handles unlock? Is an SFAuthorizationPluginView plugin still a supported way to replace the login and unlock UI? If not, what should we move to? Is Platform SSO with the new web-based authentication in macOS 27 (login window, Lock Screen and FileVault unlock) the path you would recommend? If so, is there a supported option for offline sign-in, which we do over Bluetooth today?

We are transferring an iOS app from Team A to Team B and following TN3159 to migrate Sign in with Apple users. Setup on Team A: The app’s bundle ID (com.example.app) is enabled for Sign in with Apple as its own primary App ID, not grouped. Our website uses a Services ID (com.example.web-service) whose primary App ID is a different App ID (com.example.web), not the app. Some users signed in only on the website and never used the app. Using a Sign in with Apple key associated with the app’s App ID and client_id=com.example.app, /auth/usermigrationinfo returns a transfer_sub for every user we tested, web-only users included. Questions: After the transfer, Team B will exchange these transfer_sub values with client_id=com.example.app and its own client secret. Will that work for users who only authorized the web Services ID? Or can it fail (for example invalid_request) because they never authorized the app’s App ID? If it can fail, can we change the Services ID’s primary App ID to the app’s App ID before the transfer, so the Services ID transfers with the app (as TN3159 describes)? Would that affect existing users, for example by changing their identifiers or asking for consent again? For users with a private relay email: since Team A has no other app those users use, does the old relay address stop forwarding after the transfer? Does the exchange return the new relay address for web-only users too? Thanks!

I’m looking for technical clarification on how the standalone Apple Passwords app protects credentials on iOS 26 and iOS 27, specifically when a device is locked after its first unlock since boot (AFU). Apple’s Platform Security documentation identifies Safari website passwords as using the When Unlocked Keychain protection class: https://support.apple.com/guide/security/secb0694df1a/web However, it is unclear whether this documentation also describes the implementation of the newer standalone Passwords app. Keychain accessibility classes Does the Passwords app continue to store website and application passwords using kSecAttrAccessibleWhenUnlocked or an equivalent, more restrictive class? Do passkeys, TOTP verification-code secrets, and any intermediate keys necessary to decrypt stored credentials receive the same protection? Locked-AFU protection When an iPhone has been unlocked once since boot and subsequently locked again, are the cryptographic keys required to retrieve saved website passwords inaccessible until the user unlocks the device again? Specifically, does the When Unlocked class enforce this restriction cryptographically, or could a process with elevated operating-system privileges retrieve the protected material while the device remains locked? Full-filesystem and Keychain extraction Assuming an authorized forensic examiner obtains a full-filesystem extraction or privileged operating-system execution on a device that remains locked in AFU, but does not know the device passcode: Does filesystem access alone expose usable plaintext credentials stored in Apple Passwords? Are additional cryptographic keys or authentication steps required? What security guarantees remain for When Unlocked Keychain items under these conditions? I’m not requesting information about undisclosed vulnerabilities or specific forensic-tool exploits. I’m interested in the documented behavior and security boundaries of Apple’s Keychain architecture. Independent verification Are there any published technical assessments, research papers, forensic experiments, or Apple security documents that verify the actual accessibility classes used by the Passwords app on iOS 26/27? For context, a 2026 independent security assessment of Proton Pass identified its use of kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly for sensitive Keychain material as a defense-in-depth weakness and recommended kSecAttrAccessibleWhenUnlockedThisDeviceOnly. I’m trying to understand whether Apple’s native Passwords app provides a stronger cryptographic boundary against locked-AFU extraction, rather than merely a different user-interface authentication requirement. Any clarification from an Apple engineer or references to authoritative technical documentation would be greatly appreciated.