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 Apple Team and Community, We've encountered a sudden and widespread failure with the App Attest service starting today across multiple production apps and regions. The previously working implementation is now consistently returning the following error on iOS: The operation couldn’t be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable) Despite the green status on Apple’s System Status page, this appears to be a backend issue—possibly infrastructure or DNS-related. Notably: The issue affects multiple apps. It is reproducible across different geographies. No code changes were made recently to the attestation logic. We previously reported a similar concern in this thread: App Attest Attestation Failing, but this new occurrence seems unrelated to any client-side cause. Update: An Apple engineer in this thread(https://developer.apple.com/forums/thread/782987) confirmed that the issue was due to a temporary DNS problem and has now been resolved. Can anyone else confirm seeing this today? Any insights from Apple would be appreciated to ensure continued stability. Thanks!

Since around March 4, 2025 off and on, we've been receiving 500 errors back from the validate_device_token endpoint on development and production. Today (March 6) we are constantly getting 500 error back. https://api.development.devicecheck.apple.com/v1/validate_device_token This was working previously before then. No change has happened on our end since then. This is a critical piece for our infrastructure. Thanks in advance. -Matt

I have a binary executable which needs to be given Accessibility Permissions so it can inject keypresses and mouse moves. This was always possible up to macOS 15 - when the first keypress arrived the Accessibility Permissions window would open and allow me to add the executable. However this no longer works in macOS 26: the window still opens, I navigate to the executable file and select it but it doesn't appear in the list. No error message appears. I'm guessing that this may be due to some tightening of security in Tahoe but I need to figure out what to change with my executable to allow it to work.

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!

It seems it is not possible to give a CLI app (non .app bundle) full disk access in macOS 26.1. This seems like a bug and if not that is a breaking change. Anybody seeing the same problem? Our application needs full disk access for a service running as a LaunchDaemon. The binary is located in a /Library subfolder.

Hi all, I’m building a password manager app for iOS. The app implements an ASCredentialProviderExtension and has the entitlement com.apple.developer.authentication-services.autofill-credential-provider. From a UX perspective, I’d like to help users enable my app under: Settings → General → AutoFill & Passwords What I’ve observed: Calling UIApplication.openSettingsURLString only opens my app’s own Settings page, not the AutoFill list. Some apps (e.g. Google Authenticator) appear to redirect users directly into the AutoFill Passwords & Passkeys screen when you tap “Enable AutoFill.” 1Password goes even further: when you tap “Enable” in 1Password App, it shows a system pop-up, prompts for Face ID, and then enables 1Password as the AutoFill provider without the user ever leaving the app. Questions: Is there a public API or entitlement that allows apps to deep-link users directly to the AutoFill Passwords & Passkeys screen? Is there a supported API to programmatically request that my app be enabled as an AutoFill provider (similar to what 1Password seems to achieve)? If not, what is the recommended approach for guiding users through this flow? Thanks in advance!

iOS18.1.1 macOS15.1.1 xcode16.1 Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Unable to verify webcredentials association of ********** with domain ******************. Please try again in a few seconds." Our domain must query with VPN, so I set webcredentials:qa.ejeokvv.com?mode=developer following: "If you use a private web server, which is unreachable from the public internet, while developing your app, enable the alternate mode feature to bypass the CDN and connect directly to your server. To do this, add a query string to your associated domains entitlement, as shown in the following example: :?mode= " but it still not working, even after I set mode=developer. Please help!!!!

I have been able to save and remove ASPasskeyCredentialIdentities in the ASCredentialIdentityStore. But after saving a ASPasskeyCredentialIdentity, when I retrieve the current identities stored, it always returns an empty list. I check to make sure the store is enabled. I am using this method which is available starting with iOS 17.4: extension ASCredentialIdentityStore { public func credentialIdentities(forService serviceIdentifier: ASCredentialServiceIdentifier? = nil, credentialIdentityTypes: ASCredentialIdentityStore.IdentityTypes = []) async -> [any ASCredentialIdentity] } I have called it like this: store.credentialIdentities(forService: nil, credentialIdentityTypes: .passkey) And this: store.credentialIdentities() Has anyone got this to work?

Since Sun 15th Jun 04:30 (UTC+7) we received lots of following error that causes our device test failure. Could Apple please investigate further? ############################# Operations could not be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable)

Hi folks We have a Developer ID Application which we create using electron. We made our last release for our Application on Nov'24 which was correctly working. Using the same code, we tried creating a notarized application again which started showing the following error while opening our Application. Monterey- M2- When we directly run the dmg on the dev machine, it does not give us the prompt. But if we download it from somewhere and run, the prompt comes up even in dev machine. We executed some commands to verify the notarization: 1- spctl --assess -vv /Applications/Refresh\ Pro.app On both dev machine and non-dev machine, the output was "accepted" /Applications/Refresh Pro.app: accepted source=Notarized Developer ID origin=Developer ID Application: Prograde Digital Incorporated (*******) 2- xcrun stapler validate /Applications/Refresh\ Pro.app On dev machine, we executed this command and the output is as follows. Processing: /Applications/Refresh Pro.app The validate action worked! 3- codesign -vvv --deep --strict /Applications/Refresh\ Pro.app/ /Applications/Refresh Pro.app: valid on disk /Applications/Refresh Pro.app: satisfies its Designated Requirement We have created a bug attaching the dmg. Please suggest anything we can try to make the release out the door. Bug link- https://feedbackassistant.apple.com/feedback/16811025

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!

I now had the second user with 26.2. complaining about a hang in my app. The hang occurs when the first AppleScript for Mail is run. Here is the relevant section from the process analysis in Activity Monitor: + 2443 OSACompile (in OpenScripting) + 52 [0x1b32b30f4] + 2443 SecurityPolicyTestDescriptor (in OpenScripting) + 152 [0x1b32a2284] + 2443 _SecurityPolicyTest(char const*, void const*, unsigned long) (in OpenScripting) + 332 [0x1b32a2118] + 2443 InterpreterSecurity_ScanBuffer (in libInterpreterSecurity.dylib) + 112 [0x28c149304] + 2443 -[InterpreterSecurity scanData:withSourceURL:] (in libInterpreterSecurity.dylib) + 164 [0x28c148db4] + 2443 -[XProtectScan beginAnalysisWithFeedback:] (in XprotectFramework) + 544 [0x1d35a1e58] + 2443 -[XPMalwareEvaluation initWithData:assessmentClass:] (in XprotectFramework) + 92 [0x1d359ada4] + 2443 -[XPMalwareEvaluation initWithRuleString:withExtraRules:withURL:withData:withAssessmentClass:feedback:] (in XprotectFramework) + 36 [0x1d359b2a8] My app is correctly signed and notarised. The first user had to completely uninstall/reinstall the app and the everything worked again. Why does this happen? How can the problem be fixed?

I noticed, that even though my AutoFill Credential Provider Extension works with Safari for both Passwords and Passkeys, it doesn't work in context menus inside arbitrary textfields, meanwhile the same is true for the Apple Passwords app. This is a great hit to AutoFill productivity, as my extension is unable to fill textfields by just going to the context menu and clicking AutoFill > Passwords.. Is this a feature only available to Apple via private APIs, or is this something I can interface with? I checked and the Passwords app does use some undocumented but non-private entitlements: [Key] com.apple.authentication-services.access-credential-identities [Value] [Bool] true I also checked the responsible executable for some hints (AutoFillPanelService) however found nothing that would lead me to believe this is a public extension point. Another idea I had was trying to use a macOS Service for this, however Services in the "General" category won't show up in any context menu, only in the Application's Main Menu.

I'm a bit confused about if using App Attest is possible in enterprise builds. It shows up under identifiers in the apple dev portal and I can add it to my provisioning file and entitlements file. But if I go to keys I cannot create a key for it. This page implies it can be used for enterprise builds: After distributing your app through TestFlight, the App Store, or the Apple Developer Enterprise Program, your app ignores the entitlement you set and uses the production environment.

Hi, The email attached states that we need to add GoogleToolboxForMac's missing privacy manifest. I received the attached report after running my app privacy report, however it is different and does not include GoogleToolboxForMac. I'm not sure if we need to add the privacy manifest for GoogleToolboxForMac alone or for both of them. If yes, what should I put in my privacy manifest for GoogleToolboxForMac? IS IT BELOW CODE NEED TO ADD IN PRIVACY MANIFEST OR IS IT BELOW CODE NEED TO ADD IN PRIVACY MANIFEST Please reply ASAP Regards, Viharshitha

Why can’t sandboxed mac app store apps have full disk access available in the system settings for full disk access? I discovered mac app store apps in release mode cannot access the ai auggie command line program and other command line programs like opengrep on your system. Debug builds fine. I came up with a workaround: Since I have an ssh client built in for connecting to remote servers, why not connect to ssh on the same local machine… Ask the user for their username and password in a popup. To do this, you have to enable remote login on your mac in system settings -> sharing. In addition you must grant full disk access to cli ssh in system settings: add /usr/libexec/sshd-keygen-wrapper It all works, but I don’t see the cli program in mac settings. To remove the cli program you must run a command line program to remove all full disk access support from all apps. No way to just undo ssh. So my question is, even though I got CodeFrog all working for a mac app store release, should I not do it because it’s insecure or too complicated with the system settings? Should I instead sell the app off the store like Panic Nova? Need some advice. I have not implemented in app purchases yet. Should I just have a reality check and sell the app off the store, or try for app store approval? Bummer… Maybe I’m ahead of my time, but perhaps Apple could review the source code for apps requesting full disk access and make sure there’s nothing fraudulent in them. Then, developer tools app store apps could be in the store with the user’s assurance that nothing is happening behind the scenes that is scary. From: https://blog.greenrobot.com/2025/11/10/i-have-a-decision-to-make/ Related post: https://developer.apple.com/forums/thread/806187 I submitted a code level tech support question for this. They directed me here.

Hi, is it somehow possible to access a key that was generated by the DCAppAttestService generateKey() function? I need to be 100% sure that no actor from within or outside of my app can access the generated key with the DeviceCheck Framework. It would also be helpful to get some official resources to the topic. Thank you in advance, Mike

I have something with a new individual on my team I've never seen before. They checked out our code repository from git and now anytime they try to open a .json file that is legitimately just a text file, GateKeeper tells them it cannot verify the integrity of this file and offers to have them throw this file away. I've seen this with binaries, and that makes sense. I removed the com.apple.quarantine extended attribute from all executable files in our source tree, but I've never seen GateKeeper prompt on text files. I could remove the extended attribute from all files in our source tree, but I fear the next time he pulls from git he'll get new ones flagged. Is there someway around this? I've never personally seen GateKeeper blocking text files.

Hi everyone, I’m looking for clarification on best practices for storing API keys in an iOS app — for example, keys used with RevenueCat, PostHog, AWS Rekognition, barcode scanners, and similar third-party services. I understand that hard-coding API keys directly in the app’s source code is a bad idea, since they can be extracted from the binary. However, using a .plist file doesn’t seem secure either, as it’s still bundled with the app and can be inspected. I’m wondering: What are Apple’s recommended approaches for managing these kinds of keys? Does Xcode Cloud offer a built-in or best-practice method for securely injecting environment variables or secrets at build time? Would using an external service like AWS Secrets Manager or another server-side solution make sense for this use case? Any insights or examples of how others are handling this securely within Apple’s ecosystem would be greatly appreciated. Thanks for considering my questions! — Paul