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

When a user first downloads my application they are prompted to sign into their apple account via a pop up. I have not had this pop up previously, I believe the change occurred after iOS18. I have functions that do a few things: Retrieves userRecordID Retrieves a userprofile(via userrecordid) from cloudkit.

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?

When the iCloud Passwords Chrome extension is on, there is a 400-500ms lag between clicking on a non-password field and the UI reflecting any changes made by a .on("focus") jQuery listener. When the extension is disabled, there is no lag. See below the performance profiles for the same 4 click events. Extension ON: Extension OFF:

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!

Hi folks, I would like to ask for clarification regarding Local Network Policy. I found 2 cases where I think the behaviour differs from the documentation. 1. Use case In a CI environment, we have multiple services (LaunchAgents) which require Local Network Access. We are fine by manually approving the Local Network Permission once (per service), but we also require these services to be able to self-update. Self update results in downloading the a binary with an (obviously) different UUID, which seems to result in re-triggering the Local Network Consent prompt. Strange thing: If I don't click either buttons (Allow of Reject), just restart macOS, it will result in an enabled entry in Privacy &amp; Security &gt; Local Network. I read a reply somewhere on this forum by an Apple engineer that the approval process is a mix of Bundle ID + UUID + other components, so I would expect a new binary with the same properties (but different UUID) to be already whitelisted. Is this behaviour intended? 2. Use Case Given the first issue, I decided to do this in the "right way". I was happy to read this sentence in the documentation: If you ship a launchd agent that’s not installed using SMAppService, make macOS aware of the responsible code by setting the AssociatedBundleIdentifiers property in your launchd property list. I have a properly setup (and code signed) Application, for which I have enabled Local Network permission in Privacy &amp; Security. I have a standalone LaunchAgent, which runs a long running binary from a user directory. The agent is managed with launchd, and in this sense it is "independent" from the main Application Bundle. I have setup AssociatedBundleIdentifiers in the Agent plist, to associate it with the Application. The TeamIdentifier of the 2 binaries are the same. Based on the documentation, this should be enough for my agent to signal macOS that the responsible code is the Application Bundle (which is already enabled from Local Network POV). Instead, once the LaunchAgent starts, the Local Network Consent popup appears for the binary. I would expect the Application to be the responsible code, thus no more Consent popup. Is this behaviour intended? I need this service to run as user, so I cannot just circumvent the Consent popup by running as a Daemon or Root. Nor I would like to manage the Agent with ServiceManagement. What do you guys think, have I misunderstood the documentation?

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.

I am reaching out regarding the ITMS-91061 rejection issue we encountered while submitting our app to the App Store. The rejection is related to missing privacy manifests for Firebase and related SDKs. Currently, our PrivacyInfo.xcprivacy file is structured as follows: Could you please confirm whether we can modify this file to include Firebase-related privacy information to resolve the rejection? If so, could you provide guidance on the correct format and the necessary entries we should add? We appreciate your support and look forward to your response.