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"

Since 2026-11-14 00:56 UTC, about 45% of people creating a new account with Sign in with Apple in our App Store app fail. The sheet appears, the user picks Share or Hide My Email and confirms with Face ID, then the delegate gets ASAuthorizationError 1000 with an empty userInfo. Customers report a system "could not connect" alert just before it. What we see: Only first-time authorizations fail. Returning users sign in normally. Only iOS 26.x and 27.x. No failures on iOS 18.x. Same rate in Japan and Thailand, on Wi-Fi and cellular, with either email choice. An affected device fails on almost every attempt, then eventually one attempt succeeds. Unaffected devices succeed first time. 1,340 failed attempts from 376 devices so far. The same build signed in 107 of 111 users in the two days before it started. No app release, App ID change or backend change at the time. System Status shows Sign in with Apple as available. We have not been able to reproduce it on our own devices, so we have no sysdiagnose from a failing device yet. Feedback ID: FB25582932 Is anyone else seeing this since November 14? And could someone from Apple check the server side for our client ID?

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.

I filed FB25584356 for this and would appreciate any pointers. Setup: Mac mini on macOS 27.2.1 and an iPhone on iOS 27.2, same Apple Account, HSA2, Advanced Data Protection off. Octagon is healthy (otctl status = Ready, both devices trusted). Symptoms: AirDrop to my own iPhone fails when I pick the device (rapportd: "PairVerify server M2 failed: copy identity"), iPhone Mirroring ends with noCompatiblePhone, and various clients log CKErrorDomain 111 / 5009 "Keychain Sync Incomplete". What I see in CKKS: seven zones (AutoUnlock, LimitedPeersAllowed, Home, Manatee, ApplePay, Health, Engram) still hold a key hierarchy from August 2019. The only TLKShare was issued by a device that left the account years ago, so neither current device can unwrap the TLK ("No trusted TLKShares", CKKSErrorDomain 35). secd then does what I would expect: tlkmissing → "No other devices claim to have the TLK. Resetting zone..." → CKKSDeleteCKZoneOperation → local reset → zones recreated. The delete appears to succeed. With debug logging, cloudd shows status:200 and "RecordZone ... was successfully deleted from the server" for each zone. The next fetch returns the same 2019 records with an identical server change token. Over about 11 hours: 124 reset cycles, 869 zone deletions reported as successful, 182 consecutive AutoUnlock fetches with the same change token. When not throttled it runs roughly every 5 seconds; CloudKit eventually answers "Service Unavailable" (CKError 6/2009) with a ~59 minute retry-after, and all 23 zones are unusable in the meantime. ckksctl -v AutoUnlock reset-cloudkit behaves the same way. Reset path: Support article 120862 describes "Don't know passcode?" → "Forgot all passcodes?" → "More Options" → "Delete iCloud Data". With the Mac signed in but not yet trusted, "Don't know passcode?" only offered Cancel / Try Again Later, in the sign-in flow and in both System Settings follow-ups. After three wrong passcodes the alert had a single "Try Again Later" button, although cdpd logged "Creating recovery option: Reset". Questions: Is a client-side zone delete expected to be a no-op for these zones while the server reports success? Is there a supported way to reach performCKServerUnreadableDataRemoval / "Delete iCloud Data" when another trusted device exists? I am fine with losing the end-to-end encrypted data in those zones. Logs and a sysdiagnose are attached to the Feedback.

Hello, I have noticed, once again, that DeviceActivityMonitors are quite frustrating to work with, since they are triggering random events when using mulitple Apple devices. For example, if Instagram is open on some random (non-foreground!) tab in Safari on the Mac, the iPhone will reach its limit quite consistently & quickly atfer setting up a new device activity threshold. It would be great if A) background usage was not counted towards screen time: FB25576930 B) there was an API for us developers to set-up device-specific deviceactivitymonitors: FB24363336 Hope that helps!

Our iOS app has used Sign in with Apple (SwiftUI SignInWithAppleButton, scopes .fullName and .email, hashed nonce) for over a year without problems. Since about 04:00 UTC on 14 November 2026, most people authorising the app for the first time fail: they tap the button, the system sheet appears, they complete it (Face ID or passcode), and 6 to 20 seconds after the tap the completion handler receives ASAuthorizationError.unknown (1000). People who have authorised the app before sign in normally. No request reaches our server in the failing case. What we see Before the onset this failure was rare: about one person a week against 15 to 24 first-time sign-ups a day. In the first 12 hours after the onset, 10 people got a result from the sheet. 7 never signed in. 3 did, two of them only on the 3rd and 5th attempt. It affects the current App Store build and the previous one, iOS 26.5 to 26.7, several iPhone models, in Canada, the US, Saudi Arabia, Qatar and Morocco, on Wi-Fi and cellular. This is separate from the immediate 1000 a device with no Apple Account returns. Those arrive within 3 seconds and we excluded them. What we checked Sign In with Apple is enabled on the App ID as a primary App ID. The com.apple.developer.applesignin entitlement is unchanged. Distribution certificates are valid and the membership is active. Nothing in the authorisation request, the button or the completion handler changed between the two builds. We could not reproduce it on our own device after revoking our grant in Settings (Stop Using) and signing in again. One possibly related fact: an updated Apple Developer Program License Agreement was issued on 29 October 2026 and we only accepted it on 14 November, about 12 hours after the failures began. We do not yet know whether the failures stopped after acceptance. Questions Can an unaccepted Program License Agreement degrade Sign in with Apple for first-time users, for example after a grace period? Has anyone else seen first-time authorisations start failing around 14 November 2026 with no change on their side? What should we capture from an affected device to identify the cause, given that we cannot reproduce it ourselves? We have no sysdiagnose from a failing attempt yet. The code-level support form requires a sample project, and this cannot be reproduced in one, so I am asking here. I can share the team ID, bundle ID and UTC timestamps of individual failed attempts privately with an Apple engineer. Update: this looks like the same thing as https://developer.apple.com/forums/thread/857623 (new users only since 14 November, returning users fine, agreements all active there). Our first failure was at 04:07 UTC on 14 November.

We are evaluating a macOS design before implementation. This is a platform-support question, not a report of an observed runtime failure. No actual controller executable, helper executable or deployment configuration has been selected or qualified. Our objective is to let a small, fixed-purpose helper examine an already-open object’s identity and access control list (ACL) metadata while preserving the original object reference and ownership. Proposed configuration A trusted controller would launch one native C helper using an explicit executable target and posix_spawn. The controller would need to qualify for the documented nonsandboxed-parent case, without a conflicting inherited sandbox. We do not assume that an absent entitlement alone establishes this. The helper would be the main executable of its own signed application bundle, using its own ordinary App Sandbox rather than inheriting the controller’s sandbox. Its proposed additional filesystem permission would be com.apple.security.temporary-exception.files.absolute-path.read-only, containing exactly two fixed directory entries beneath a user’s development workspace, outside the helper’s container. The literal private paths are omitted. The controller would already own a read-only file descriptor for one regular file or directory within those trees. It would retain its original reference and pass a known duplicate referring to the same open object to the helper. The helper would perform one metadata observation. The proposed operations are fstat for object identity and fgetattrlist requesting ATTR_CMN_RETURNED_ATTRS and ATTR_CMN_EXTENDED_SECURITY, with FSOPT_REPORT_FULLSIZE and without FSOPT_PACK_INVAL_ATTRS. Required boundaries The helper must use only the inherited descriptor for the subject observation. The design does not permit: Reopening or resolving the subject through a pathname, bookmark or URL. Substituting a copied file or another object reference. Reading file contents, enumerating directories, changing permissions, or modifying shared descriptor flags or file offsets. Expanding the exception to an ancestor, home directory or broader workspace. Disabling an existing sandbox or using private interfaces to bypass restrictions. Parent-side traversal and identity checks remain separate responsibilities. Strict ancestor directories are not additional helper ACL subjects. We understand that a read-only directory exception and ordinary sandbox/container capabilities may permit more than the helper’s intended metadata operations. Metadata-only behaviour would be a reviewed-code obligation; we are not asking App Sandbox to enforce an exact metadata-only operation filter. Questions Supported launch and activation: Under what documented parent-context, signing, bundle, container and launch conditions can this helper establish its own ordinary App Sandbox? What supported mechanism or guarantee establishes that the sandbox is effective before the subject metadata operation? Required metadata permissions: Does the proposed read-only exception support fstat and the specified extended-security fgetattrlist request through an inherited read-only descriptor, for both regular files and directories? Please distinguish descriptor survival from permission to perform these operations, including any additional access-control conditions. Scope, identity and lifetime: What documented behaviour applies to descendant coverage, aliases, hard links, renames or namespace changes after the descriptor was opened? Please distinguish the lifetime of the inherited object reference from the lifetime of the static directory permission. Our design would refuse uncertainty rather than reopen, rebind or widen access. Evidence and support boundary: Which public documentation, interfaces or authoritative guarantees support this exact composition, and which parts require separate empirical qualification? Please identify applicable macOS versions and restrictions. Distinguish platform support from any distribution or App Store review requirements. If these requirements cannot be combined through supported interfaces, please identify the incompatible requirement. An approach requiring broader access, pathname reopening, a replacement object or a different handoff architecture would be a design change requiring separate review, not a solution within the stated constraints. Permission failures, unsupported requests and incomplete metadata would remain unavailable results. They would not be interpreted as proof that an ACL is absent. Complete ACL-absence interpretation and native resource bounds remain separate qualification questions. Apple material already reviewed Resolving App Sandbox Inheritance Problems App Sandbox Temporary Exception Entitlements Accessing files from the macOS App Sandbox

I’m investigating a macOS Keychain access-control question involving an existing generic-password item and a separately code-signed application. The requirement is to authorize the application to access the existing item while preserving all previously authorized applications, partition-list entries, and other security restrictions. The item must remain in its existing Keychain. Recreating, replacing, or migrating it is not acceptable. My understanding is that legacy trusted-application ACLs and Keychain partition lists can impose separate restrictions, and that modifying one does not necessarily preserve or satisfy the other. I would appreciate clarification on four questions: Is there a supported macOS API for adding one trusted application to an existing generic-password item’s ACL while preserving all other ACL entries and restrictions? Is there a supported API for modifying an existing item’s partition list without replacing or inadvertently broadening its existing authorization policy? After making these changes, is there a supported method to independently enumerate and verify the complete resulting ACL and partition-list policy, rather than relying solely on a successful access attempt? If complete independent verification is not supported, what approach does Apple recommend for safely extending access to an existing Keychain item without weakening its current protections? The goal is a narrowly scoped, auditable authorization change, not a general relaxation of Keychain security. I’m particularly interested in the distinction between what macOS technically permits and what Apple officially supports for production applications. Thank you for any guidance or relevant documentation.

I'm evaluating a macOS file-based Keychain ACL that should authorize one application identity, defined by an intended code-signing requirement. The application is a shared Python interpreter; I understand that trusting it does not restrict access to an individual script. I read the related Apple Developer Forums discussion, which explains that complete ACL introspection is not supported and that the stored trusted-application code-signing requirement is accessible through SPI rather than public API. My narrower question is whether there is a supported verification operation that does not require exposing that requirement: Given a SecTrustedApplicationRef obtained through SecACLCopyContents, can a public API establish that its stored caller-matching requirement is no broader than the intended application requirement? Confirming that the intended application is accepted would establish only that it matches, not that additional application identities are excluded. I also don't want to assume that CFEqual against a newly created reference, matching paths, or matching SecTrustedApplicationCopyData results proves equivalent authorization. Apple's documentation describes the CopyData result as opaque. If this comparison is unsupported, what documented provisioning or operating-system enforcement guarantees should an application rely on instead? Is controlled provisioning the intended boundary, or is a different supported Keychain design appropriate? Most importantly, if verifying the exact trusted-application restriction isn't supported, what is Apple's recommended secure approach for allowing a local Python trading application to retrieve Keychain credentials without granting access to every script using the same Python interpreter? A fake-only example using a disposable test Keychain and synthetic generic-password item has been prepared but has not been built or run because full Xcode was unavailable. This is an API-contract question; no runtime failure or ACL attack is claimed, and no assumption is made that published source exactly matches the installed framework.

Our app's Sign in with Apple never completes. Apple's create-account sheet renders fully (name + share/hide-my-email step), then the final server submit fails and shows the "Sign Up Not Completed" sheet. The authorization callback returns ASAuthorizationError.canceled (1001) with no userInfo — even though the user did not cancel. Reproduced on multiple physical devices and multiple Apple IDs (all with 2FA), on iOS 26.5.1, since our first build. Team ID: 24XS837728 App ID: C54N9Q226H (bundle com.sucsessmaperrs.careerAssessmentApp) Verified on our side: com.apple.developer.applesignin = [Default] present in the distribution build (codesign -d --entitlements); embedded profile is the explicit App Store profile for the App ID (not wildcard). App ID has Sign in with Apple enabled as a primary App ID; capability deleted + recreated via the App Store Connect API today, no change. Firebase consumes the identity token; the failure is in Apple's UI before our code runs. App Store Connect agreements are clean. Key isolating fact: the same Apple ID on the same device completes a first-time Sign in with Apple sign-up in other third-party apps — only ours fails. So the cause appears scoped to our App ID / team on Apple's side, not the device, the Apple ID, 2FA, or our client code. This matches the widespread server-side "Sign Up Not Completed" failure in thread 675756 — same signature: multiple devices/Apple IDs, no console error, the failure delegate surfacing only as "cancel", newly created apps affected, even Apple's own sample app failing — which Apple ultimately resolved server-side (with a recurrence reported June 2025). Note this is the native ASAuthorizationController flow, not the REST/web flow, so the query-parameter percent-encoding fix from thread 122458 does not apply here. Could an Apple engineer check the server-side Sign in with Apple / account-association state for App ID C54N9Q226H (Team 24XS837728)? Happy to provide a screen recording or sysdiagnose.

I'm evaluating a macOS file-based Keychain ACL that should authorize one application identity, defined by an intended code-signing requirement. The application is a shared Python interpreter; I understand that trusting it does not restrict access to an individual script. I read the related Apple Developer Forums discussion, which explains that complete ACL introspection is not supported and that the stored trusted-application code-signing requirement is accessible through SPI rather than public API. My narrower question is whether there is a supported verification operation that does not require exposing that requirement: Given a SecTrustedApplicationRef obtained through SecACLCopyContents, can a public API establish that its stored caller-matching requirement is no broader than the intended application requirement? Confirming that the intended application is accepted would establish only that it matches, not that additional application identities are excluded. I also don't want to assume that CFEqual against a newly created reference, matching paths, or matching SecTrustedApplicationCopyData results proves equivalent authorization. Apple's documentation describes the CopyData result as opaque. If this comparison is unsupported, what documented provisioning or operating-system enforcement guarantees should an application rely on instead? Is controlled provisioning the intended boundary, or is a different supported Keychain design appropriate? Most importantly, if verifying the exact trusted-application restriction isn't supported, what is Apple's recommended secure approach for allowing a local Python trading application to retrieve Keychain credentials without granting access to every script using the same Python interpreter? A fake-only example using a disposable test Keychain and synthetic generic-password item has been prepared but has not been built or run because full Xcode was unavailable. This is an API-contract question; no runtime failure or ACL attack is claimed, and no assumption is made that published source exactly matches the installed framework.

I’m preparing an update to a native macOS serial logger already distributed through the Mac App Store. The app uses IOSerialBSDClient to enumerate serial ports, opens the selected /dev/cu.* device with open(O_RDWR | O_NOCTTY | O_NONBLOCK), and configures it with termios. On macOS 27.2, open() returns EPERM with App Sandbox enabled and the USB and Bluetooth entitlements present. The same port opens successfully from a process without App Sandbox. I reproduced this with several adapters. Apple’s archived Entitlement Key Reference lists com.apple.security.device.serial and describes adding it manually: https://developer.apple.com/library/archive/documentation/Miscellaneous/Reference/EntitlementKeyReference/Chapters/EnablingAppSandbox.html The macOS 27.2 App Sandbox profile still contains a rule for this entitlement, but I couldn’t find it in the current entitlement documentation or in Xcode 27.2’s Signing & Capabilities editor. Is adding com.apple.security.device.serial manually to the app’s signed entitlements still the supported approach for new Mac App Store updates? Does it require separate approval or provisioning authorization? If this entitlement is no longer supported for Mac App Store submissions, what does Apple recommend for accessing system-provided BSD serial ports with App Sandbox enabled? The app needs to work with ports exposed by both system and third-party drivers and configure them through termios. Would a temporary file access exception for /dev/ be appropriate for this use case?

What we're trying to do We ship a Developer-ID authorization plugin (a SecurityAgent AuthorizationPlugin bundle exporting AuthorizationPluginCreate, hosting an SFAuthorizationPluginView subclass) that presents custom credential + MFA UI at macOS authentication surfaces — the Jamf Connect / NoMAD / XCreds pattern. This works correctly at the login window (system.login.console). We now want the same custom UI at the active-session lock screen (screensaver unlock), so a managed user can satisfy an MFA step on unlock — without MDM. We understand Platform SSO is the MDM-based path; we're specifically asking about the non-MDM AuthorizationPlugin path, which Cisco Duo and RSA appear to ship on macOS 14/15. Environment macOS Sonoma 14.8.7 and Sequoia 15.7.7 / 15.7.9, Apple Silicon (arm64). Non-MDM. Standard Developer ID distribution, no configuration profiles. Plugin bundle: Developer ID Application + Hardened Runtime (flags=runtime), satisfies its DR, notarized. Bundle has an empty NSPrincipalClass and no NSMainNibFile; construction follows the NameAndPassword DTS sample exactly (alloc the SFAuthorizationPluginView subclass via -initWithCallbacks:andEngineRef: in MechanismInvoke, then -displayView). Reproduction Install the plugin into /Library/Security/SecurityAgentPlugins/. Define a custom right (class = evaluate-mechanisms, mechanisms = [ OurPlugin:invoke ]) — we do not replace the screensaver rule. Append that right to the existing rule, keeping use-login-window-ui: system.login.screensaver (class = rule): rule = [ use-login-window-ui, com.example.screensaver-mfa ] (This "append after use-login-window-ui" arming matches what Cisco Duo's installer does — native password unlock runs first, then the appended mechanism runs in the post-password phase.) Lock, then unlock. What we observe Our mechanism is invoked at unlock (MechanismInvoke runs — so the arming is correct; the modern path otherwise never invokes third-party plugins). But inside MechanismInvoke, on the main thread, in SecurityAgentHelper-arm64: host check: AgentPluginViewHelper = PRESENT // we're in the SecurityAgent GUI host probe: callbacks->version = 4, GetHintValue = <ptr> // engine callbacks, unmodified probe: authorize-right PRESENT rc=0 val=system.login.screensaver presenter alloc'd p = 0x0 (nil = 1) // init returns nil -[SFAuthorizationPluginView initWithCallbacks:andEngineRef:] returns nil. Every downstream symptom we'd chased earlier (black screen, spinner, "ViewBridge … Connection invalid") is just a consequence of there being no view object. What we've ruled out Tracing the construction path (-initWithCallbacks:andEngineRef: → -loadPlugin → [AgentPluginViewHelper loadPluginForRight:engineRef:pluginView:]), we've eliminated: Host process — AgentPluginViewHelper is present; we're in SecurityAgent, not authorizationhost (our UI mechanism is non-privileged). The authorize-right hint — present and correct (system.login.screensaver), read straight through callbacks->GetHintValue. Callbacks / engineRef — valid, version == 4, passed through unmodified (same pointer the engine handed us). The nib — no NSMainNibFile set. The right→product mapping — the right maps to the builtin product, whose plugin object constructs unconditionally. That leaves the display_view re-host step, which appears bound to whether this SecurityAgent instance currently has a live, connection-accepting view-hosting session. Our hypothesis: use-login-window-ui completes the native unlock and tears down its view-hosting session, so our appended mechanism runs after teardown → no live host for display_view → the builtin display mechanism's init fails → SFAuthorizationPluginView init returns nil. The experiment that should have fixed it — but didn't The vendor that ships this (Duo) brackets its non-privileged GUI mechanism with a leading privileged mechanism (and a trailing one). A privileged mechanism runs in authorizationhost; we hypothesized the privileged→non-privileged transition makes authd re-activate SecurityAgent and stand up a fresh view-hosting session before the GUI mechanism runs. We mirrored exactly that: [ OurPlugin:precheck,privileged, OurPlugin:invoke, OurPlugin:complete,privileged ] where precheck/complete are no-op privileged mechanisms that just SetResult(allow). The logs confirm the transition happened: precheck ran in authorizationhosthelper, then invoke ran in a freshly spawned SecurityAgentHelper process (so SecurityAgent did re-activate), with AgentPluginViewHelper present and the hint correct — yet SFAuthorizationPluginView init still returned nil. So replicating the vendor's authorizationdb structure is not sufficient. The remaining difference is either an OS precondition that simply isn't met during a locked-session unlock (the agent isn't accepting view-hosting connections in that context), or something in the vendor's bundle/build (entitlements, embedded XPC/frameworks) rather than the authdb wiring. Questions Is presenting a custom SFAuthorizationPluginView at the active-session lock screen a supported scenario for a non-MDM Developer-ID authorization plugin on macOS 14/15? If yes — what is the supported way to ensure a live view-hosting session exists for a mechanism appended to system.login.screensaver after use-login-window-ui? Is the leading-privileged-mechanism pattern intended, or is there a documented right/API we should use? If SFAuthorizationPluginView init returning nil in this context is expected, please confirm and point us to the sanctioned alternative for custom credential UI at screensaver unlock without MDM. Does any of this differ on Managed vs. non-Managed devices, or depend on SIP / FileVault / Secure Enclave state? References Forums 110667 — use-login-window-ui blocks third-party plugins; legacy path invokes them ("not a bug"). Forums 744211, 771114 — SFAuthorizationPluginView / ViewBridge / viewForType: never called at the lock screen on macOS 15. Feedback FB13238136, FB13128730 — third-party plugin at the lock shield; Data-Protection keychain from screensaver context. Sample code: NameAndPassword — our construction shape matches it exactly. I can provide a minimal reproducer bundle and a sysdiagnose + unified-log capture around a failed unlock on request.

In our macOS Redirect SSO extension, initiatorOrigin is empty in the authorization options received in beginAuthorization(with:). The corresponding AppSSOAgent log shows: localhost AppSSOAgent[55733]: (AppSSOUI) [com.apple.AppSSO:SOAgent] -[SOAgent beginAuthorizationWithRequestParameters:completion:] { AuthorizationOptions = { initiatingAction = 0; initiatorOrigin = ""; path = ""; userActionInitiated = 1; };Is this expected behavior for certain SSO requests, or could this indicate an issue in macOS 27?

We are developing a macOS Redirect SSO extension and observing an empty initiatorOrigin in the authorization options received in beginAuthorization(with:). The corresponding AppSSOAgent log shows: localhost AppSSOAgent[55733]: (AppSSOUI) [com.apple.AppSSO:SOAgent] -[SOAgent beginAuthorizationWithRequestParameters:completion:] { AuthorizationOptions = { initiatingAction = 0; initiatorOrigin = ""; path = ""; userActionInitiated = 1; };Is this expected behavior for certain SSO requests, or could this indicate an issue in macOS 27?

We are developing an Apple Watch and iPhone training app and would like guidance on the required-reason API requirements for sharing a timing relationship between the two apps. On Apple Watch, we record Core Motion samples and read ProcessInfo.processInfo.systemUptime when each sample callback arrives. The paired iPhone uses timing information to analyze sample ordering and freshness. The two values relevant to this question are: Measurement timestamp: CMLogItem.timestamp associated with the Core Motion sample on Apple Watch. Callback observation time: systemUptime read by the Watch app when it receives that sample’s callback. The proposed interval is the callback observation time minus the measurement timestamp, calculated on the Watch. Both endpoints are on the Watch. The iPhone is the intended recipient of the interval; its receipt time is not an endpoint of this calculation. For illustration only, synthetic values of 1,000.000 seconds for the measurement timestamp and 1,000.020 seconds for the callback observation time would produce a proposed interval of 0.020 seconds. These are not real measurements. This arithmetic example does not establish clock compatibility or permission to transmit the result. Apple’s documentation describes CMLogItem.timestamp as seconds since device boot. The System Boot Time required-reason API list includes systemUptime and mach_absolute_time(). Reason 35F9.1 permits certain elapsed-time measurements and includes an exception for elapsed time between events that occurred within the app. Our questions are: Is CMLogItem.timestamp itself covered by the System Boot Time required-reason API category? We do not see this property explicitly included in the published list. Under reason 35F9.1, may the interval between a Core Motion measurement timestamp and the app’s callback observation time be sent from Apple Watch to its paired iPhone for analysis? Specifically, does it qualify for the exception for elapsed time between events that occurred within the app, given that the measurement time comes from Core Motion? If not, is there an approved way to represent this timing relationship while preserving sample ordering and freshness analysis? Which timing information may be transferred, and which approved reason, if any, applies? We are not reporting an Apple API malfunction. We are asking how to implement this use in accordance with the privacy requirements. Our focused local Xcode sample uses synthetic values only. It does not collect real motion data or transmit data between devices.

Developed an app and run it, now I see Autofill (app name) in activity monitor. Please help! I am using opensource libraries. My other developed apps does not show autofill (app name) and it uses the same libs. The differences with the 2 is that the one with the problem uses: assimp, and freetype 2. Is this a security risk? I am thinking maybe if i run this app in sudo mode it will autofill and reveal my password to hackers. What is the best way to mitigate this?

Hello, We are investigating the new annual ATT reprompting behavior introduced in iOS 27.2 for EU users. Apple's documentation states that developers can request ATT authorization again one year after the user's previous choice. However, we would like to clarify how this applies to existing ATT decisions made before iOS 27.2. Questions Previous ATT decisions older than 12 months If a user denied ATT permission in March 2025 on an earlier iOS version and upgrades to iOS 27.2 in November 2026, can the app immediately display the ATT prompt again? Previous ATT decisions less than 12 months old If a user denied ATT permission in June 2026, will the next ATT prompt become available in June 2027, or does the 12-month period start from the installation of iOS 27.2? Historical ATT decision timestamps Does iOS maintain the original timestamp of ATT decisions made on previous iOS versions, or does the new annual reprompting mechanism only track decisions recorded from iOS 27.2 onwards? Reprompt eligibility API Is there any public API that allows developers to determine whether a user is eligible for an ATT reprompt, without actually attempting to display it? Context This is particularly important for existing applications and Consent Management Platforms (CMPs), where we need to coordinate ATT authorization with GDPR consent flows. Understanding whether the 12-month interval applies retroactively to existing ATT decisions would help us implement the new behavior correctly without unnecessarily prompting users or disrupting existing consent flows. Thank you for your clarification

I am trying to fix an expired TestFlight build, which requires an update. However, when I attempt to log in to my developer account, I get stuck at the mobile phone authentication step. Although I have entered the correct phone number, the verification code never arrives on my device—even after multiple attempts—and the phone-based authentication option itself is not working. What should I do?

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.

Hi Apple Developer Technical Support, We have a locally signed macOS system daemon that an administrator starts manually. It needs to use a dedicated P-256 signing key in a file-based keychain. We want macOS to let only the exact approved build use that key, without a prompt. A different build signed with the same certificate should be denied. Apple’s published Security source shows that the keychain can identify some callers by their code directory hash (cdhash). Is setting a key’s partition list to that exact hash a supported way to enforce this restriction for a system daemon? If so, which macOS versions support it, and what API or Apple tool should we use to configure it? After setup, how can we verify that the intended key has the exact restriction in place, including whether any broader rule allows another process to sign with the key, export it, or change its access rules? If macOS doesn’t offer a supported way to set and verify this restriction, please confirm that limitation.