Has anyone here encountered this? It's driving me crazy. It appears on launch. App Sandbox is enabled. The proper entitlement is selected (com.apple.security.files.user-selected.read-write) I believe this is causing an issue with app functionality for users on different machines. There is zero documentation across the internet on this problem. I am on macOS 26 beta. This error appears in both Xcode and Xcode-beta. Please help! Thank you, Logan

Summary I am investigating a change in macOS 26.1 (Tahoe) where plain (non-bundled) executables that request screen recording access no longer appear under: System Settings → Privacy & Security → Screen & System Audio Recording This behavior differs from macOS Sequoia, where these executables did appear in the list and could be managed through the UI. Tahoe still prompts for permission and still allows the executable to capture the screen once permission is granted, but the executable never shows up in the UI list. This breaks user expectations and removes UI-based permission management. To confirm the behavior, I created a small reproduction project with both: a plain executable, and an identical executable packaged inside an .app bundle. Only the bundled version appears in System Settings. Observed Behaviour 1. Plain Executable (from my reproduction project) When running a plain executable that captures the screen: macOS displays the normal screen-recording permission prompt. Before granting permission: screenshots show only the desktop background. After granting permission: screenshots capture the full display. The executable does not appear under “Screen & System Audio Recording”. Even when permission is granted manually (e.g., dragging the executable into the pane), the executable still does not appear, which prevents the user from modifying or revoking the permission through the UI. If the executable is launched from inside another app (e.g., VS Code, Terminal), the parent app appears in the list instead, not the executable itself. 2. Bundled App Version (from the reproduction project) I packaged the same code into a simple .app bundle (ScreenCaptureApp.app). When running the app: The same permission prompt appears. Pre-permission screenshots show the desktop background. Post-permission screenshots capture the full display. The app does appear under “Screen & System Audio Recording”. This bundle uses the same underlying executable — the only difference is packaging. Hypothesis macOS 26.1 (Tahoe) appears to require app bundles for an item to be shown in the Screen Recording privacy UI. Plain executables: still request and receive permission, still function correctly after permission is granted, but do not appear in the System Settings list. This may be an intentional change, undocumented behavior, or a regression. Reproduction Project The reproduction project includes: screen_capture.go A simple Go program that captures screenshots in a loop. screen_capture_executable Plain executable built from the Go source. ScreenCaptureApp.app/ App bundle containing the same executable. build.sh Builds both the plain executable and the app bundle. Permission reset and TCC testing scripts. The project demonstrates the behavior consistently. Steps to Reproduce Plain Executable Build: ./build.sh Reset screen capture permissions: sudo tccutil reset ScreenCapture Run: ./screen_capture_executable Before granting: screenshots show desktop only. Grant permission when prompted. After granting: full screenshots. Executable does not appear in “Screen & System Audio Recording”. Bundled App Build (if not already built): ./build.sh Reset permissions (optional): sudo tccutil reset ScreenCapture Run: open ScreenCaptureApp.app Before granting: screenshots show desktop. After granting: full screenshots. App bundle appears in the System Settings list. Additional Check I also tested launching the plain executable as a child process of another executable, similar to how some software architectures work. Result: Permission prompt appears Permission can be granted Executable still does not appear in the UI, even though TCC tracks it internally → consistent with the plain-executable behaviour. This reinforces that only app bundles are listed. Questions for Apple Is the removal of plain executables from “Screen & System Audio Recording” an intentional change in macOS Tahoe? If so, does Apple now require all screen-recording capable binaries to be packaged as .app bundles for the UI to display them? Is there a supported method for making a plain executable (launched by a parent process) appear in the list? If this is not intentional, what is the recommended path for reporting this as a regression? Files Unfortunately, I have discovered the zip file that contains my reproduction project can't be directly uploaded here. Here is a Google Drive link instead: https://drive.google.com/file/d/1sXsr3Q0g6_UzlOIL54P5wbS7yBkpMJ7A/view?usp=sharing Thank you for taking the time to review this. Any insight into whether this change is intentional or a regression would be very helpful.

Hi, how can you authenticate a User through Biometrics with iPhone Passcode as Fallback in the Autofill Credential Provider Extension? In the App it works without a problem. In the Extension I get "Caller is not running foreground" Yeah, it isn't, as it's just a sheet above e.g. Safari. I'd like to avoid having the user setup a Passcode dedicated to my App, especially because FaceID is way faster. Does anybody know how to achieve iOS native Auth in the extension? Please let me know, a code sample would be appreciated. Regards, Mia

Hi everyone, I’m encountering an unexpected Keychain behavior in a production environment and would like to confirm whether this is expected or if I’m missing something. In my app, I store a deviceId in the Keychain based on the classic KeychainItemWrapper implementation. I extended it by explicitly setting: kSecAttrAccessible = kSecAttrAccessibleAfterFirstUnlock My understanding is that kSecAttrAccessibleAfterFirstUnlock should allow Keychain access while the app is running in the background, as long as the device has been unlocked at least once after reboot. However, after the app went live, I observed that when the app performs background execution (e.g., triggered by background tasks / silent push), Keychain read attempts intermittently fail with: errSecInteractionNotAllowed (-25308) This seems inconsistent with the documented behavior of kSecAttrAccessibleAfterFirstUnlock. Additional context: The issue never occurs in foreground. The issue does not appear on development devices. User devices are not freshly rebooted when this happens. The Keychain item is created successfully; only background reads fail. Setting the accessibility to kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly produces the same result. Questions: Under what circumstances can kSecAttrAccessibleAfterFirstUnlock still cause a -25308 error? Is there any known restriction when accessing Keychain while the app is running in background execution contexts? Could certain system states (Low Power Mode, Background App Refresh conditions, device lock state, etc.) cause Keychain reads to be blocked unexpectedly? Any insights or similar experiences would be greatly appreciated. Thank you!

Hello Apple Developer Community, We have been experiencing a persistent notification issue in our application, Flowace, after updating to macOS 15 and above. The issue is affecting our customers but does not occur on our internal test machines. Issue Description When users share their screen using Flowace, they receive a repetitive system notification stating: "Flowace has accessed your screen and system audio XX times in the past 30 days. You can manage this in settings." This pop-up appears approximately every minute, even though screen sharing and audio access work correctly. This behavior was not present in macOS 15.1.1 or earlier versions and appears to be related to recent privacy enhancements in macOS. Impact on Users The frequent pop-ups disrupt workflows, making it difficult for users to focus while using screen-sharing features. No issues are detected in Privacy & Security Settings, where Flowace has the necessary permissions. The issue is not reproducible on our internal test machines, making troubleshooting difficult. Our application is enterprise level and works all the time, so technically this pop only comes after a period of not using the app. Request for Assistance We would like to understand: Has anyone else encountered a similar issue in macOS 15+? Is there official Apple documentation explaining this new privacy behavior? Are there any interim fixes to suppress or manage these notifications? What are Apple's prospects regarding this feature in upcoming macOS updates? A demonstration of the issue can be seen in the following video: https://youtu.be/njA6mam_Bgw Any insights, workarounds, or recommendations would be highly appreciated! Thank you in advance for your help. Best, Anuj Patil Flowace Team

In the macOS 14.0 SDK, environment and library constraints were introduced, which made defense against common attack vectors relatively simple (especially with the LightWeightCodeRequirements framework added in 14.4). Now, the application I'm working on must support macOS 13.0 too, so I was looking into alternatives that do work for those operating systems as well. What I found myself is that the SecCode/SecStaticCode APIs in the Security Framework do offer very similar fashion checks as the LightWeightCodeRequirements framework does: SecCodeCopySigningInformation can return values like signing identifier, team identifier, code requirement string and so on. SecStaticCodeCreateWithPath can return a SecStaticCode object to an executable/app bundle on the file system. Let's say, I would want to protect myself against launchd executable swap. From macOS 14.0 onward, I would use a Spawn Constraint for this, directly in the launchd.plist file. Before macOS 14.0, I would create a SecStaticCode object for the executable path found in the launchd.plist, and then examine its SecCodeCopySigningInformation dictionary. If the expectations are met, only then would I execute the launchd.plist-defined executable or connect to it via XPC. Are these two equivalent? If not, what are the differences?

I am developing a macOS application (targeting macOS 13 and later) that is non-sandboxed and needs to install and trust a root certificate by adding it to the System keychain programmatically. I’m fine with prompting the user for admin privileges or password, if needed. So far, I have attempted to execute the following command programmatically from both: A user-level process A root-level process sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.pem While the certificate does get installed, it does not appear as trusted in the Keychain Access app. One more point: The app is not distributed via MDM. App will be distributed out side the app store. Questions: What is the correct way to programmatically install and trust a root certificate in the System keychain? Does this require additional entitlements, signing, or profile configurations? Is it possible outside of MDM management? Any guidance or working samples would be greatly appreciated.

Binary code is associated with the NSUserTrackingUsageDescription deleted at present, but in the revised App privacy will contain NSUserTrackingUsageDescription, I feel very confused, don't know should shouldn't solve.

Hello, I recently installed an iOS app called SpyBuster by MacPaw. This app shows as list all my installed apps. How is this possible ? As a developer, I know this is prohibited by Apple - third party app to scan application workspace.

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.

In iOS 18, i use CNContactPickerViewController to access to Contacts (i know it is one-time access). After first pick up one contact, the Setting > Apps > my app > Contacts shows Private Access without any option to close it. Is there any way to close it and undisplay it ? I tried to uninstall and reinstall my app, but it didn't work.

Hi, I'm working on developing my own CryptoTokenKit (CTK) extension to enable codesign with HSM-backed keys. Here's what I’ve done so far: The container app sets up the tokenConfiguration with TKTokenKeychainCertificate and TKTokenKeychainKey. The extension registers successfully and is visible via pluginkit when launching the container app. The virtual smartcard appears when running security list-smartcards. The certificate, key, and identity are all visible using security export-smartcard -i [card]. However, nothing appears in the Keychain. After adding logging and reviewing output in the Console, I’ve observed the following behavior when running codesign: My TKTokenSession is instantiated correctly, using my custom TKToken implementation — so far, so good. However, none of the following TKTokenSession methods are ever called: func tokenSession(_ session: TKTokenSession, beginAuthFor operation: TKTokenOperation, constraint: Any) throws -> TKTokenAuthOperation func tokenSession(_ session: TKTokenSession, supports operation: TKTokenOperation, keyObjectID: TKToken.ObjectID, algorithm: TKTokenKeyAlgorithm) -> Bool func tokenSession(_ session: TKTokenSession, sign dataToSign: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data func tokenSession(_ session: TKTokenSession, decrypt ciphertext: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data func tokenSession(_ session: TKTokenSession, performKeyExchange otherPartyPublicKeyData: Data, keyObjectID objectID: Any, algorithm: TKTokenKeyAlgorithm, parameters: TKTokenKeyExchangeParameters) throws -> Data The only relevant Console log is: default 11:31:15.453969+0200 PersistentToken [0x154d04850] invalidated because the client process (pid 4899) either cancelled the connection or exited There’s no crash report related to the extension, so my assumption is that ctkd is closing the connection for some unknown reason. Is there any way to debug this further? Thank you for your help.

Hi! We are developing an authentication plugin for macOS that integrates with the system's authentication flow. The plugin is designed to prompt the user for approval via a push notification in our app before allowing access. The plugin is added as the first mechanism in the authenticate rule, followed by the default builtin:authenticate as a fallback. When the system requests authentication (e.g., during screen unlock), our plugin successfully displays the custom UI and sends a push notification to the user's device. However, I've encountered the following issue: If the user does not approve the push notification within ~30 seconds, the system resets the screen lock (expected behavior). If the user approves the push notification within approximately 30 seconds but doesn’t start entering their password before the timeout expires, the system still resets the screen lock before they can enter their password, effectively canceling the session. What I've Tried: Attempted to imitate mouse movement after the push button was clicked to keep the session active. Created a display sleep prevention assertion using IOKit to prevent the screen from turning off. Used the caffeinate command to keep the display and system awake. Tried setting the result as allow for the authorization request and passing an empty password to prevent the display from turning off. I also checked the system logs when this issue occurred and found the following messages: ___loginwindow: -[LWScreenLock (Private) askForPasswordSecAgent] | localUser = >timeout loginwindow: -[LWScreenLock handleUnlockResult:] _block_invoke | ERROR: Unexpected _lockRequestedBy of:7 sleeping screen loginwindow: SleepDisplay | enter powerd: Process (loginwindow) is requesting display idle___ These messages suggest that the loginwindow process encounters a timeout condition, followed by the display entering sleep mode. Despite my attempts to prevent this behavior, the screen lock still resets prematurely. Questions: Is there a documented (or undocumented) system timeout for the entire authentication flow during screen unlock that I cannot override? Are there any strategies for pausing or extending the authentication timeout to allow for complex authentication flows like push notifications? Any guidance or insights would be greatly appreciated. Thank you!

I'm writing an app on macOS that stores passwords in the Keychain and later retrieves them using SecItemCopyMatching(). This works fine 90% of the time. However, occasionally, the call to SecItemCopyMatching() fails with errSecAuthFailed (-25293). When this occurs, simply restarting the app resolves the issue; otherwise, it will consistently fail with errSecAuthFailed. What I suspect is that the Keychain access permission has a time limitation for a process. This issue always seems to arise when I keep my app running for an extended period.

I have a small command-line app I've been using for years to process files. I have it run by an Automator script, so that I can drop files onto it. It stopped working this morning. At first, I could still run the app from the command line, without Automator. But then after I recompiled the app, now I cannot even do that. When I run it, it's saying 'zsh: killed' followed by my app's path. What is that? The app does run if I run it from Xcode. How do I fix this?

I am working on implementing mTLS authentication in my iOS app (Apple Inhouse & intune MAM managed app). The SCEP client certificate is deployed on the device via Intune MDM. When I try accessing the protected endpoint via SFSafariViewController/ASWebAuthenticationSession, the certificate picker appears and the request succeeds. However, from within my app (using URLSessionDelegate), the certificate is not found (errSecItemNotFound). The didReceive challenge method is called, but my SCEP certificate is not found in the app. The certificate is visible under Settings > Device Management > SCEP Certificate. How can I make my iOS app access and use the SCEP certificate (installed via Intune MDM) for mTLS requests? Do I need a special entitlement, keychain access group, or configuration in Intune or Developer account to allow my app to use the certificate? Here is the sample code I am using: final class KeychainCertificateDelegate: NSObject, URLSessionDelegate { func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) { guard challenge.protectionSpace.authenticationMethod == NSURLAuthenticationMethodClientCertificate else { completionHandler(.performDefaultHandling, nil) return } // Get the DNs the server will accept guard let expectedDNs = challenge.protectionSpace.distinguishedNames else { completionHandler(.cancelAuthenticationChallenge, nil) return } var identityRefs: CFTypeRef? = nil let err = SecItemCopyMatching([ kSecClass: kSecClassIdentity, kSecMatchLimit: kSecMatchLimitAll, kSecMatchIssuers: expectedDNs, kSecReturnRef: true, ] as NSDictionary, &identityRefs) if err != errSecSuccess { completionHandler(.cancelAuthenticationChallenge, nil) return } guard let identities = identityRefs as? [SecIdentity], let identity = identities.first else { print("Identity list is empty") completionHandler(.cancelAuthenticationChallenge, nil) return } let credential = URLCredential(identity: identity, certificates: nil, persistence: .forSession) completionHandler(.useCredential, credential) } } func perform_mTLSRequest() { guard let url = URL(string: "https://sample.com/api/endpoint") else { return } var request = URLRequest(url: url) request.httpMethod = "POST" request.setValue("application/json", forHTTPHeaderField: "Accept") request.setValue("Bearer \(bearerToken)", forHTTPHeaderField: "Authorization") let delegate = KeychainCertificateDelegate() let session = URLSession(configuration: .ephemeral, delegate: delegate, delegateQueue: nil) let task = session.dataTask(with: request) { data, response, error in guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { print("Bad response") return } if let data = data { print(String(data: data, encoding: .utf8)!) } } task.resume() }

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?

I created an app in Xcode using ApplescriptObjC that is supposed to communicate with Finder and Adobe Illustrator. It has been working for the last 8 years, until now I have updated it for Sonoma and it no longer triggers the alerts for the user to approve the communication. It sends the Apple Events, but instead of the alert dialog I get this error in Console: "Sandboxed application with pid 15728 attempted to lookup App: "Finder"/"finder"/"com.apple.finder" 654/0x0:0x1d01d MACSstill-hintable sess=100017 but was denied due to sandboxing." The Illustrator error is prdictably similar. I added this to the app.entitlements file: <key>com.apple.security.automation.apple-events</key> <array> <string>com.apple.finder</string> <string>com.adobe.illustrator</string> </array> I added this to Info.plist: <key>NSAppleEventsUsageDescription</key> <string>This app requires access to Finder and Adobe Illustrator for automation.</string> I built the app, signed with the correct Developer ID Application Certificate. I've also packaged it into a signed DMG and installed it, with the same result as running it from Xcode. I tried stripping it down to just the lines of code that communicate with Finder and Illustrator, and built it with a different bundle identifier with the same result. What am I missing?

Hi Team, We are trying to understand deep sleep behaviour, can you please help us clarifying on the below questions: When will we configure Hibernate 25, is it valid for M series MacBooks? Is Hibernate 25 called deep sleep mode? What are the settings I need to do on Mac, to make my Mac go in to deep sleep? When awakening from deep sleep , what would be macOS system behaviour? If we have custom SFAuthorization plug in at system.login.screensaver, what would be the behaviour with deep sleep?

We recently deployed Attestation on our application, and for a majority of the 40,000 users it works well. We have about six customers who are failing attestation. In digging through debug logs, we're seeing this error "iOS assertion verification failed. Unauthorized access attempted." We're assuming that the UUID is blocked somehow on Apple side but we're stumped as to why. We had a customer come in and we could look at the phone, and best we can tell it's just a generic phone with no jailbroken or any malicious apps. How can we determine if the UUID is blocked?