Hi, I am working on Authorisation Plugin for Mac OS X and able to get going for most of the parts and taking inspiration from Jamf Authorisation Plugin repo https://github.com/jamf/NoMADLogin-AD. I have seen in project they are implementing logic for following. Connecting to Wifi Power management (Sleep, Restart, Power Off) Question: I was wondering these things need to be implemented or is there a way some components from Mac OS X could be integrated calling some API and I don't have to implement them and I see say a top bar where these items are viable as we see in default login screen. I have developed my own login screen and I do see it is all blank everything I have to implement from scratch. Trying luck here if any API is out there to reduce work, else no option but to implement all logic. I'll really appreciate if someone just could help me know such API's are present or not. In case there are will save lot of effort. Thanks,

In one of my apps I would like to find out if users have their device set up to authenticate with their Apple Watch. According to the documentation (https://developer.apple.com/documentation/localauthentication/lapolicy/deviceownerauthenticationwithcompanion) this would be done by evaluating the LAPolicy like this: var error: NSError? var canEvaluateCompanion = false if #available(iOS 18.0, *) { canEvaluateCompanion = context.canEvaluatePolicy(.deviceOwnerAuthenticationWithCompanion, error: &error) } But when I run this on my iPhone 16 Pro (iOS 18.5) with a paired Apple Watch SE 2nd Gen (watchOS 11.5) it always returns false and the error is -1000 "No companion device available". But authentication with my watch is definitely enabled, because I regularly unlock my phone with the watch. Other evaluations of using biometrics just works as expected. Anything that I am missing?

I am developing a custom authorization plugin for macOS, and I’ve encountered an issue where the auth plugin view remains visible on the home screen for a few seconds after login. Issue Details: After entering valid credentials, I call setResult(.allow) in my plugin to proceed with login. The authentication succeeds, and macOS starts transitioning to the home screen. However, for a few seconds after login, the authorization plugin view is still visible on the home screen before it disappears. I have observed this issue even when using Apple's sample authorization plugin. Observation: This issue occurs without an external monitor (on a single built-in display). If I manually close the plugin window inside Destroy(AuthPlugin.mechanism), then the auth plugin views do not appear on the home screen, which seems to fix the issue. However, when I do this, a gray screen appears for about a second before the desktop environment fully loads. I suspect that the gray screen appears due to the time macOS takes to fully load the home screen environment after login. Questions: Why does the authorization plugin view persist on the home screen for a few seconds after login? Is manually closing the plugin window in Destroy(AuthPlugin.mechanism) the correct way to prevent this, or is there a better approach? Is my assumption that the gray screen appears due to the home screen not being fully loaded correct? If the gray screen is caused by home screen loading, is there a system notification or event I can listen to in order to know when the home screen has fully loaded?

What Has Been Implemented Replaced the default loginwindow:login with a custom authorization plugin. The plugin: Performs primary OTP authentication. Displays a custom password prompt. Validates the password using Open Directory (OD) APIs. Next Scenario was handling password change Password change is simulated via: sudo pwpolicy -u robo -setpolicy "newPasswordRequired=1" On next login: Plugin retrieves the old password. OD API returns kODErrorCredentialsPasswordChangeRequired. Triggers a custom change password window to collect and set new password. Issue Observed : After changing password: The user’s login keychain resets. Custom entries under the login keychain are removed. We have tried few solutions Using API, SecKeychainChangePassword(...) Using CLI, security set-keychain-password -o oldpwd -p newpwd ~/Library/Keychains/login.keychain-db These approaches appear to successfully change the keychain password, but: On launching Keychain Access, two password prompts appear, after authentication, Keychain Access window doesn't appear (no app visibility). Question: Is there a reliable way (API or CLI) to reset or update the user’s login keychain password from within the custom authorization plugin, so: The keychain is not reset or lost. Keychain Access works normally post-login. The password update experience is seamless. Thank you for your help and I appreciate your time and consideration

Hi All, I have a finder sync extension that passes data back to my main app. It currently writes to a plist file in my group container folder. Since updating to macOS 15, I have been getting this pop-up every time I trigger this writing to the plist after the finder sync extension loads. This is how I write to the plist from my finder sync extension: let appGroupDefaults = UserDefaults(suiteName: "group.team_id.Finder-Sync-Extension-Test-Project") let items = FIFinderSyncController.default().selectedItemURLs() DispatchQueue.main.async { let url = items?.first?.absoluteString var file = items?.first?.lastPathComponent if let defaults = appGroupDefaults{ defaults.set(url, forKey: "targetURL") defaults.synchronize() } self.showWindow(with: NSExtensionContext()) } This is how I read the plist from my main app: if let defaults = UserDefaults(suiteName: "group.team_id.Finder-Sync-Extension-Test-Project") { defaults.synchronize() if let clickedUrl = defaults.string(forKey: "targetURL") { window = NSWindow(contentRect: NSScreen.main?.frame ?? .zero, styleMask: [.miniaturizable, .closable, .resizable, .titled], backing: .buffered, defer: false) window?.title = "My App" window?.makeKeyAndOrderFront(nil) textField.stringValue = clickedUrl window?.contentView?.addSubview(textField) } } It is fine if this popup happens once and the user's choice gets remembered. I just don't want it to happen every time. Any help on if this is the correct way to pass data between the finder sync extension and the main app or on how to get macOS to remember the choice of the user would be great. Thanks, James

I am writing a MacOS app that uses the Apple crypto libraries to create, save, and use an RSA key pair. I am not using a Secure Enclave so that the private key can later the retrieved through the keychain. The problem I am running into is that on my and multiple other systems the creation and retrieval works fine. On a different system -- running MacOS 15.3 just like the working systems -- the SecKeyCreateRandomKey function appears to work fine and I get a key reference back, but on subsequent runs SecItemCopyMatching results in errSecItemNotFound. Why would it appear to save properly on some systems and not others? var error: Unmanaged<CFError>? let access = SecAccessControlCreateWithFlags(kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .biometryAny, &error)! let tag = TAG.data(using: .utf8)! // com.example.myapp.rsakey let attributes: [String: Any] = [ kSecAttrKeyType as String: KEY_TYPE, // set to kSecAttrKeyTypeRSA kSecAttrKeySizeInBits as String: 3072, kSecPrivateKeyAttrs as String: [ kSecAttrIsPermanent as String: true, kSecAttrApplicationTag as String: tag, kSecAttrAccessControl as String: access, ], ] guard let newKey = SecKeyCreateRandomKey(attributes as CFDictionary, &error) else { throw error!.takeRetainedValue() as Error } return newKey This runs fine on both systems, getting a valid key reference that I can use. But then if I immediately try to pull the key, it works on my system but not the other. let query = [ kSecClass as String: kSecClassKey, kSecAttrApplicationTag as String: tag, kSecReturnRef as String: true, ] var item: CFTypeRef? let status = SecItemCopyMatching(query as CFDictionary, &item) let msg = SecCopyErrorMessageString(status, nil) if status == errSecItemNotFound { print("key not found") } guard status == errSecSuccess else { print("other retrieval error") } return item as! SecKey I've also tried a separate query using the secCall function from here (https://developer.apple.com/forums/thread/710961) that gets ALL kSecClassKey items before and after the "create the key" function and it'll report the same amount of keys before and after on the bugged system. On the other machines where it works, it'll show one more key as expected. In the Signing & Capabilities section of the project config, I have Keychain Sharing set up with a group like com.example.myapp where my key uses a tag like com.example.myapp.rsakey. The entitlements file has an associated entry for Keychain Access Groups with value $(AppIdentifierPrefix)com.example.myapp.

Hello, I am currently researching to develop an application where I want to apply the MacOS updates without the password prompt shown to the users. I did some research on this and understand that an MDM solution can apply these patches without user intervention. Are there any other ways we can achieve this? Any leads are much appreciated.

With Let's Encrypt having completely dropped support for OCSP recently [1], I wanted to ask if macOS has a means of keeping up to date with their CRLs and if so, roughly how often this occurs? I first observed an issue where a revoked-certificate test site, "revoked.badssl.com" (cert signed by Let's Encrypt), was not getting blocked on any browser, when a revocation policy was set up using the SecPolicyCreateRevocation API, in tandem with the kSecRevocationUseAnyAvailableMethod and kSecRevocationPreferCRL flags. After further investigation, I noticed that even on a fresh install of macOS, Safari does not block this test website, while Chrome and Firefox (usually) do, due to its revoked certificate. Chrome and Firefox both have their own means of dealing with CRLs, while I assume Safari uses the system Keychain and APIs. I checked cert info for the site here [2]. It was issued on 2025-07-01 20:00 and revoked an hour later. [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=revoked.badssl.com

Is there a way to unlock login keychain without using password and with any other authentication factor supported by 3rd party MFA options?

Hi everyone, I’m working an Objective-C lib that performs Keychain operations, such as generating cryptographic keys and signing data. The lib will be used by my team in a Java program for macOS via JNI. When working with the traditional file-based Keychain (i.e., without access control flags), everything works smoothly, no issues at all. However, as soon as I try to generate a key using access control flags SecAccessControlCreateWithFlags, the Data Protection Keychain returns error -34018 (errSecMissingEntitlement) during SecKeyCreateRandomKey. This behavior is expected. To address this, I attempted to codesign my native dynamic library (.dylib) with an entitlement plist specifying various combinations of: keychain-access-groups com.apple.security.keychain etc. with: My Apple Development certificate Developer ID Application certificate Apple Distribution certificate None of these combinations made a difference, the error persists. I’d love to clarify: Is it supported to access Data Protection Keychain / Secure Enclave Keys in this type of use case? If so, what exact entitlements does macOS expect when calling SecKeyCreateRandomKey from a native library? I’d really appreciate any guidance or clarification. Thanks in advance! Best regards, Neil

Hi Team, How can we fetch the macOS password requirement(for setting a new password) that are inforce during login for users? Is there a way to get this info in swift programming?

Before device Reboot: Here no issue from keychain. 2025-06-17 11:18:17.956334 +0530 WAVE PTX [DB_ENCRYPTION] Key successfully retrieved from the Keychain default When device is in reboot and locked (Keychain access is set to FirstUnlock) App got woken up in background SEEMS(NOT SURE) DEVICE STILL IN LOCKED STARE IF YES THEN WHICH IS EXPECTED 2025-06-17 12:12:30.036184 +0530 WAVE PTX <ALA_ERROR>: [OS-CCF] [DB_ENCRYPTION] Error while retriving Private key -25308 default 2025-06-17 12:15:28.914700 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default —————————————————— And as per logs, here user has launch the application post unlock and application never got the keychain access here also. HERE STILL HAS ISSUE WITH KEYCHAIN ACCESS. 2025-06-17 12:52:55.640976 +0530 WAVE PTX DEBUG : willFinishLaunchingWithOptions default 2025-06-17 12:52:55.651371 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default

Issue Summary I'm encountering a DCError.invalidInput error when calling DCAppAttestService.shared.generateAssertion() in my App Attest implementation. This issue affects only a small subset of users - the majority of users can successfully complete both attestation and assertion flows without any issues. According to Apple Engineer feedback, there might be a small implementation issue in my code. Key Observations Success Rate: ~95% of users complete the flow successfully Failure Pattern: The remaining ~5% consistently fail at assertion generation Key Length: Logs show key length of 44 characters for both successful and failing cases Consistency: Users who experience the error tend to experience it consistently Platform: Issue observed across different iOS versions and device types Environment iOS App Attest implementation Using DCAppAttestService for both attestation and assertion Custom relying party server communication Issue affects ~5% of users consistently Key Implementation Details 1. Attestation Flow (Working) The attestation process works correctly: // Generate key and attest (successful for all users) self.attestService.generateKey { keyId, keyIdError in guard keyIdError == nil, let keyId = keyId else { return completionHandler(.failure(.dcError(keyIdError as! DCError))) } // Note: keyId length is consistently 44 characters for both successful and failing users // Attest key with Apple servers self.attestKey(keyId, clientData: clientData) { result in // ... verification with RP server // Key is successfully stored for ALL users (including those who later fail at assertion) } } 2. Assertion Flow (Failing for ~5% of Users with invalidInput) The assertion generation fails for a consistent subset of users: // Get assertion data from RP server self.assertRelyingParty.getAssertionData(kid, with: data) { result in switch result { case .success(let receivedData): let session = receivedData.session let clientData = receivedData.clientData let hash = clientData.toSHA256() // SHA256 hash of client data // THIS CALL FAILS WITH invalidInput for ~5% of users // Same keyId (44 chars) that worked for attestation self.attestService.generateAssertion(kid, clientDataHash: hash) { assertion, err in guard err == nil, let assertion = assertion else { // Error: DCError.invalidInput if let err = err as? DCError, err.code == .invalidKey { return reattestAndAssert(.invalidKey, completionHandler) } else { return completionHandler(.failure(.dcError(err as! DCError))) } } // ... verification logic } } } 3. Client Data Structure Client data JSON structure (identical for successful and failing users): // For attestation (works for all users) let clientData = ["challenge": receivedData.challenge] // For assertion (fails for ~5% of users with same structure) var clientData = ["challenge": receivedData.challenge] if let data = data { // Additional data for assertion clientData["account"] = data["account"] clientData["amount"] = data["amount"] } 4. SHA256 Hash Implementation extension Data { public func toSHA256() -> Data { return Data(SHA256.hash(data: self)) } } 5. Key Storage Implementation Using UserDefaults for key storage (works consistently for all users): private let keyStorageTag = "app-attest-keyid" func setKey(_ keyId: String) -> Result<(), KeyStorageError> { UserDefaults.standard.set(keyId, forKey: keyStorageTag) return .success(()) } func getKey() -> Result<String?, KeyStorageError> { let keyId = UserDefaults.standard.string(forKey: keyStorageTag) return .success(keyId) } Questions User-Specific Factors: Since this affects only ~5% of users consistently, could there be device-specific, iOS version-specific, or account-specific factors that cause invalidInput? Key State Validation: Is there any way to validate the state of an attested key before calling generateAssertion()? The key length (44 chars) appears normal for both successful and failing cases. Keychain vs UserDefaults: Could the issue be related to using UserDefaults instead of Keychain for key storage? Though this works for 95% of users. Race Conditions: Could there be subtle race conditions or timing issues that only affect certain users/devices? Error Recovery: Is there a recommended way to handle this error? Should we attempt re-attestation for these users? Additional Context & Debugging Attempts Consistent Failure: Users who experience this error typically experience it on every attempt Key Validation: Both successful and failing users have identical key formats (44 character strings) Device Diversity: Issue observed across different device models and iOS versions Server Logs: Our server successfully provides challenges and processes attestation for all users Re-attestation: Forcing re-attestation sometimes resolves the issue temporarily, but it often recurs The fact that 95% of users succeed with identical code suggests there might be some environmental or device-specific factor that we're not accounting for. Any insights into what could cause invalidInput for a subset of users would be invaluable.

A client asked why we can't detect other apps installed on a device without an MDM profile, we explained this isn't possible due to privacy and security restrictions on iOS. A regular app cannot find other apps that are installed unless part of the same group. The client then told us to download SpyBuster (on the App Store) which somehow is collecting a list of Bundle IDs or names of all installed apps somehow. We were skeptical, but sure enough, the app showed us a list of apps we had installed. How is it doing this?!?! No MDM profile associated with the app. No special permissions requested. No access to anything shown in privacy &amp; security in settings. Is there a special entitlement we're not aware of? Just seems like they must be using a private API call to get this info but that would of course mean it should be pulled from the App Store. We'd love to have this capability in our apps if it's legit and accepted by App Store review. Thanks!

I requested permission to use the Family Controls entitlement two weeks ago, and I have not received a response or status update. I have been to that page where it says "Thank you! We'll get back to you soon!" so many times.

In my app, I use SecItem to store some data in the Keychain. I’d like to know — when a user sets up a new iPhone and transfers data from the old device, will those Keychain items be migrated or synced to the new device?

Having trouble decrypting a string using an encryption key and an IV. var key: String var iv: String func decryptData(_ encryptedText: String) -> String? { if let textData = Data(base64Encoded: iv + encryptedText) { do { let sealedBox = try AES.GCM.SealedBox(combined: textData) let key = SymmetricKey(data: key.data(using: .utf8)!) let decryptedData = try AES.GCM.open(sealedBox, using: key) return String(data: decryptedData, encoding: .utf8) } catch { print("Decryption failed: \(error)") return nil } } return nil } Proper coding choices aside (I'm just trying anything at this point,) the main problem is opening the SealedBox. If I go to an online decryption site, I can paste in my encrypted text, the encryption key, and the IV as plain text and I can encrypt and decrypt just fine. But I can't seem to get the right combo in my Swift code. I don't have a "tag" even though I'm using the combined option. How can I make this work when all I will be receiving is the encrypted text, the encryption key, and the IV. (the encryption key is 256 bits) Try an AES site with a key of 32 digits and an IV of 16 digits and text of your choice. Use the encrypted version of the text and then the key and IV in my code and you'll see the problem. I can make the SealedBox but I can't open it to get the decrypted data. So I'm not combining the right things the right way. Anyone notice the problem?

I am working on improving Keychain item storage secured with Face ID using SecAccessControlCreateWithFlags. The implementation uses the .biometryAny flag as shown below: SecAccessControlCreateWithFlags( kCFAllocatorDefault, kSecAttrAccessibleWhenUnlockedThisDeviceOnly, .biometryAny, &amp;error ) While this approach generally works as expected, I encountered a specific edge case during testing. On iOS 18.3.1 with Xcode 15.4, the following sequence causes the Keychain item to become inaccessible: Navigate to Settings &gt; Face ID &amp; Passcode and select Reset Face ID. Before setting up a new Face ID, tap the Back button to exit the setup process. Reopen the Face ID setup and complete the enrollment. Return to the app—previously stored Keychain items protected by .biometryAny are no longer available. This behavior appears to be a change introduced in recent iOS versions. In versions prior to iOS 15, resetting or deleting Face ID entries did not invalidate existing Keychain items protected by .biometryAny. This difference in behavior between iOS versions raises questions about the changes to biometric protection handling. Any suggestions are welcomed that might shine a light on what the best practice to use keychain access control and prevent the data to become unavailable.

I’d like to confirm something regarding the hosting of the apple-app-site-association (AASA) file. We have a server that publicly hosts the AASA file and is accessible globally. However, this server sits behind an additional security layer (a security server/reverse proxy). My question is: Will this security layer affect Apple’s ability to access and validate the AASA file for Universal Links or App Clips? Are there specific requirements (e.g. headers, redirects, TLS versions, etc.) that we need to ensure the security server does not block or modify? Any guidance or best practices would be appreciated. Thanks!

My high-level goal is to add support for Game Mode in a Java game, which launches via a macOS "launcher" app that runs the actual java game as a separate process (e.g. using the java command line tool). I asked this over in the Graphics & Games section and was told this, which is why I'm reposting this here. I'm uncertain how to speak to CLI tools and Java games launched from a macOS app. These sound like security and sandboxing questions which we recommend you ask about in those sections of the forums. The system seems to decide whether to enable Game Mode based on values in the Info.plist (e.g. for LSApplicationCategoryType and GCSupportsGameMode). However, the child process can't seem to see these values. Is there a way to change that? (The rest of this post is copied from my other forums post to provide additional context.) Imagine a native macOS app that acts as a "launcher" for a Java game.** For example, the "launcher" app might use the Swift Process API or a similar method to run the java command line tool (lets assume the user has installed Java themselves) to run the game. I have seen How to Enable Game Mode. If the native launcher app's Info.plist has the following keys set: LSApplicationCategoryType set to public.app-category.games LSSupportsGameMode set to true (for macOS 26+) GCSupportsGameMode set to true The launcher itself can cause Game Mode to activate if the launcher is fullscreened. However, if the launcher opens a Java process that opens a window, then the Java window is fullscreened, Game Mode doesn't seem to activate. In this case activating Game Mode for the launcher itself is unnecessary, but you'd expect Game Mode to activate when the actual game in the Java window is fullscreened. Is there a way to get Game Mode to activate in the latter case? ** The concrete case I'm thinking of is a third-party Minecraft Java Edition launcher, but the issue can also be demonstrated in a sample project (FB13786152). It seems like the official Minecraft launcher is able to do this, though it's not clear how. (Is its bundle identifier hardcoded in the OS to allow for this? Changing a sample app's bundle identifier to be the same as the official Minecraft launcher gets the behavior I want, but obviously this is not a practical solution.)