I’ve developed an authorization plug-in with a mechanism that runs an SFAuthorizationPluginView subclass and I’m facing a couple issues: - Glitch after successful login After setting kAuthorizationResultAllow in the context the user is successfully logged in and brought to the desktop but the login controls remain onscreen for a few seconds after login is complete, resulting in them being visible at the same time as the dock, menu bar and desktop.
 I’ve also tried what’s mentioned here https://developer.apple.com/forums/thread/780212 but without any luck. It’s also worth mentioning that the deinit() in my SFAuthorizationPluginView subclass never gets called when the plugin it’s loaded at the login stage but it does get called the plugin is used to re-authenticate the user after they locked their screen. - update() doesn't trigger the plugin to call view(for:) I’m trying to update the UI elements out of my control (like buttons and user avatar images) in order to have them placed at the proper position on the screen after a resize of my inner NSView. To do that I call update() but it appears that does not trigger the plugin to call view(for:) and update system UI elements placement. Is this the expected behavior? - setButton not working as expected 
I’m trying to disable the login button by calling the setButton(_:enabled:) passing a SFButtonTypeLogin as inButtonType, as suggested here: https://developer.apple.com/forums/thread/777432. When the method is called at the login screen it has no effect on the button (the one with the forward-arrow icon) but when it’s called by the plugin loaded at the ‘unlock screen’ stage it successfully disable the ‘OK’ button. - Certificate issue When trying to run a network request from the plugin loaded in the ‘unlock screen’ scenario, I always get this type of error: The certificate for this server is invalid. You might be connecting to a server that is pretending to be <<server_url>> which could put your confidential information at risk Everything works as expected when the plugin is loaded either at login screen or for authorizing an operation that requires admin privileges while the user is logged in.

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.

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 am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM. The Setup: Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain. Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted. The Goal: I need to use the private key from the identity to be able to sign the data The Problem: The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths. As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired. What i've tried so far: Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution. Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless. The Question: Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? If not, is there a better way to achieve the end goal?

Hello everyone. Hope this one finds you well) I have an issue with integrating a FIDO2 server with ASAuthorizationController. I have managed to register a user with passkey successfully, however when authenticating, the request for authentication response fails. The server can't validate signature field. I can see 2 possible causes for the issue: ASAuthorizationPlatformPublicKeyCredentialAssertion.rawAuthenticatorData contains invalid algorithm information (the server tries ES256, which ultimately fails with false response), or I have messed up Base64URL encoding for the signature property (which is unlikely, since all other fields also require Base64URL, and the server consumes them with no issues). So the question is, what encryption algorithm does ASAuthorizationController use? Maybe someone has other ideas regarding where to look into? Please help. Thanks)

I’m having an issue with my Credential Provider Extension for passkey registration. On the browser I click on registration, in IOS i can select my App for passkey registration with a continue button. Wenn I click the continue button the prepareInterface(forPasskeyRegistration:) function is called but the MainInterface is not shown —it only appears when I click the continue button a second time. Here’s a simplified version of my prepareInterface method: override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { guard let request = registrationRequest as? ASPasskeyCredentialRequest, let identity = request.credentialIdentity as? ASPasskeyCredentialIdentity else { extensionContext.cancelRequest(withError: ASExtensionError(.failed)) return } self.identity = identity self.request = request log.info("prepareInterface called successfully") } In viewDidAppear, I trigger FaceID authentication and complete the registration process if register is true. However, the UI only shows after a second “Continue” tap. Has anyone encountered this behavior or have suggestions on how to ensure the UI appears immediately after prepareInterface is called? Could it be a timing or lifecycle issue with the extension context? Thanks for any insights!

Hi Apple Developer Support, I’m building a macOS app that acts as a default browser. I can confirm that I can set it correctly through System Settings → Default Web Browser. The app implements ASWebAuthenticationSessionWebBrowserSessionHandling to intercept Single Sign-On (SSO) flows. To handle requests, it presents SSO pages in a WKWebView embedded in a window that this app creates and owns - this works perfectly for the initial login flow. However, after I close my WebView window and then launch Safari or Chrome, any subsequent SSO requests open in the newly-launched browser instead of my custom browser, even though it remains selected as the default in System Settings. I’d appreciate any insight on why the system “hands off” to Safari/Chrome in this scenario, and how I can keep my app consistently intercepting all ASWebAuthenticationSession requests. Here are the steps that break down the issue: Launch & confirm that the custom default browser app is the default browser in System Settings → Default Web Browser. Trigger SSO (e.g., try to log in to Slack). App’s WKWebView appears, and the SSO UI works end-to-end. Close the WebView window (I have windowShouldClose callback where I cancel the pending session). Manually launch Safari or Chrome. Trigger SSO again. Observed behaviour: the login URL opens in Safari/Chrome. I am using macOS 15.3.2

We use Jamf Blueprint to deploy the managed app and identity to the iOS device (iOS 26.3 installed). Our managed app can access the identity via let identityProvider = ManagedAppIdentitiesProvider() let identity: SecIdentity do { identity = try await identityProvider.identity(withIdentifier: "myIdentity") } catch { } However, the app extension cannot access the same identity. Our app extension is notification extension that implemented UNNotificationServiceExtension APIs. We use above code in didReceive() function to access identity that always failed. The MDM configuration payload is: "AppConfig": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] }, "ExtensionConfigs": { "Identifier (com.example.myapp.extension)": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] } }, "ManifestURL": "https://example.net/manifest.plist", "InstallBehavior": { "Install": "Required" } } Is there any problem in our MDM configuration? Or the notification extension cannot integrate with ManagedApp FM?

Title: Sporadical - Permissions Not Cleared After App Uninstallation on iOS18 I install and launch my private MAUI App I ask for example Bluetooth permissions (can be any other permission) I tap Allow button on native settings (or Don't Allow) I unistall app from real phone (we can wait for a while) I install and launch My Private MAUI App I ask for example Bluetooth permissions &lt;- here is an issue. Bluetooth is already granted, so I cannot ask for it again. Occurrence: This issue occurs inconsistently: On iOS 18.5: approximately 5 out of 10 times On iOS 17: approximately 1 out of 50 times Tested using my automated system using Appium latest. After each scenario I unistall app using: "mobile: removeApp" with bundleId

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?

I am trying to setup remote Java debugging between two machines running macOS (15.6 and 26). I am able to get the Java program to listen on a socket. However, I can connect to that socket only from the same machine, not from another machine on my local network. I use nc to test the connection. It reports Connection refused when trying to connect from the other machine. This issue sounds like it could be caused by the Java program lacking Local Network system permission. I am familiar with that issue arising when a program attempts to connect to a port on the local network. In that case, a dialog is displayed and System Settings can be used to grant Local Network permission to the client program. I don't know whether the same permission is required on the program that is receiving client requests. If it is, then I don't know how to grant that permission. There is no dialog, and System Settings does not provide any obvious way to grant permission to a program that I specify. Note that a Java application is a program run by the java command, not a bundled application. The java command contains a hard-wired Info.plist which, annoyingly, requests permission to use the microphone, but not Local Network access.

When an app is trying to access identities put in the keychain by cryptotokenkit extension, the user gets asked a permission pop-up which reads 'Token Access Request" would like access a token provided by: " with 2 options 'Don't allow' and 'OK' I accidently clicked "Don't allow" and now can't access identities put in crypto token kit. How can I reset the preference?

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?

There’s a critical, actively exploited vulnerability in Apple’s iOS activation servers allowing unauthenticated XML payload injection: https://cyberpress.org/apple-ios-activation-vulnerability/ This flaw targets the core activation process, bypassing normal security checks. Despite the severity, it’s barely discussed in public security channels. Why is this not being addressed or publicly acknowledged? Apple developers and security researchers should urgently review and audit activation flows—this is a direct attack vector on device trust integrity. Any insights or official response appreciated.

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!

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!

I’m implementing passkey registration and authentication in an iOS 17 app with a credential provider extension, but I’m running into an issue. Setup: I have a credential provider target configured. The app correctly shows the pop-up to register the passkey with my app. My Info.plist is set up properly. Issue: When the following function is triggered: override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { "code to generate registrationRequest..." let controller = ASAuthorizationController(authorizationRequests: [registrationRequest]) controller.delegate = self controller.presentationContextProvider = self controller.performRequests() } I get the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 I do not own the relying party domain (e.g., https://webauthn.io), so I cannot configure an apple-app-site-association file on the website. Question: How can I register and authenticate passkeys on any site that allows passkeys (such as webauthn.io) when I don’t control the webpage? Are there any workarounds or best practices for handling this in iOS 17? Any insights would be greatly appreciated!

Hi, We are using the MSAL library to authenticate users, with SSO authentication implemented through the Microsoft Authenticator app. The problem is that once or twice a day, a prompt for forced authentication appears, indicating that silent token acquisition is failing and resulting in a requirement for forced authentication. Below are some of the logs: ================================================= 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] Silent flow finished. Result (null), error: -51115 error domain: MSIDErrorDomain 2025-08-28 11:00:05.034 [Info] [AppDelegate.swift:121] application(:didFinishLaunchingWithOptions:) > MSAL message: TID=751353 MSAL 1.8.1 iOS 18.5 [2025-08-28 10:00:05 - EC9D1457-2D70-4878-926F-553391EBC9D3] [MSAL] acquireTokenSilent returning with error: (MSALErrorDomain, -50002) Masked(not-null) ==================================================== We initially raised this issue with Microsoft, but according to them: In the app's logs, the single one failure it contains, was when the SSO extension returned the error com.apple.AuthenticationServices.AuthorizationError, -6000 during a silent call. This error code is generated by the system framework (Apple), not by our code. It indicates that the framework encountered an unexpected internal issue before or after calling the SSO extension. MSAL returning interaction_required to the client app is the most effective way to recover from this error (as you mention, after the user selects the account the app continues working as expected). Additionally, as you also mention, the interactive call is made by switching to Authenticator (not displaying a "window" without leaving Eva Lite app), which means MSAL is not able to use the SSO extension and is using the fallback to legacy authentication. The recommended next step is for the customer to request support directly from Apple as this is an issue on their side. Additionally, the customer can also try to update to the latest iOS, in case Apple has already fixed this issue. ============================================= STEPS TO REPRODUCE There is no such steps its just that this is an enterprise application which is getting used on managed devices[iPhone 14]. The device are managed using some intune policy. Platform and Version: iOS Development Environment: Xcode 15, macOS 13.6.1 Run-time Configuration: iOS 18 Please let me know if there are any solutions to resolve this problem. Thank you.

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!