Hello Apple Developer Team, I would love to see iCloud Keychain Autofill and Touch ID support extended to Chromium-based browsers on macOS (such as Ecosia, Brave, or Vivaldi). Currently, Safari allows autofill of passwords using Touch ID, but when using other browsers, I have to manually copy-paste credentials from Keychain Access, which is time-consuming. Would it be possible for Apple to provide an API or framework that allows non-WebKit browsers to integrate iCloud Keychain autofill while keeping security intact? This feature would make macOS more convenient for users who prefer alternative browsers while keeping security standards high. Thanks in advance for considering this! Best regards, Kilian

Can you please give me a hand with importing certificates under MacOS? I want to connect to Wi-Fi with 802.1X authentication (EAP-TLS) using a certificate that my homebrew application imported into my data protection keychain, but the imported certificate does not show up and I cannot select the certificate. It also does not show up in the Keychain Access app. One method I have tried is to import it into the data protection keychain by using the SecItemAdd function and setting kSecUseDataProtectionKeychain to true, but it does not work. Is there a better way to do this? ID: for id in identities { let identityParams: [String: Any] = [ kSecValueRef as String: id, kSecReturnPersistentRef as String: true, kSecUseDataProtectionKeychain as String: true ] let addIdentityStatus = SecItemAdd(identityParams as CFDictionary, nil) if addIdentityStatus == errSecSuccess { print("Successfully added the ID.: \(addIdentityStatus)") } else { print("Failed to add the ID.: \(addIdentityStatus)") } } Certificate: for cert in certificates { let certParams: [String: Any] = [ kSecValueRef as String: cert, kSecReturnPersistentRef as String: true, kSecUseDataProtectionKeychain as String: true ] let addCertStatus = SecItemAdd(certParams as CFDictionary, nil) if addCertStatus == errSecSuccess { print("Successfully added the certificate.: (\(addCertStatus))") } else { print("Failed to add the certificate.: (\(addCertStatus))") } } Private key: for privateKey in keys { let keyTag = UUID().uuidString.data(using: .utf8)! let keyParams: [String: Any] = [ kSecAttrApplicationTag as String: keyTag, kSecValueRef as String: privateKey, kSecReturnPersistentRef as String: true, kSecUseDataProtectionKeychain as String: true ] let addKeyStatus = SecItemAdd(keyParams as CFDictionary, nil) if addKeyStatus == errSecSuccess { print("Successfully added the private key.: \(addKeyStatus)") } else { print("Failed to add the private key.: \(addKeyStatus)") } }

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?

I'm working on two Swift applications which are using QUIC in Network.framework for communication, one serve as the listener (server) and the other serve as the client so that they can exchange data, both the server and the client app are running under the same LAN, the problem I met is that when client try to connect to the server, the connection will fail due to boring SSL, couple questions: Since both the server app and client app are running under the same LAN, do they need TLS certificate? If it does, will self-signed certificate P12 work? I might distribute the app in App Store or in signed/notarized dmg or pkg to our users. If I need a public certificate and self signed wouldn't work, since they are just pair of apps w/o fixed dns domain etc, Is there any public certificate only for standalone application, not for the fixed web domain?

I am currently developing a No-Sandbox application. What I want to achieve is to use AuthorizationCopyRights in a No-Sandbox application to elevate to root, then register SMAppService.daemon after elevation, and finally call the registered daemon from within the No-Sandbox application. Implementation Details Here is the Plist that I am registering with SMAppService: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.example.agent</string> <key>BundleProgram</key> <string>/usr/local/bin/test</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/test</string> <string>login</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> Code that successfully performs privilege escalation (a helper tool popup appears) private func registerSMAppServiceDaemon() -> Bool { let service = SMAppService.daemon(plistName: "com.example.plist") do { try service.register() print("Successfully registered \(service)") return true } catch { print("Unable to register \(error)") return false } } private func levelUpRoot() -> Bool { var authRef: AuthorizationRef? let status = AuthorizationCreate(nil, nil, [], &authRef) if status != errAuthorizationSuccess { return false } let rightName = kSMRightBlessPrivilegedHelper return rightName.withCString { cStringName -> Bool in var authItem = AuthorizationItem( name: cStringName, valueLength: 0, value: nil, flags: 0 ) return withUnsafeMutablePointer(to: &authItem) { authItemPointer -> Bool in var authRights = AuthorizationRights(count: 1, items: authItemPointer) let authFlags: AuthorizationFlags = [.interactionAllowed, .preAuthorize, .extendRights] let status = AuthorizationCopyRights(authRef!, &authRights, nil, authFlags, nil) if status == errAuthorizationSuccess { if !registerSMAppServiceDaemon() { return false } return true } return false } } } Error Details Unable to register Error Domain=SMAppServiceErrorDomain Code=1 "Operation not permitted" UserInfo={NSLocalizedFailureReason=Operation not permitted} The likely cause of this error is that /usr/local/bin/test is being bundled. However, based on my understanding, since this is a non-sandboxed application, the binary should be accessible as long as it is run as root. Trying post as mentioned in the response, placing the test binary under Contents/Resources/ allows SMAppService to successfully register it. However, executing the binary results in a different error. Here is the plist at that time. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.example.agent</string> <key>BundleProgram</key> <string>Contents/Resources/test</string> <key>ProgramArguments</key> <array> <string>Contents/Resources/test</string> <string>login</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist> Here is the function at that time. private func executeBin() { let bundle = Bundle.main if let binaryPath = bundle.path(forResource: "test", ofType: nil) { print(binaryPath) let task = Process() task.executableURL = URL(fileURLWithPath: binaryPath) task.arguments = ["login"] let pipe = Pipe() task.standardOutput = pipe task.standardError = pipe do { try task.run() let outputData = pipe.fileHandleForReading.readDataToEndOfFile() if let output = String(data: outputData, encoding: .utf8) { print("Binary output: \(output)") } task.waitUntilExit() if task.terminationStatus == 0 { print("Binary executed successfully") } else { print("Binary execution failed with status: \(task.terminationStatus)") } } catch { print("Error executing binary: \(error)") } } else { print("Binary not found in the app bundle") } } Executed After Error Binary output: Binary execution failed with status: 5 Are there any other ways to execute a specific binary as root when using AuthorizationCopyRights? For example, by preparing a Helper Tool?

I’m building an iOS app that collects user PII (emails, names) and stores it in my backend database. I already use HTTPS for data transfer, but I’m unsure if Apple requires server-side encryption for stored data. For example: If a user’s email is stored in plain text on my server (but transmitted securely via HTTPS), will this violate App Store guidelines? Does Apple explicitly mandate encryption-at-rest for PII, or is it just a recommendation? Are there exceptions for non-sensitive data like usernames? I checked App Store Review Guidelines §5.1.1, which says "data must be stored securely," but it’s unclear if this requires encryption. Context: The app targets U.S. users (no GDPR/CCPA concerns). No financial/health data is involved. Is plain-text server storage of emails/names acceptable, or will this risk rejection? Thanks for any clarity!

I have some questions regarding App Group Id's and use of the FileManager during an Appstore iOS transfer. I've read a lot of the topics here that cover app groups and iOS, but it's still unclear exactly what is going to happen during transfer when we try to release an updated version of the app from the new account. We're using this method FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.foo.bar") to store files on the device that are important for app launch and user experience. Once we transfer the app and begin the process of creating a new version under the new account will we be able to read the files that are stored using this app group id under the new account? What steps do we need to take in order to handle this and continue being able to access these files? It seems like the app group is not transferred in the process? I've seen some users mention they removed the app group from the original account and created it again under the receiving account (with notes mentioning this is undocumented behavior). These conversations we're centered around Shared user defaults, and that applies as well but I'm more concerned with reading the values from the file system. Thanks!

I have my custom Authplugin implemented at login (system.login.console), and I want to remove password requirement validation/authentication from system.login.console authorization right. Do you see any functionality loss in completely removing password need at login. And is there any reference which can help me here to acheive this?

Hi, I have a couple of questions about how to proceed and prepare the implementation for the DeviceLock MDM command for macOS in a secure and proper manner. https://developer.apple.com/documentation/devicemanagement/device-lock-command In documentation "PIN" is "(string) The six-character PIN for Find My. This value is available in macOS 10.8 and later." - is this the PIN that is used to unlock the device? Is there any video online that I can see how the process would look like for the end user with locking and unlocking a device? What should be done before sending a DeviceLock command? What should be done to safely test the command without bricking a device. How to unlock a device that was locked with a DeviceLock command? Is there any Unlock command or can the user unlock device with the provided PIN earlier? Thank you for any help!

Hi everyone, I’m currently facing an issue while trying to submit an update for my app to the App Store. The review process is blocking the update due to a "Privacy - Data Use and Sharing" warning, stating that our app requests "tracking purchase history for tracking purposes." However, we have already removed this functionality and deleted the NSUserTrackingUsageDescription key from our latest build. Despite this, the warning persists, and we are unable to proceed with the update. I have already contacted Apple Support, but in the meantime, I wanted to ask the community: Has anyone else encountered this issue, and if so, how did you resolve it? Is there a way to force a refresh of privacy-related settings in App Store Connect? Are there any additional steps we need to take to completely remove this tracking flag from our app submission? Any insights or guidance would be greatly appreciated! Thanks in advance for your help.

The problem only happened on iOS system is 18.3. We save the data about user after user login,so when user login successful ,we save users info in NSUserdefault ,then user delete app,and reinstall the app,when launch the app,it is already logged in.

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'm looking for confirmation on the security aspects of fdesetup authrestart when used on a FileVault-enabled Mac. As I understand it, this command temporarily stores the decryption key in memory to allow the system to restart without requiring manual entry of the FileVault password. However, I have a few security-related concerns: Storage of the Decryption Key: Where exactly is the key stored during an authenticated restart? Is it protected within the Secure Enclave (for Apple Silicon Macs) or the T2 Security Chip on Intel Macs? Key Lifetime &amp; Wiping: At what point is the decryption key erased from memory? Does it persist in any form after the system has fully rebooted? Protection Against Physical Attacks: If an attacker gains physical access to the machine before the restart completes, is there any possibility that they could extract the decryption key from memory? Cold Boot Attack Resistance: Is there any risk that advanced forensic techniques (such as freezing RAM to retain data) could be used to recover the decryption key after issuing an authenticated restart? Malware Resistance: Could a compromised system (e.g., root access by an attacker) intercept or misuse the decryption key before the restart? I understand that on Apple Silicon and T2-equipped Macs, FileVault keys are tied to hardware-based encryption, making unauthorized access difficult. However, I'd like to confirm whether Authenticated Restart introduces any new risks compared to a standard FileVault-enabled boot process.

Sometimes, when I close the lid using the MacOs version Sequoia 15.2, with the configuration to require a password for 5 seconds, the system does not ask for the password as expected. This happens sometimes even though nothing preventing the system from sleeping when you close and open the lid, but it still seems like a security concern. Is there some known issue related to this problem or a way to avoid it? Result of command pmset -g: Configuration:

Hello. I want to do the following and need your help. I want to import a certificate (pkcs#12) into my macOS keychain with a setting that prohibits exporting the certificate. I want to import the certificate (pkcs#12) into my login keychain or system keychain. I was able to achieve [1] with the help of the following threads, but have the following problems. https://developer.apple.com/forums/thread/677314?answerId=824644022#824644022 how to import into login keychain or system keychain How to achieve this without using the deprecated API To import into the login keychain, I could use the “SecKeychainCopyDefault” function instead of the “SecKeychainCopySearchList” function, However, both of these functions were deprecated APIs. https://developer.apple.com/documentation/security/seckeychaincopysearchlist(_:) https://developer.apple.com/documentation/security/seckeychaincopydefault(_:) I checked the following URL and it seems that using the SecItem API is correct, but I could not figure out how to use it. https://developer.apple.com/documentation/technotes/tn3137-on-mac-keychains Is there any way to import them into the login keychain or system keychain without using these deprecated APIs?

I have an app that captures USB storage device and sends some commands to it. The app has a privilege helper tool which captures the USB device. Everything was working fine upto macOS 15.2 but it 15.3 update broke the functionality. When the helper tool tries to capture the USB device, it is able to capture IOUSBHostDevice but fails to capture IOUSBHostInterface. The error is Code: 3758097097; Domain: IOUSBHostErrorDomain; Description: Failed to create IOUSBHostInterface.; Reason: Failed [super init] I have verified the UID, EUID, GID, EGID = 0 for the helper process. So by IOUSBHost documentation it should have worked. The code that cause the error inside the helper tool is func captureUSBInterface(interface: io_service_t) -> IOUSBHostInterface? { let queue = DispatchQueue(label: "com.example.usbdevice.queue2") var capturedInterface: IOUSBHostInterface? do { capturedInterface = try IOUSBHostInterface(__ioService: interface, options: .deviceCapture, queue: queue, interestHandler: nil) } catch { NSLog("Failed to capture USB interface: \(error)") return nil } return capturedInterface } The app has sandbox=False and is distributed outside of the App Store. Please advise (long-term, short-term solutions) on how to make this work.

i recently upgraded to sequoia, and now, more often than not, when running in the debugger, opening my database causes a hang: When i run outside the debugger, it opens just fine. I suspect it has to do with "full disk access"? but i've given my app full disk access. i've also set Qt and Xcode to have "Allow apps to use developer tools" permissions. as a test i also added my app into that permission group, all to no avail. the path to the DB being opened is in my user's Music folder, and having full disk access gives permission for everything, including things in that folder. confused!

Current Setup: Using Secure Enclave with userPresence access control Foreground keychain accessibility: whenPasscodeSetThisDeviceOnly Security Requirement: Our security group wants us to invalidate biometrics and require a username/password if a biometric item is added (potentially by a hostile 3rd party) Need to upgrade from userPresence to biometricCurrentSet to ensure re-authentication when biometric credentials change. Issue: After implementing biometricCurrentSet, authentication cancels after two failed biometric attempts instead of falling back to passcode. Current Detection Method: User completes initial biometric authentication Biometric changes occur (undetectable by app) App attempts Secure Enclave access Access denial triggers re-authentication requirement Cannot revoke refresh token after access is denied Security Concern: Current implementation allows new biometric enrollments to access existing authenticated sessions without re-verification. Question: What's the recommended approach to: Implement biometricCurrentSet while maintaining passcode fallback Properly handle refresh token invalidation when biometric credentials change Looking for guidance on best practices for implementing these security requirements while maintaining good UX.

I must be missing something. How can an iphone that is in lockdown mode, using ONLY data, no Bluetooth connected and only one singular iPhone have seven UNLISTED items on the local network in privacy and settings?

转让app成功了之后，由于开发者账号更改，团队ID改变，导致获取不到原有的keychain中缓存的用户数据，所以在用户进行登录时，无法登录到原有的老账号，而是被识别成了一个新的用户。这种情况怎么解决。