On macOS 26.1 (25B78) I can't give Full Disk Access to sshd-keygen-wrapper. Now my Jenkins jobs do not work because they do not have the permission to execute the necessary scripts. Until macOS 26.1 everything worked fine. I restarted the machine several times and tried to give access from Settings -> Privacy & Security -> Full Disk Access but it just does not work. I tried logging with ssh on the machine and executing a script but again nothing happened.

I can't find any information about why this is happening, nor can I reproduce the 'successful' state on this device. My team needs to understand this behavior, so any insight would be greatly appreciated! The expected behavior: If I delete both apps and reinstall them, attempting to open the second app from my app should trigger the system confirmation dialog. The specifics: I'm using the MSAL library. It navigates the user to the Microsoft Authenticator app and then returns to my app. However, even after resetting the phone and reinstalling both apps, the dialog never shows up (it just opens the app directly). Does anyone know the logic behind how iOS handles these prompts or why it might be persistent even after a reset? Thanks in advance!

Hello everyone. Hope this one finds you well) I have an issue with integrating a FIDO2 server with ASAuthorizationController. I have managed to register a user with passkey successfully, however when authenticating, the request for authentication response fails. The server can't validate signature field. I can see 2 possible causes for the issue: ASAuthorizationPlatformPublicKeyCredentialAssertion.rawAuthenticatorData contains invalid algorithm information (the server tries ES256, which ultimately fails with false response), or I have messed up Base64URL encoding for the signature property (which is unlikely, since all other fields also require Base64URL, and the server consumes them with no issues). So the question is, what encryption algorithm does ASAuthorizationController use? Maybe someone has other ideas regarding where to look into? Please help. Thanks)

冷启动后我们读文件，发现："error_msg":"未能打开文件“FinishTasks.plist”，因为你没有查看它的权限。 是否有这些问题： 「iOS 26 iPhone 16,2 cold launch file access failure」） 核心内容：多名开发者反馈 iPhone 15 Pro（iOS 26.0/26.1）冷启动时读取 Documents 目录下的 plist 文件提示权限拒绝，切后台再切前台恢复，苹果员工回复「建议延迟文件操作至 applicationDidBecomeActive 后」。

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.

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.

The One-time codes documentation details how to enable autofill for SMS based codes. However, there is no details about how to correctly implement autofill for email based codes. I am observing the email based autofill works inconsistently when using email based OTC. In my application: There is latency of 10-15 seconds from when the email arrives to when it is available for autofill. After the autofill feature is used, the OTC email is not being deleted from the inbox automatically. Without documentation, it's unclear to me what I might be doing wrong that is causing these side effects. I found an ietf proposal for how autofill with email based codes might work, but it’s unclear if this is how Apple has implemented the feature: https://www.ietf.org/archive/id/draft-wells-origin-bound-one-time-codes-00.html#name-email Existing docs for Autofill using SMS: https://developer.apple.com/documentation/security/enabling-autofill-for-domain-bound-sms-codes

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!

In our mobile we are using UUID as a device identifier . With this ID we using certain function like Primary device and secondary devices .
Primary device has more control to the app other than secondary device .
In our case user is getting new iPhone and the apps related data are moved to new device from old device from clone option.

While moving the keychain data is also moved , which is causing the new device also has same UUID and the customer are using both the devices in some cases ,

So both devices are considered as primary in our app .
Is there any way to identify the device is cloned ,

Needed suggestion

I'm experiencing a strange issue where ASWebAuthenticationSession works perfectly when running from Xcode (both Debug and Release), but fails on TestFlight builds. The setup: iOS app using ASWebAuthenticationSession for OIDC login (Keycloak) Custom URL scheme callback (myapp://) prefersEphemeralWebBrowserSession = false The issue: When using iOS Keychain autofill (with Face ID/Touch ID or normal iphone pw, that auto-submits the form) -> works perfectly When manually typing credentials and clicking the login button -> fails with white screen When it fails, the form POST from Keycloak back to my server (/signin-oidc) never reaches the server at all. The authentication session just shows a white screen. Reproduced on: Multiple devices (iPhone 15 Pro, etc.) iOS 18.x Xcode 16.x Multiple TestFlight testers confirmed same behavior What I've tried: Clearing Safari cookies/data prefersEphemeralWebBrowserSession = true and false Different SameSite cookie policies on server Verified custom URL scheme is registered and works (testing myapp://test in Safari opens the app) Why custom URL scheme instead of Universal Links: We couldn't get Universal Links to trigger from a js redirect (window.location.href) within ASWebAuthenticationSession. Only custom URL schemes seemed to be intercepted. If there's a way to make Universal Links work in this context, without a manual user-interaction we'd be happy to try. iOS Keychain autofill works The only working path is iOS Keychain autofill that requires iphone-authentication and auto-submits the form. Any manual form submission fails, but only on TestFlight - not Xcode builds. Has anyone encountered this or know a workaround?

Hi everyone, I'm currently working on a native macOS app (built with SwiftUI) and I'm trying to implement Password AutoFill functionality so users can use their saved credentials from Keychain or third-party password managers. I've gone through Apple's documentation, WWDC sessions, and sample code, but I've noticed that the resources primarily focus on iOS and web implementations. There's very limited guidance specifically for macOS. I've set up: Associated Domains entitlement with the webcredentials: service The apple-app-site-association file on my server TextField with .textContentType(.username) and SecureField with .textContentType(.password) However, I'm still not seeing the expected AutoFill behavior on macOS like I would on iOS. Has anyone successfully implemented Password AutoFill on a native macOS app? Are there any macOS-specific considerations or additional steps required that differ from iOS? Any guidance, sample code, or pointers to documentation I might have missed would be greatly appreciated.

Hello Team, We’ve recently started receiving reports from our customer base (Trellix) regarding issues with Full Disk Access (FDA) for Trellix binaries on macOS devices running Tahoe 26.1 (released on November 3, 2025). The issue occurs when users attempt to add Trellix CLI binaries under FDA to grant the required permissions; the binaries fail to appear under the FDA settings, even after selection. Upon further investigation, this appears to be a macOS 26.1–specific issue and not observed in earlier versions. Similar reports have been noted across various forums, indicating that the issue affects multiple binaries, not just Trellix: Some of the discussions on the same issue I see online. https://developer.apple.com/forums/thread/806187 https://developer.apple.com/forums/thread/806156 https://forum.logik.tv/t/macos-26-1-installation-issue-wait-before-updating/13761 https://www.reddit.com/r/MacOS/comments/1os1ph3/cant_add_anything_to_privacy_security_full_disk/ I have also logged FB21009024 for the same. We would like to understand when we can expect this to be fixed, since the issue persists even in 26.2 Beta and also whether the workaround of dragging and dropping the binaries can still be suggested?

While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.

Hi... It would be nice if Apple / XCode would be so gracious to explore the possibility of providing the ability to include: Code scrambling / renaming Control-flow obfuscation String encryption Anti-debugging Anti-hooking Jailbreak detection App integrity checks Runtime tamper detection That way, we could eliminate the need to settle for third-party software. Who do we have to bribe to submit such a request and entertain such an idea?

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.

When trying to check if a certificate has been revoked with SecPolicyCreateRevocation (Flags: kSecRevocationUseAnyAvailableMethod | kSecRevocationRequirePositiveResponse) and SecTrustEvaluateWithError I always get the result error code errSecIncompleteCertRevocationCheck, regardless if the certificate was revoked or not. Reproduction: Execute the program from the attached Xcode project (See Feedback FB21224106). Error output: Error: Error Domain=NSOSStatusErrorDomain Code=-67635 ""revoked.badssl.com","E8","ISRG Root X1" certificates do not meet pinning requirements" UserInfo={NSLocalizedDescription="revoked.badssl.com","E8","ISRG Root X1" certificates do not meet pinning requirements, NSUnderlyingError=0x6000018d48a0 {Error Domain=NSOSStatusErrorDomain Code=-67635 "Certificate 0 “revoked.badssl.com” has errors: Failed to check revocation;" UserInfo={NSLocalizedDescription=Certificate 0 “revoked.badssl.com” has errors: Failed to check revocation;}}} To me it looks like that the revocation check just fails („Failed to check revocation;“), no further information is provided by the returned error. In the example the certificate chain of https://revoked.badssl.com (default code) and https://badssl.com is verified (to switch see comments in the code). I have a proxy configured in the system, I assume that the revocation check will use it. On the same machine, the browsers (Safari and Google Chrome) can successfully detect if the certificate was revoked (revoked.badssl.com) or not (badssl.com) without further changes in the system/proxy settings. Note: The example leaks some memory, it’s just a test program. Am I missing something? Feedback: FB21224106

While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.

Since October 3rd, I've stopped receiving responses to the Private Access Tokens challenge. I'm using this link: https://demo-issuer.private-access-tokens.fastly.com/.well-known/token-issuer-directory. I receive tokens from Fastly and return a header to the iOS app, but then I don't receive another authentication request from iOS. The user has automatic verification enabled on their phone. The problem is global and affects all my mobile app users. Has anyone encountered a similar problem and found a solution?

I read online that there is no way to extract the call log from an iPhone. I want to develop an app to help people remember to call their mom, and if they did, the "nagging" would disappear automatically. I'm looking for any workaround to know when a user called someone, without having them log it manually.

We're experiencing crashes in our production iOS app related to Apple's DeviceCheck framework. The crash occurs in DCAnalytics internal performance tracking, affecting some specific versions of iOS 18 (18.4.1, 18.5.0). Crash Signature CoreFoundation: -[__NSDictionaryM setObject:forKeyedSubscript:] + 460 DeviceCheck: -[DCAnalytics sendPerformanceForCategory:eventType:] + 236 Observed Patterns Scenario 1 - Token Generation: Crashed: com.appQueue EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000010 DeviceCheck: -[DCDevice generateTokenWithCompletionHandler:] Thread: Background dispatch queue Scenario 2 - Support Check: Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000008 DeviceCheck: -[DCDevice _isSupportedReturningError:] DeviceCheck: -[DCDevice isSupported] Thread: Main thread Root Cause Analysis The DCAnalytics component within DeviceCheck attempts to insert a nil value into an NSMutableDictionary when recording performance metrics, indicating missing nil validation before dictionary operations. Reproduction Context Crashes occur during standard DeviceCheck API usage: Calling DCDevice.isSupported property Calling DCDevice.generateToken(completionHandler:) (triggered by Firebase App Check SDK) Both operations invoke internal analytics that fail with nil insertion attempts. Concurrency Considerations We've implemented sequential access guards around DeviceCheck token generation to prevent race conditions, yet crashes persist. This suggests the issue likely originates within the DeviceCheck framework's internal implementation rather than concurrent access from our application code. Note: Scenario 2 occurs through Firebase SDK's App Check integration, which internally uses DeviceCheck for attestation. Request Can Apple engineering confirm if this is a known issue with DeviceCheck's analytics subsystem? Is there a recommended workaround to disable DCAnalytics or ensure thread-safe DeviceCheck API usage? Any guidance on preventing these crashes would be appreciated.