Hello,
I am unable to configure Sign in with Apple on my developer account.
Whenever I try to:
Enable/disable the Sign in with Apple capability in my App ID, or
Configure a Service ID for web authentication,
the portal does not save my changes.
In the browser developer console, I consistently see this error:
Request URL: https://developer.apple.com/services-account/v1/bundleIds/XXXXXXXX
Request Method: PATCH
Status Code: 501 Not Implemented
This happens across all browsers (Safari, Chrome, Incognito) and even after clearing cache. It affects my entire account, not just one App ID.
I have already tried:
Creating a new Service ID → still fails.
Creating a new App ID → still fails.
Re-enabling the capability → save does not work.
Different browsers and devices → same result.
Has anyone else experienced this issue, and is there a known fix?
Or is this something that Apple Developer Support needs to resolve at the account level?
Prioritize 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
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.
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!
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 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 Apple,
Currently we want to have enhancement for SMS OTP that we want to implement OTP Autofill, But after do some research we're stuck with option that the OTP only show in keyboard suggestion, is there any way for making OTP is automatically filled without user have to click the keyboard suggestion when receiving the SMS.
Thanks
Best Regards,
Admiral Sultano Harly.
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!
Hello,
I’m trying to remove the “Sign in with Apple” for my app via the iOS settings (also tried on a Mac, and on the web via account.apple.com).
When I tap “Stop Using”, nothing happens, the dialog disappear but the app remains listed.
Someone said on a forum that the issue is linked with the ServiceId that doesn't exist anymore. But how to recover it ? And anyway this behavior is unintended and creates a gap in the process.
Has anyone experienced this before? Is there a known fix, or should I contact Apple Support directly for server-side revocation?
Thank you!
Topic:
Privacy & Security
SubTopic:
Sign in with Apple
Is there any particular reason why ASWebAuthenticationSession doesn't have support for async/await? (example below)
do {
let callbackURL = try await webAuthSession.start()
} catch {
// handle error
}
I'm curious if this style of integration doesn't exist for architectural reasons? Or is the legacy completion handler style preserved in order to prevent existing integrations from breaking?
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.
I am implementing Apple Sign-In for a multi-platform application, specifically for the web component using the REST API flow.
I am encountering an invalid_request Invalid web redirect url error when attempting to use a newly registered redirect URL.
Here are the details:
Original Test URL: I initially registered a redirect URL, let's call it [Your Original Test Redirect URL, e.g., https://test.yourdomain.com/auth/callback], for testing purposes. This URL worked correctly.
New Service URL: I then registered a second redirect URL, [Your New Service Redirect URL, e.g., https://www.yourdomain.com/auth/callback], intended for my production service. This URL was registered approximately 5 days ago (including the weekend).
The Problem: The new service URL ([Your New Service Redirect URL]) is still not working and consistently returns the invalid_request Invalid web redirect url error.
Puzzling Behavior: Furthermore, I have since deleted the original test URL ([Your Original Test Redirect URL]) from the Service ID configuration in the Apple Developer portal. However, the deleted test URL still appears to function correctly when I use it.
This situation is highly confusing: The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational.
The Service ID in question is [Your Service ID, e.g., com.yourdomain.service].
Could you please investigate why the new redirect URL ([Your New Service Redirect URL]) is not becoming active and is returning the invalid_request error, and also explain why the deleted URL ([Your Original Test Redirect URL]) remains functional?
Any guidance or assistance you can provide to resolve this issue with the new URL would be greatly appreciated. Thank you for your time and support.
Sincerely,
I have the exact same problem.
The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational.
In addition to the above problem, I also get a response of 'invalid_client' when I newly register a service in configuration.
Please check it out as it needs to be resolved quickly.
I'm using aws cognito for authentication in my app, and added the "Sign in with apple" identity provider. Not working at all by displaying "Sign Up Not Completed" error.
I am using custom domain in cognito..
I tried recreating the Private Key, and also recreating the Service Identifier. Nothing helped.
Anyone experiencing anything like this?
I hope this problem could be solved, also in case any other one strugling the same issue could be helpful.
We are developing an iOS App which use "sign in with Apple" feature.
We found we can not login with this feature, the "sign in with Apple" dialog box always flash an error info "Sign-Up Not Complete".
We have double checked configuration of Bundle ID, and xcode capabilities, info.plist, entitlements, etc.
We have even changed the developer team, using other bundle ID and demo code to testify this, also got failure of "Sign-Up Not Complete" error.
We did even just use Apple official demo code (https://developer.apple.com/documentation/AuthenticationServices/implementing-user-authentication-with-sign-in-with-apple), also got the same failure.
Interestingly, we found that using some old Bundle IDs which created before (even we did not use it for App yet), we could get "sign in with Apple" success logged in.
Therefore we now can not include "sign in with Apple" feature in our App today, and this is the key feature in our App.
Please help.
Since there is very little information we could collect, I just put the debug error here:
Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.nethawk.flutter.battlebuddy}
LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler}
Attempt to map database failed: permission was denied. This attempt will not be retried.
Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler}
Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)"
ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)"
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?
During internal testing, we observed the following behavior and would appreciate clarification on whether it is expected and supported in production environments.
When generating an elliptic-curve cryptographic key pair using "kSecAttrTokenIDSecureEnclave", and explicitly specifying a "kSecAttrAccessGroup", we found that cryptographic operations (specifically encryption and decryption) could be successfully performed using this key pair from two distinct applications. Both applications had the Keychain Sharing capability enabled and were signed with the same provisioning profile identity.
Given the documented security properties of Secure Enclave, backed keys, namely that private key material is protected by hardware and access is strictly constrained by design, we would like to confirm whether the ability for multiple applications (sharing the same keychain access group and signing identity) to perform cryptographic operations with the same Secure Enclave–backed key is expected behavior on iOS.
Specifically, we are seeking confirmation on:
Whether this behavior is intentional and supported in production.
Whether the Secure Enclave enforces access control primarily at the application-identifier (App ID) level rather than the individual app bundle level in this scenario.
Whether there are any documented limitations or guarantees regarding cross-application usage of Secure Enclave keys when keychain sharing is configured.
Any guidance or references to official documentation clarifying this behavior would be greatly appreciated.
Topic:
Privacy & Security
SubTopic:
General
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.
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
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.
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?