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!
General
RSS for tagPrioritize user privacy and data security in your app. Discuss best practices for data handling, user consent, and security measures to protect user information.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
Issue: Plain Executables Do Not Appear Under “Screen & System Audio Recording” on macOS 26.1 (Tahoe)
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.
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!!!!
Topic:
Privacy & Security
SubTopic:
General
Tags:
Passkeys in iCloud Keychain
Authentication Services
Hi,
After enabling the new Enhanced Security capability in Xcode 26, I’m seeing install failures on devices running < iOS 26.
Deployment target: iOS 15.0
Capability: Enhanced Security (added via Signing & Capabilities tab)
Building to iOS 18 device error - Unable to Install ...Please ensure sure that your app is signed by a valid provisioning profile.
It works fine on iOS 26 devices.
I’d like to confirm Apple’s intent here:
Is this capability formally supported only on iOS 26 and later, and therefore incompatible with earlier OS versions?
Or should older systems ignore the entitlement, meaning this behavior might be a bug?
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.
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?
My app has been rejected by App Store review because the sign in with Apple functionality is not working properly. I'm able to reproduce the issue on my end but I don't understand why it's happening.
I have two other apps that implement the same OAuth flow in an identical manner, and those apps have no issues signing in with Apple.
I've copied my OAuth flow to a fresh project to see if that would make a difference, and it gives me the exact same error. In the simulator I get "invalid_request, invalid web redirect URL", and on-device the FaceID authentication fails with a very non-specific "Sign Up Not Completed" error.
I'm completely out of ideas here, so any guidance would be appreciated. Thanks!
Hi! Is it possible to disable the option for users to 'Sign in with Another Device'? I encounter this message during the authentication process and I want to prevent it from appearing. I appreciate your help and look forward to your response.
How can my password manager app redirect users to the “AutoFill Passwords & Passkeys” settings page?
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!
Topic:
Privacy & Security
SubTopic:
General
Tags:
Wallet
Authentication Services
Passkeys in iCloud Keychain
Managed Settings
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)
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.
Hi,
This issue is happening during Passkey creation.
We’ve observed that approximately 1% of our customer users encounter a persistent error during Passkey creation. For the vast majority, the process works as expected.
We believe our apple-app-site-association file is correctly configured, served directly from the RP ID over HTTPS without redirects, and is up-to-date. This setup appears to work for most users, and it seems the Apple CDN cache reflects the latest version of the file.
To help us diagnose and address the issue for the affected users, we would appreciate guidance on the following:
What tools or steps does Apple recommend to identify the root cause of this issue?
Are there any known recovery steps we can suggest to users to resolve this on affected devices?
Is there a way to force a refresh of the on-device cache for the apple-app-site-association file?
Thank you in advance for any input or guidance.
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
Topic:
Privacy & Security
SubTopic:
General
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.
Hi. I enter a password using the security command at the command line. It appears in the keychain access app, but not in the passwords app. I don't understand why.
rickhedin@Ricks-MacBook-Pro zalando % security add-generic-password -U -s "birds" -a "cats" -w "dogs"
rickhedin@Ricks-MacBook-Pro zalando %
rickhedin@Ricks-MacBook-Pro zalando % security find-generic-password -s "birds" -wa "cats"
dogs
rickhedin@Ricks-MacBook-Pro zalando %
I'm told the two apps are two views of the same data, so I guess some filter must be being applied?
Topic:
Privacy & Security
SubTopic:
General
I am currently working on ways my application which would monitor the dlopen() and dlsym() calls made on macOS.
In the current list of events endpoint security framework provides, I don't see a relevant event which would give me this information.
Are there any alternate ways we can get these events on macOS?
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.
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.
Hey there,
I’m currently exploring the possibility of integrating Sign in with Apple into my iOS app and backend.
Regarding the iOS app, I’ve read that when a user is signed in, you always need to call getCredentialState on the app’s launch. Is this true? If so, how is it possible to sign the user out then?
I intend to incorporate SwiftData and CloudKit into my application. In light of this, I’m curious about your approach to user management. Specifically, I’m wondering if you would store the user’s data in a Redis database after successful authentication on the backend. Or, would you separate the user data and save it using SwiftData/ CloudKit?
Hello,
I'm an application developer related to Apple system extensions. I developed an endpoint security system extension that can run normally before the 14.x system. However, after I upgraded to 15.x, I found that when I uninstalled and reinstalled my system extension, although the system extension was installed successfully, a system warning box would pop up when I clicked enable in the Settings, indicating a failure.
I conducted the following test. I reinstalled a brand-new MAC 15.x system. When I installed my applications, the system extensions could be installed successfully and enabled normally. However, when I uninstalled and reinstalled, my system extension couldn't be enabled properly and a system warning popped up as well. I tried disabling SIP and enabling System Extension Developers, but it still didn't work.
When the system warning box pops up, I can see some error log information through the console application, including an error related to
Failed to authorize right 'com.apple.system-extensions.admin' by client '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] for authorization created by '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] (3,0) (-60005) (engine 179)
as shown in the screenshot.
The same problem, mentioned in Cannot approve some extensions in MacOS Sequoia , but there is no solution