I'm working on integrating Passkey functionality into my iOS app (targeting iOS 16.0+), and I'm facing an issue where the system dialog still shows the "Save to another device" option during Passkey registration. I want to hide this option to force users to create Passkeys only on the current device. 1. My Current Registration Implementation Here’s the code I’m using to create a Passkey registration request. I’ve tried to use ASAuthorizationPlatformPublicKeyCredentialProvider (which is supposed to target platform authenticators like Face ID/Touch ID), but the "Save to another device" option still appears: `// Initialize provider for platform authenticators let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: domain) // Create registration request let registrationRequest = provider.createCredentialRegistrationRequest( challenge: challenge, name: username, userID: userId ) // Optional configurations (tried these but no effect on "another device" option) registrationRequest.displayName = "Test Device" registrationRequest.userVerificationPreference = .required registrationRequest.attestationPreference = .none // Set up authorization controller let authController = ASAuthorizationController(authorizationRequests: [registrationRequest]) let delegate = PasskeyRegistrationDelegate(completion: completion) authController.delegate = delegate // Trigger the registration flow authController.performRequests(options: .preferImmediatelyAvailableCredentials)` 2. Observation from Authentication Flow (Working as Expected) During the Passkey authentication flow (not registration), I can successfully hide the "Use another device" option by specifying allowedCredentials in the ASAuthorizationPlatformPublicKeyCredentialAssertionRequest. Here’s a simplified example of that working code: let assertionRequest = provider.createCredentialAssertionRequest(challenge: challenge) assertionRequest.allowedCredentials = allowedCredentials After adding allowedCredentials, the system dialog no longer shows cross-device options—this is exactly the behavior I want for registration. 3. My Questions Is there a similar parameter to allowedCredentials (from authentication) that I can use during registration to hide the "Save to another device" option? Did I miss any configuration in the registration request (e.g., authenticatorAttachment or other properties) that forces the flow to use only the current device’s platform authenticator? Are there any system-level constraints or WebAuthn standards I’m overlooking that cause the "Save to another device" option to persist during registration? Any insights or code examples would be greatly appreciated!

Hi everyone, I'm currently working on a native macOS app (built with SwiftUI) and I'm trying to implement Password AutoFill functionality so users can use their saved credentials from Keychain or third-party password managers. I've gone through Apple's documentation, WWDC sessions, and sample code, but I've noticed that the resources primarily focus on iOS and web implementations. There's very limited guidance specifically for macOS. I've set up: Associated Domains entitlement with the webcredentials: service The apple-app-site-association file on my server TextField with .textContentType(.username) and SecureField with .textContentType(.password) However, I'm still not seeing the expected AutoFill behavior on macOS like I would on iOS. Has anyone successfully implemented Password AutoFill on a native macOS app? Are there any macOS-specific considerations or additional steps required that differ from iOS? Any guidance, sample code, or pointers to documentation I might have missed would be greatly appreciated.

Hi, We are implementing Platform SSO and using attestKey during registration via ASAuthorizationProviderExtensionLoginManager. Could you clarify whether the attestKey flow involves sending attestation data to an Apple server for verification (similar to App Attest in the DeviceCheck framework), or if the attestation certificate chain is generated and signed entirely on-device without any Apple server interaction? The App Attest flow is clearly documented as using Apple’s attestation service, but the Platform SSO process is less clearly described. Thank you.

To use passkeys, you need to place the correct AASA file on the web server and add an entry in the Entitlements.plist, for example webcredentials:mydomain.com. This is clear so far, but I would like to ask if it's possible to set this webcredentials in a different way in the app? The reason for this is that we are developing a native app and our on-premise customers have their own web servers. We cannot know these domains in advance so creating a dedicated app for each customer is not option for us. Thank you for your help!

Hello, I’m storing some values in the Keychain with the attribute ‘ksecattraccessibleafterfirstunlockthisdeviceonly’ (https://developer.apple.com/documentation/security/ksecattraccessibleafterfirstunlockthisdeviceonly). When I migrate user data between iPhones via iCloud, this behaves as expected and the keys are not preserved. However, when I migrate using a direct connection between two devices, the keys are preserved, which seems to contradict the attribute’s intent. Is this a known behavior, and if so, is there a workaround?

We are developing an app that uses Authentication Services to authenticate users. According to the documentation, this framework will open the default web browser if it supports auth session handling, and Safari otherwise. This is not entirely true, and users will be frustrated! macOS version: Sequoia 15.5; Safari version: 18.5. When: The default browser is not Safari, and supports auth session handling (Google Chrome and Microsoft Edge as examples); and - The Safari app is already running; The auth flow will: Present the confirmation dialog box with the default browser icon. Good! Open a Safari window, instead of the default browser's one. Bad! Respond with "User Cancelled" error to the app, after making the end user believe the auth was good. Very Bad!! If the app retries the auth session, the default browser window will open as expected, and it will work as expected. However, requiring users to authenticate twice is a very bad users experience... This issue does not reproduce, when either: Safari is not running at the moment of auth session start; The default browser does not support auth session handling; or - Safari is the default browser. Fellow developers, be warned! Apple engineers, feedback #18426939 is waiting for you. Cheers!

I'm looking to implement USB monitoring for FIDO2 authentication through a custom Authorization Plugin, specifically for the below ones. This plugin applies to the following macOS authorization mechanisms: system.login.console — login window authentication system.login.screensaver — screensaver unlock authentication The goal is to build a GUI AuthPlugin, an authorization plugin that presents a custom window prompting the user to "Insert your FIDO key”. Additionally, the plugin should detect when the FIDO2 device is removed and respond accordingly. Additional Info: We have already developed a custom authorization plugin which is a primary authentication using OTP at login and Lock Screen. We are now extending to include FIDO2 support as a primary. Our custom authorization plugin is designed to replace the default loginwindow:login mechanism with a custom implementation. Question: Is there a reliable approach to achieve the USB monitoring functionality through a custom authorization plugin? Any guidance or pointers on this would be greatly appreciated.

Hello, I am using the prf extension for passkeys that is available since ios 18 and macos15. I am using a fixed, hardcoded prf input when creating or geting the credentials. After creating a passkey, i try to get the credentials and retrieve the prf output, which works great, but i am getting different prf outputs for the same credential and same prf input used in the following scenarios: Logging in directly (platform authenticator) on my macbook/iphone/ipad i get "prf output X" consistently for the 3 devices When i use my iphone/ipad to scan the qr code on my macbook (cross-platform authenticator) i get "prf output Y" consistently with both my ipad and iphone. Is this intended? Is there a way to get deterministic prf output for both platform and cross-platform auth attachements while using the same credential and prf input?

Hi, In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant. We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally. Environment iOS 26.3 Real device App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Characteristics: appears constantly affects only unique user -Don't resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)") We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier. Please, help us any guidance for solution. Thank you

Our background monitoring application uses a Unix executable that requests Screen Recording permission via CGRequestScreenCaptureAccess(). This worked correctly in macOS Tahoe 26.0.1, but broke in 26.1. Issue: After calling CGRequestScreenCaptureAccess() in macOS Tahoe 26.1: System dialog appears and opens System Settings Our executable does NOT appear in the Screen Recording list Manually adding via "+" button grants permission internally, but the executable still doesn't show in the UI Users cannot verify or revoke permissions Background: Unix executable runs as a background process (not from Terminal) Uses Accessibility APIs to retrieve window titles Same issue occurs with Full Disk Access permissions Environment: macOS Tahoe 26.1 (worked in 26.0.1) Background process (not launched from Terminal) Questions: Is this a bug or intentional design change in 26.1? What's the recommended approach for background executables to properly register with TCC? Are there specific requirements (Info.plist, etc.) needed? This significantly impacts user experience as they cannot manage permissions through the UI. Any guidance would be greatly appreciated. Thank you

Why can’t sandboxed mac app store apps have full disk access available in the system settings for full disk access? I discovered mac app store apps in release mode cannot access the ai auggie command line program and other command line programs like opengrep on your system. Debug builds fine. I came up with a workaround: Since I have an ssh client built in for connecting to remote servers, why not connect to ssh on the same local machine… Ask the user for their username and password in a popup. To do this, you have to enable remote login on your mac in system settings -> sharing. In addition you must grant full disk access to cli ssh in system settings: add /usr/libexec/sshd-keygen-wrapper It all works, but I don’t see the cli program in mac settings. To remove the cli program you must run a command line program to remove all full disk access support from all apps. No way to just undo ssh. So my question is, even though I got CodeFrog all working for a mac app store release, should I not do it because it’s insecure or too complicated with the system settings? Should I instead sell the app off the store like Panic Nova? Need some advice. I have not implemented in app purchases yet. Should I just have a reality check and sell the app off the store, or try for app store approval? Bummer… Maybe I’m ahead of my time, but perhaps Apple could review the source code for apps requesting full disk access and make sure there’s nothing fraudulent in them. Then, developer tools app store apps could be in the store with the user’s assurance that nothing is happening behind the scenes that is scary. From: https://blog.greenrobot.com/2025/11/10/i-have-a-decision-to-make/ Related post: https://developer.apple.com/forums/thread/806187 I submitted a code level tech support question for this. They directed me here.

I have filed bug reports on this to no avail, so I am bringing it up here hoping someone at Apple will address this. Since the first beta of 26.3, with voice control enabled there are now two icons in the menu bar (*plus an orange dot in full screen) that never go away. That orange microphone isn't serving its intended purpose to notify me that something is accessing my microphone if it is always displayed. I use voice control extensively, so it is nearly always on. In every prior version of macOS, the orange icon was not on for voice control. Even if voice control is not listening but simply enabled in system settings, the orange icon will be there. And there is no need for this icon to be on for a system service that is always listening. This orange icon in the menu bar at all times is incredibly irritating, as it takes up valuable space to the right of the notch, and causes other actual useful menu bar items to be hidden. As well, if some other application on my system were to turn on the mic and start recording me I would never know since that orange icon is always on. It also places an orange dot next to the control center icon taking up even more of the precious little menu bar real estate. Please fix this! Either exempt voice control (as Siri is always listening and it doesn't get the orange icon) or exempt all system services, or give me a way to turn this off. If you cannot tell, I find this incredibly annoying and frustrating.

Hi, I'm using webauthn.io to test my macOS Passkey application. When registering a passkey whichever value I set for User Verification, that's what I get when I check registrationRequest.userVerificationPreference on prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest). However, when authenticating my passkey I can never get discouraged UV on prepareInterfaceToProvideCredential(for credentialRequest: any ASCredentialRequest). In the WWDC 2022 Meet Passkeys video, it is stated that Apple will always require UV when biometrics are available. I use a Macbook Pro with TouchID, but if I'm working with my lid closed, shouldn't I be able to get .discouraged?

Hi, This issue is happening during Passkey creation. We’ve observed that approximately 1% of our customer users encounter a persistent error during Passkey creation. For the vast majority, the process works as expected. We believe our apple-app-site-association file is correctly configured, served directly from the RP ID over HTTPS without redirects, and is up-to-date. This setup appears to work for most users, and it seems the Apple CDN cache reflects the latest version of the file. To help us diagnose and address the issue for the affected users, we would appreciate guidance on the following: What tools or steps does Apple recommend to identify the root cause of this issue? Are there any known recovery steps we can suggest to users to resolve this on affected devices? Is there a way to force a refresh of the on-device cache for the apple-app-site-association file? Thank you in advance for any input or guidance.

I've made my first app and encountered an unexpected (potentially existential) issue. The Manager app is designed to tag 3rd party "plugins" used by a DAW, storing metadata in a local SQLite database, and move them between Active and Inactive folders. This allows management of the plugin collection - the DAW only uses what's in the Active folder. Permissions are obtained via security-scoped bookmarks on first launch. The app functions as intended: plugin bundles move correctly and the database tracks everything. No information is written to the plugins themselves. The Problem:
When moving plugins using fs.rename() , the MAS sandbox automatically adds the com.apple.quarantine extended attribute to moved files. When the DAW subsequently rebuilds its plugin cache, it interprets quarantined plugins as "corrupt" or potentially malicious and refuses to load them. Technical Details: Moving files with NSFileManager or Node.js fs APIs within sandbox triggers quarantine Sandboxed apps cannot call xattr -d com.apple.quarantine or use removexattr() The entitlement com.apple.security.files.user-selected.read-write doesn't grant xattr removal rights User workaround: run xattr -cr /path/to/plugins in Terminal - not acceptable for professional users Question:
Is there any MAS-compliant way to move files without triggering quarantine, or to remove the quarantine attribute within the sandbox? The hardened-runtime DMG build works perfectly (no sandbox = no quarantine added). Any insight appreciated!

Hello, I'm an application developer related to Apple system extensions. I developed an endpoint security system extension that can run normally before the 14.x system. However, after I upgraded to 15.x, I found that when I uninstalled and reinstalled my system extension, although the system extension was installed successfully, a system warning box would pop up when I clicked enable in the Settings, indicating a failure. I conducted the following test. I reinstalled a brand-new MAC 15.x system. When I installed my applications, the system extensions could be installed successfully and enabled normally. However, when I uninstalled and reinstalled, my system extension couldn't be enabled properly and a system warning popped up as well. I tried disabling SIP and enabling System Extension Developers, but it still didn't work. When the system warning box pops up, I can see some error log information through the console application, including an error related to Failed to authorize right 'com.apple.system-extensions.admin' by client '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] for authorization created by '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] (3,0) (-60005) (engine 179) as shown in the screenshot. The same problem, mentioned in Cannot approve some extensions in MacOS Sequoia , but there is no solution

Hello Team, We’ve recently started receiving reports from our customer base (Trellix) regarding issues with Full Disk Access (FDA) for Trellix binaries on macOS devices running Tahoe 26.1 (released on November 3, 2025). The issue occurs when users attempt to add Trellix CLI binaries under FDA to grant the required permissions; the binaries fail to appear under the FDA settings, even after selection. Upon further investigation, this appears to be a macOS 26.1–specific issue and not observed in earlier versions. Similar reports have been noted across various forums, indicating that the issue affects multiple binaries, not just Trellix: Some of the discussions on the same issue I see online. https://developer.apple.com/forums/thread/806187 https://developer.apple.com/forums/thread/806156 https://forum.logik.tv/t/macos-26-1-installation-issue-wait-before-updating/13761 https://www.reddit.com/r/MacOS/comments/1os1ph3/cant_add_anything_to_privacy_security_full_disk/ I have also logged FB21009024 for the same. We would like to understand when we can expect this to be fixed, since the issue persists even in 26.2 Beta and also whether the workaround of dragging and dropping the binaries can still be suggested?

I noticed, that even though my AutoFill Credential Provider Extension works with Safari for both Passwords and Passkeys, it doesn't work in context menus inside arbitrary textfields, meanwhile the same is true for the Apple Passwords app. This is a great hit to AutoFill productivity, as my extension is unable to fill textfields by just going to the context menu and clicking AutoFill > Passwords.. Is this a feature only available to Apple via private APIs, or is this something I can interface with? I checked and the Passwords app does use some undocumented but non-private entitlements: [Key] com.apple.authentication-services.access-credential-identities [Value] [Bool] true I also checked the responsible executable for some hints (AutoFillPanelService) however found nothing that would lead me to believe this is a public extension point. Another idea I had was trying to use a macOS Service for this, however Services in the "General" category won't show up in any context menu, only in the Application's Main Menu.

I have been trying to find a way to be able to sign some data with private key of an identity in login keychain without raising any prompts. I am able to do this with system keychain (obviously with correct permissions and checks) but not with login keychain. It always ends up asking user for their login password. Here is how the code looks, roughly, NSDictionary *query = @{ (__bridge id)kSecClass: (__bridge id)kSecClassIdentity, (__bridge id)kSecReturnRef: @YES, (__bridge id)kSecMatchLimit: (__bridge id)kSecMatchLimitAll }; CFTypeRef result = NULL; OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, (CFTypeRef *)&result); NSArray *identities = ( NSArray *)result; SecIdentityRef identity = NULL; for (id _ident in identities) { // pick one as required } SecKeyRef privateKey = NULL; OSStatus status = SecIdentityCopyPrivateKey(identity, &privateKey); NSData *strData = [string dataUsingEncoding:NSUTF8StringEncoding]; unsigned char hash[CC_SHA256_DIGEST_LENGTH]; CC_SHA256(strData.bytes, (CC_LONG)strData.length, hash); NSData *digestData = [NSData dataWithBytes:hash length:CC_SHA256_DIGEST_LENGTH]; CFErrorRef cfError = NULL; NSData *signature = (__bridge_transfer NSData *)SecKeyCreateSignature(privateKey, kSecKeyAlgorithmRSASignatureDigestPKCS1v15SHA256, (__bridge CFDataRef)digestData, &cfError); Above code raises these system logs in console default 08:44:52.781024+0000 securityd client is valid, proceeding default 08:44:52.781172+0000 securityd code requirement check failed (-67050), client is not Apple-signed default 08:44:52.781233+0000 securityd displaying keychain prompt for /Applications/Demo.app(81692) If the key is in login keychain, is there any way to do SecKeyCreateSignature without raising prompts? What does client is not Apple-signed mean? PS: Identities are pre-installed either manually or via some device management solution, the application is not installing them.

From watching the video on App Attest the answer would appear to be no, but the video is a few years old so in hope, I thought I would post this question anyway. There's several scenarios where I would like a notification service extension to be able to use App Attest in communications with the back end(for example to send a receipt to the backend acknowledging receipt of the push, fetching an image from a url in the push payload, a few others). Any change App Attest can be used in by a notification service extension?