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, 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?

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!

We need to transfer an App to other developer account, both the account are belong to our company. As we know, our app is using the Sign in with Apple function that we need to do some transfer job and we refer to this document: https://developer.apple.com/documentation/technotes/tn3159-migrating-sign-in-with-apple-users-for-an-app-transfer. There is a lot of users using the Sign in with Apple in our app, totally serval millions. To avoid risks as much as possible that we have to make the work flow very clearly, so we're seeking help here. I have serval questions, some I've got the answers from Google gemini and this Forums, I will list them below, please take a look what I understanding is correct or not, thanks. A. From the document above, can I performed the Steps 1&2 before the app transfer? if so, is there a maximum lead time for these transfer_subs? B. Regarding Step 5(Team B exchanging transfer identifiers via https://appleid.apple.com/auth/usermigrationinfo) are there specific rate limits (requests per second/minute) for this endpoint? Cause we have a huge number of user whose using the Sign in with Apple, we have to transfer the sub values as soon as possible. C. Cause we have a huge number of user whose using the Sign in with Apple again, This transfer job involves huge risks. So, is there any way to simulate these whole operations? Answer by my self: NO.

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.

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

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.

Apple Sign In - "Sign up not completed" Error in Development Build (React Native / Expo) Problem Summary I'm implementing Apple Sign In in a React Native app using expo-apple-authentication. The Apple sign-in dialog appears as expected, but after tapping "Continue," it displays the message: "Sign up not completed". No credential is returned, and the promise eventually rejects with ERR_REQUEST_CANCELED. App Configuration Platform: React Native (Expo SDK 52) Library: expo-apple-authentication v7.1.3 Target: iOS development build (not Expo Go) Bundle ID: com.example.appname.nativetest (new App ID created for testing) Apple Developer Console Setup (Reviewed Carefully) App ID Explicit App ID (not a wildcard) "Sign In with Apple" capability enabled No associated Services IDs or Sign In with Apple Keys Provisioning Profile Development profile created for the test App ID Profile includes the test device and development certificate Installed successfully and used to sign the app Certificates and Signing Valid Apple Developer Program membership Development certificate installed and selected during build App installs and launches properly on the test device Implementation Attempts Attempt 1: Supabase OAuth Method Initially tried using Supabase’s built-in Apple OAuth provider: Configured with team ID, key ID, and JWT credentials Proper redirect URLs and scheme were in place Resulted in OAuth URL pointing to Supabase instead of Apple, with incomplete client ID Ultimately moved to native implementation for improved control and reliability Attempt 2: Native Apple Sign In (Current Approach) Using expo-apple-authentication with the following code: const credential = await AppleAuthentication.signInAsync({ requestedScopes: [ AppleAuthentication.AppleAuthenticationScope.FULL_NAME, AppleAuthentication.AppleAuthenticationScope.EMAIL, ], }); Relevant app.config.js Section: ios: { bundleIdentifier: 'com.example.appname.nativetest', usesAppleSignIn: true, infoPlist: { NSAppTransportSecurity: { NSAllowsArbitraryLoads: true, NSAllowsLocalNetworking: true, }, }, }, plugins: ['expo-apple-authentication'] Observed Behavior AppleAuthentication.isAvailableAsync() → true Credential state → NOT_FOUND (expected for new user) Apple Sign In dialog appears and allows interaction User taps "Continue" → dialog reports "Sign up not completed" Eventually returns: [Error: The user canceled the authorization attempt], code ERR_REQUEST_CANCELED Confirmed Working Aspects AppleAuthentication API is available and initialized App is signed correctly and launches on the physical test device Apple Sign In dialog appears with correct styling and options Same result observed across both Wi-Fi and cellular networks Clean Setup and Debugging Performed Removed all previous build artifacts Created a new App ID and new provisioning profile Rebuilt the app using expo run:ios --device Validated entitlements and provisioning assignments Removed any Services IDs and Apple Sign In keys used in previous attempts Verified ATS (App Transport Security) policies allow dev-time communication Environment Information Device: iPhone (not simulator) iOS Version: 18.5 Xcode: Latest version Apple ID: Developer account with 2FA enabled Build Method: EAS CLI using expo run:ios --device Open Questions Has anyone experienced the "Sign up not completed" issue with a clean native implementation in Expo? Are there known limitations when testing Apple Sign In in local development builds? Could prior Apple ID authorization attempts impact sign-in behavior during testing? Are there any additional configuration steps, Info.plist changes, or entitlements required beyond those listed above? Thank you in advance for any suggestions or guidance. We’re hoping this is simply a configuration detail that needs to be adjusted.

https://developer.apple.com/news/?id=j9zukcr6 starting from Jan 2026 there is change in requirements for account notifications for Sign in with Apple. Does this apply only to developers based in South Korea or all apps which are avai via the korean App Store?

On iOS 26, QuickLookAR (ARQuickLookPreviewItem) shares the actual .usdz file via the system Share Sheet instead of the original website URL. This is a regression from iOS 17–18, where sharing correctly preserved and sent only the source URL. Repro steps: 1. Open a web-hosted USDZ model in QuickLookAR (Safari). 2. Tap Share. 3. Share via any messenger. 4. The full .usdz file is sent. Expected: Share Sheet sends only the original URL. Actual: Share Sheet sends the USDZ file. Impact: Uncontrolled distribution of proprietary 3D assets. Critical IP / data leak. Blocks production AR deployments relying on QuickLook. Environment: iOS 26.0–26.1, iPhone 14 / 15. Works as expected on iOS 17–18. Test case: https://admixreality.com/ios26/

Hey all, Question for the masses.... Does the Yubikey authentication have a OS dependency and it only works with a stable, public OS? Does Azure/Okta/Yubikey beta OS26? My CEO installed iPadOS 26 on his iPad and was not able to authenticate via Yubikey into our company environment. I ran the same scenario on my iPad using iPadOS 26 and I had the same results. Downgrading to iPAdOS doesn't pose these issues. I'm assuming something isn't fine-tuned yet?

I've made my first app and encountered an unexpected (potentially existential) issue. The Manager app is designed to tag 3rd party "plugins" used by a DAW, storing metadata in a local SQLite database, and move them between Active and Inactive folders. This allows management of the plugin collection - the DAW only uses what's in the Active folder. Permissions are obtained via security-scoped bookmarks on first launch. The app functions as intended: plugin bundles move correctly and the database tracks everything. No information is written to the plugins themselves. The Problem:
When moving plugins using fs.rename() , the MAS sandbox automatically adds the com.apple.quarantine extended attribute to moved files. When the DAW subsequently rebuilds its plugin cache, it interprets quarantined plugins as "corrupt" or potentially malicious and refuses to load them. Technical Details: Moving files with NSFileManager or Node.js fs APIs within sandbox triggers quarantine Sandboxed apps cannot call xattr -d com.apple.quarantine or use removexattr() The entitlement com.apple.security.files.user-selected.read-write doesn't grant xattr removal rights User workaround: run xattr -cr /path/to/plugins in Terminal - not acceptable for professional users Question:
Is there any MAS-compliant way to move files without triggering quarantine, or to remove the quarantine attribute within the sandbox? The hardened-runtime DMG build works perfectly (no sandbox = no quarantine added). Any insight 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, In our app we are using DeviceCheck (App Attest) in a production environment iOS. The service works correctly for most users, but a user reported failure in a flow that use device check service. This failure is not intermittently, it is constant. We are unable to reproduce this failure and we are believing that this failure occurred by new version ios 26.3 because for others users using early versions the service is normally. Environment iOS 26.3 Real device App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Characteristics: appears constantly affects only unique user -Don't resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info (Error Domain=com.apple.devicecheck.error Code=3 "(null)") We saw about this error code 3 in this post 812308, but it's not our case because the ios version in this case is not iOS 17.0 or earlier. Please, help us any guidance for solution. Thank you

I’m trying to update the Domains and Redirects section for my Services ID configuration in Apple Developer (for Sign in with Apple). When I add new domains and click Save, nothing happens. In the browser console, I see a network request that fails with: PATCH not supported What I’ve tried so far: Logging out/in and refreshing the page Clearing browser cache and cookies Trying in Safari, Chrome, and incognito mode Verifying domain formatting (HTTPS, no trailing slash, domain is live) The issue persists in all browsers I’ve tested. Request: Is this a known issue with the Developer portal, or is there an alternative method to update my Services ID domains? Any guidance would be appreciated. Thanks,

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)

Title: Sporadical - Permissions Not Cleared After App Uninstallation on iOS18 I install and launch my private MAUI App I ask for example Bluetooth permissions (can be any other permission) I tap Allow button on native settings (or Don't Allow) I unistall app from real phone (we can wait for a while) I install and launch My Private MAUI App I ask for example Bluetooth permissions &lt;- here is an issue. Bluetooth is already granted, so I cannot ask for it again. Occurrence: This issue occurs inconsistently: On iOS 18.5: approximately 5 out of 10 times On iOS 17: approximately 1 out of 50 times Tested using my automated system using Appium latest. After each scenario I unistall app using: "mobile: removeApp" with bundleId

Recently, we received an user enquiry regarding the inability to perform bookings for the app. After investigation, we found that the issue appears to be caused by the failure of the Apple DeviceCheck service. Based on our checks, approximately 0.01% of requests fail each day (e.g., on 26 June: 6 failures out of 44,544 requests) when using Apple DeviceCheck. Could you please assist in raising the following enquiries with Apple Support? What is the typical failure rate of Apple DeviceCheck? Are there any reliability metrics or benchmarks for its performance? How can the failures be prevented, or is there a recommended retry mechanism to handle such failures? Does the iOS version affect the performance or reliability of Apple DeviceCheck? Are there known issues or limitations with specific iOS versions? How long does the token remain valid, and when should a new one be retrieved? Does using a jailbroken device affect the functionality of Apple DeviceCheck?

I am trying to setup remote Java debugging between two machines running macOS (15.6 and 26). I am able to get the Java program to listen on a socket. However, I can connect to that socket only from the same machine, not from another machine on my local network. I use nc to test the connection. It reports Connection refused when trying to connect from the other machine. This issue sounds like it could be caused by the Java program lacking Local Network system permission. I am familiar with that issue arising when a program attempts to connect to a port on the local network. In that case, a dialog is displayed and System Settings can be used to grant Local Network permission to the client program. I don't know whether the same permission is required on the program that is receiving client requests. If it is, then I don't know how to grant that permission. There is no dialog, and System Settings does not provide any obvious way to grant permission to a program that I specify. Note that a Java application is a program run by the java command, not a bundled application. The java command contains a hard-wired Info.plist which, annoyingly, requests permission to use the microphone, but not Local Network access.

Hello. I have issue with implementing "Sign in with Apple" on my website. As folow, I have created: App ID identifier: com.livnobus.app (G2F5N5UHYZ) Service ID identifier: com.livnobus.client (B25ZN8P84U) with option enabled "Sign in with Apple" and configuration (Primary App ID and Webiste URLs) Key ID: 43N8XKUW7S with option enabled "Sign in with Apple" and configuration (Primary App ID and Grouped App Ids) When I click "Sign in with Apple" on my website (https://dev.livnobus.com/auth/login), system redirect me to https://appleid.apple.com/ and error show "invalid_client". Redirect URL on my web site is: https://appleid.apple.com/auth/authorize?client_id=com.livnobus.client&redirect_uri=https%3A%2F%2Fdev.livnobus.com%2Fauth%2Fapple%2Fcallback&scope=name%20email&response_type=code&response_mode=form_post&state=eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO&nonce=e7c7a242-1977-47ea-9013-98820c24bfba.eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO There was old Service ID identifier com.livnobus.app-client, for which I lost private KEY, so I have created new one: com.livnobus.client With old Service ID com.livnobus.app-client, https://appleid.apple.com/ shows me Apple form for sign in, but with new Service ID com.livnobus.client there is error "invalid_client" https://appleid.apple.com/auth/authorize?client_id=com.livnobus.app-client&redirect_uri=https%3A%2F%2Fdev.livnobus.com%2Fauth%2Fapple%2Fcallback&scope=name%20email&response_type=code&response_mode=form_post&state=eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO&nonce=e7c7a242-1977-47ea-9013-98820c24bfba.eGAgdpLrvskJc26RbTizc9TGwxnL6KAEJOf68pmO These changes I have made last Friday, and since then I can't use "Sign in with Apple" on my website. Thanks!