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?

I recently turned on the enhanced security options for my macOS app in Xcode 26.0.1 by adding the Enhanced Security capability in the Signing and Capabilities tab. Then, Xcode adds the following key-value sets (with some other key-values) to my app's entitlements file. <key>com.apple.security.hardened-process.enhanced-security-version</key> <integer>1</integer> <key>com.apple.security.hardened-process.platform-restrictions</key> <integer>2</integer> These values appear following the documentation about the enhanced security feature (Enabling enhanced security for your app) and the app works without any issues. However, when I submitted a new version to the Mac App Store, my submission was rejected, and I received the following message from the App Review team via the App Store Connect. Guideline 2.4.5(i) - Performance Your app incorrectly implements sandboxing, or it contains one or more entitlements with invalid values. Please review the included entitlements and sandboxing documentation and resolve this issue before resubmitting a new binary. Entitlement "com.apple.security.hardened-process.enhanced-security-version" value must be boolean and true. Entitlement "com.apple.security.hardened-process.platform-restrictions" value must be boolean and true. When I changed those values directly in the entitlements file based on this message, the app appears to still work. However, these settings are against the description in the documentation I mentioned above and against the settings Xcode inserted after changing the GUI setting view. So, my question is, which settings are actually correct to enable the Enhanced Security and the Additional Runtime Platform Restrictions?

Please excuse my lack of understanding of what are probably fundamental concepts in iOS/iPadOS development but I have searched far and wide for documentation and haven't had much luck so far. I am not sure that what I want to do is even possible with an iPad iPadOS app. Goals: Develop a Swift iPadOS app that can digitally sign a file using a PIV SmartCard/Token (Personal Identity Verification Card): Insert a PIV SmartCard/Token (such as a Yubikey 5Ci) into the lightning port of an iPadOS device iPad (NOT MacOS) Interface with the SmartCard/Token to access the user's PIV certificate/signature and "use it" to sign a file Question 1: How to get the PIV Certificate from SmartCard/Token/Yubikey into iPadOS keychain?   * Do we need to get the PIV certificate into the iOS keychain? Is there another way to interact with a SmartCard directly?   * This should prompt the user for their PIN? Question 2: How to get our Swift app to hook into the event that the SmartCard/Token is inserted into the device and then interface with the user's certificate?   * When is the user prompted to enter their PIN for SmartCard/Token/Yubikey?   * Do we need to use CyrptoTokenKit to interface with a smartcard inserted into the lightning port of an iOS device?

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.

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!!!!

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!

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 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!

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.

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!

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,

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 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)"

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.

Hello, we are using DeviceCheck – App Attest in a production iOS app. The integration has been live for some time and works correctly for most users, but a small subset of users encounter non-deterministic failures that we are unable to reproduce internally. Environment iOS 14+ Real devices only (no simulator) App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Relevant code let service = DCAppAttestService.shared service.generateKey { keyId, error in // key generation } service.attestKey(keyId, clientDataHash: hash) { attestation, error in // ERROR: com.apple.devicecheck.error 3 / 4 } service.generateAssertion(keyId, clientDataHash: clientDataHash) { assertion, error in // ERROR: com.apple.devicecheck.error 3 / 4 } For some users we intermittently receive: com.apple.devicecheck.error error 3 com.apple.devicecheck.error error 4 Characteristics: appears random affects only some users/devices sometimes resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info Some questions: What is the official meaning of App Attest errors 3 and 4? Are these errors related to key state, device conditions, throttling, or transient App Attest service issues? Is there any recommended way to debug or gain more insight when this happens in production? Any guidance would be greatly appreciated, as this impacts real users and is difficult to diagnose. Thank you.

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.

QuickLookAR shares the actual USDZ model instead of the original website URL — critical copyright and data leak issue on iOS 26 Since iOS 26, QuickLookAR (or ARQuickLookPreviewItem) no longer preserves the original web URL when sharing a model. Instead of sending the link to the hosted file, the system directly shares the actual USDZ model file with the recipient. This is a critical regression and a severe breach of intellectual property protection, as it exposes proprietary 3D models that must never be distributed outside of the controlled web environment. In earlier iOS versions (tested up to iOS 18), QuickLookAR correctly handled sharing — the share sheet would send the website link where the model is hosted, not the file itself. Starting with iOS 26, this behavior has changed and completely breaks the intended secure flow for AR experiences. Our project relies on allowing users to view models in AR via QuickLook, without ever transferring the underlying 3D assets. Now, the share operation forces full file sharing, giving end users unrestricted access to the model file, which can be copied, rehosted, or reverse-engineered. This issue critically affects production environments and prevents us from deploying our AR-based solutions. Implement a standard QuickLookAR preview with a USDZ file hosted on your web server (e.g., via ARQuickLookPreviewItem). 2. Open the AR view on iOS 26. 3. Tap the Share icon from QuickLookAR. 4. Send via any messenger (Telegram, WhatsApp, etc.). 5. Observe that the actual .usdz model is sent instead of the original website URL. ⸻ Expected behavior: QuickLookAR should share only the original URL (as in iOS 17–18), not the file itself. This ensures that intellectual property and licensed 3D models remain protected and controlled by the content owner. ⸻ Actual behavior: QuickLookAR shares the entire USDZ file, leaking the model content outside of the intended environment. ⸻ Impact: • Violation of copyright and confidential data policies • Loss of control over proprietary 3D assets • Breaking change for all existing web-based AR integrations • Critical blocker for AR production deployment ⸻ Environment: • iOS 26.0 and 26.1 (tested on iPhone 14, iPhone 15) • Safari + QuickLookAR integration • Works correctly on iOS 17 / iOS 18 ⸻ Notes: This regression appears to have been introduced in the latest iOS 26 system handling of QuickLookAR sharing. Please escalate this issue to the ARKit / QuickLook engineering team as it directly affects compliance, IP protection, and usability of AR features across production applications. Additional Notes / Verification: Please test this behavior yourself using the CheckAR test model on my website: https://admixreality.com/ios26/ • If the login page appears, click “Check AR” and then “View in Your Space”. • On iOS 18 and earlier, sharing correctly sends the website URL. • On iOS 26, sharing sends the actual USDZ model file. This clearly demonstrates the regression and the security/IP issue.

I'm trying to export and re-import a P-256 private key that was originally generated via SecKeyCreateRandomKey(), but I keep running into roadblocks. The key is simply exported via SecItemExport() with format formatWrappedPKCS8, and I did set a password just to be sure. Do note that I must use the file-based keychain, as the data protection keychain requires a restricted entitlement and I'm not going to pay a yearly fee just to securely store some private keys for a personal project. The 7-day limit for unsigned/self-signed binaries isn't feasible either. Here's pretty much everything I could think of trying: Simply using SecItemImport() does import the key, but I cannot set kSecAttrLabel and more importantly: kSecAttrApplicationTag. There just isn't any way to pass these attributes upfront, so it's always imported as Imported Private Key with an empty comment. Keys don't support many attributes to begin with and I need something that's unique to my program but shared across all the relevant key entries, otherwise it's impossible to query for only my program's keys. kSecAttrLabel is already used for something else and is always unique, which really only leaves kSecAttrApplicationTag. I've already accepted that this can be changed via Keychain Access, as this attribute should end up as the entry's comment. At least, that's how it works with SecKeyCreateRandomKey() and SecItemCopyMatching(). I'm trying to get that same behaviour for imports. Running SecItemUpdate() afterwards to set these 2 attributes doesn't work either, as now the kSecAttrApplicationTag is suddenly used for the entry's label instead of the comment. Even setting kSecAttrComment (just to be certain) doesn't change the comment. I think kSecAttrApplicationTag might be a creation-time attribute only, and since SecItemImport() already created a SecKey I will never be able to set this. It likely falls back to updating the label because it needs to target something that is still mutable? Using SecItemImport() with a nil keychain (i.e. create a transient key), then persisting that with SecItemAdd() via kSecValueRef does allow me to set the 2 attributes, but now the ACL is lost. Or more precise: the ACL does seem to exist as any OS prompts do show the label I originally set for the ACL, but in Keychain Access it shows as Allow all applications to access this item. I'm looking to enable Confirm before allowing access and add my own program to the Always allow access by these applications list. Private keys outright being open to all programs is of course not acceptable, and I can indeed access them from other programs without any prompts. Changing the ACL via SecKeychainItemSetAccess() after SecItemAdd() doesn't seem to do anything. It apparently succeeds but nothing changes. I also reopened Keychain Access to make sure it's not a UI "caching" issue. Creating a transient key first, then getting the raw key via SecKeyCopyExternalRepresentation() and passing that to SecItemAdd() via kSecValueData results in The specified attribute does not exist. This error only disappears if I remove almost all of the attributes. I can pass only kSecValueData, kSecClass and kSecAttrApplicationTag, but then I get The specified item already exists in the keychain errors. I found a doc that explains what determines uniqueness, so here are the rest of the attributes I'm using for SecItemAdd(): kSecClass: not mentioned as part of the primary key but still required, otherwise you'll get One or more parameters passed to a function were not valid. kSecAttrLabel: needed for my use case and not part of the primary key either, but as I said this results in The specified attribute does not exist. kSecAttrApplicationLabel: The specified attribute does not exist. As I understand it this should be the SHA1 hash of the public key, passed as Data. Just omitting it would certainly be an option if the other attributes actually worked, but right now I'm passing it to try and construct a truly unique primary key. kSecAttrApplicationTag: The specified item already exists in the keychain. kSecAttrKeySizeInBits: The specified attribute does not exist. kSecAttrEffectiveKeySize: The specified attribute does not exist. kSecAttrKeyClass: The specified attribute does not exist. kSecAttrKeyType: The specified attribute does not exist. It looks like only kSecAttrApplicationTag is accepted, but still ignored for the primary key. Even entering something that is guaranteed to be unique still results in The specified item already exists in the keychain, so I think might actually be targeting literally any key. I decided to create a completely new keychain and import it there (which does succeed), but the key is completely broken. There's no Kind and Usage at the top of Keychain Access and the table view just below it shows symmetric key instead of private. The kSecAttrApplicationTag I'm passing is still being used as the label instead of the comment and there's no ACL. I can't even delete this key because Keychain Access complains that A missing value was detected. It seems like the key doesn't really contain anything unique for its primary key, so it will always match any existing key. Using SecKeyCreateWithData() and then using that key as the kSecValueRef for SecItemAdd() results in A required entitlement isn't present. I also have to add kSecUseDataProtectionKeychain: false to SecItemAdd() (even though that should already be the default) but then I get The specified item is no longer valid. It may have been deleted from the keychain. This occurs even if I decrypt the PKCS8 manually instead of via SecItemImport(), so it's at least not like it's detecting the transient key somehow. No combination of kSecAttrIsPermanent, kSecUseDataProtectionKeychain and kSecUseKeychain on either SecKeyCreateWithData() or SecItemAdd() changes anything. I also tried PKCS12 despite that it always expects an "identity" (key + cert), while I only have (and need) a private key. Exporting as formatPKCS12 and importing it with itemTypeAggregate (or itemTypeUnknown) does import the key, and now it's only missing the kSecAttrApplicationTag as the original label is automatically included in the PKCS12. The outItems parameter contains an empty list though, which sort of makes sense because I'm not importing a full "identity". I can at least target the key by kSecAttrLabel for SecItemUpdate(), but any attempt to update the comment once again changes the label so it's not really any better than before. SecPKCS12Import() doesn't even import anything at all, even though it does return errSecSuccess while also passing kSecImportExportKeychain explicitly. Is there literally no way?

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?

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!