Hello, Is there any way to detect if the iOS screen is currently being shared via FaceTime or iPhone Mirroring? Our application relies on this information to help ensure that users are not accessing it from one location while physically being in another.

Hi team, We are experiencing an issue where some users in China are unable to create passkeys due to authentication errors. This is the UI flows The method we use to prompt users is passkey creation. Technically, this is implemented using Apple’s AuthenticationServices framework. We create an instance of ASAuthorizationController and conform to ASAuthorizationControllerDelegate to handle the results of the authentication attempt. In failure cases, we receive ASAuthorizationError.failed (code 1004), along with some additional details describing the nature of the failure. However, we are currently unable to determine the exact root cause of this issue or how to resolve it. At this point, we can only make assumptions based on the limited error information provided. Our current hypothesis is that due to network restrictions, Apple may be unable to reach the .well-known endpoint where we host the associated domain file. Alternatively, even if the file is successfully loaded and cached to Apple’s CDN, the system in China may not be able to reach the CDN itself. We would greatly appreciate it if you could help us understand what might be causing this problem and guide us on how we can resolve it effectively. Thanks, Hung

We’ve identified an issue in our app where, upon clicking the "Call Customer Center" button, users are unexpectedly shown a logo and message option on a native pop-up window. However, this wasn't the case before, and it should only display a phone number to dial, which was given inside our code. This is incorrect and misleading for our users, as: We are a Canadian-based service and have no affiliation with US messaging chat. The messaging feature was never enabled or intended for our app. Our app should only initiate a phone call to our customer support center — no messages or branding from third parties should appear

General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

I added a feature to my app that retrieves only app settings (no personal data) from my API hosted on Cloudflare Workers. The app does not send, collect, track, or share any user data, and I do not store or process any personal information. Technical details such as IP address, user agent, and device information may be automatically transmitted as part of the internet protocol when the request is made, but my app does not log or use them. Cloudflare may collect this information. Question: Does this count as “data collection” for App Store Connect purposes, or can I select “No Data Collected”?

We implemented a feature to receive name and email address after Sign in with Apple, and it works perfectly in our testing. However, during the app review, they says it doesn't work, and the app is rejected. Why does it work differently?

I'm building a macOS app that registers itself for HTTP(S) url handling and would like it to participate in the ASWebAuthenticationSession fow. I did: update the plist to register as a handler for URL shemes (http, https, file) use NSWorkspace setDefaultApplication API to set this app as a default handler for urls in question wrote custom ASWebAuthenticationSessionWebBrowserSessionHandling implementation and set it as SessionManager's sessionHandler I launched this app from Xcode, then I triggered authentication flow from a third-party app. When the sign in flow is initiated, I can see that my app is activeated (willBecomeActive and didBecomeActive callbacks are both called), but there is no call for sessionHandler's begin() method. With some additional debugging I see that my app receives an apple event when the flow is started: {sfri,auth target=SafariLaunchAgent {qntp=90/$627......},aapd=TRUE If I switch system default browser back to Safari and then start the login flow, it correctly displays a sign in web page. What do I miss? PS. I'm on Tahoe 26.2

WebAuthn Level 3 § 6.3.2 Step 2 states the authenticator must : Check if at least one of the specified combinations of PublicKeyCredentialType and cryptographic parameters in credTypesAndPubKeyAlgs is supported. If not, return an error code equivalent to "NotSupportedError" and terminate the operation. On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and an ES256 credential is created when an RP passes a non-empty sequence that does not contain {"type":"public-key","alg":-7} (e.g., [{"type":"public-key","alg":-8}]). When I use Chromium 138.0.7204.92 on my laptop running Arch Linux in conjunction with the Passwords app (connected via the "hybrid" protocol), a credential is not created and instead an error is reported per the spec.

Migrating APP and users, obtaining the user's transfer_sub, an exception occurred: {"error":"invalid_request"} `POST /auth/usermigrationinfo HTTP/1.1 Host: appleid.apple.com Content-Type: application/x-www-form-urlencoded Authorization: Bearer {access_token} sub={sub}&target={recipient_team_id}&client_id={client_id}&client_secret={client_secret} The specific request is as follows: 15:56:20.858 AppleService - --> POST https://appleid.apple.com/auth/usermigrationinfo 15:56:20.858 AppleService - Content-Type: application/x-www-form-urlencoded 15:56:20.858 AppleService - Content-Length: 395 15:56:20.858 AppleService - Authorization: Bearer a56a8828048af48c0871e73b55d8910aa.0.rzvs.96uUcy1KBqo34Kj8qrPb4w 15:56:20.858 AppleService - 15:56:20.858 AppleService - sub=001315.1535dbadc15b472987acdf634719a06a.0600&target=WLN67KBBV8&client_id=com.hawatalk.live&client_secret=eyJraWQiOiIzODg5U1ZXNDM5IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJRMzlUU1BHMjk3IiwiaWF0IjoxNzU1MDcxNzc5LCJleHAiOjE3NTUwNzUzNzksImF1ZCI6Imh0dHBzOi8vYXBwbGVpZC5hcHBsZS5jb20iLCJzdWIiOiJjb20uaGF3YXRhbGsubGl2ZSJ9.8i9RYIcepuIiEqOMu1OOAlmmjnB84AJueel21gNapiNa9pr3498Zkj8J5MUIzvvnvsvUJkKQjp_VvnsG_IIrTA 15:56:20.859 AppleService - --> END POST (395-byte body) 15:56:21.675 AppleService - <-- 400 Bad Request https://appleid.apple.com/auth/usermigrationinfo(816ms) 15:56:21.675 AppleService - Server: Apple 15:56:21.675 AppleService - Date: Wed, 13 Aug 2025 07:56:22 GMT 15:56:21.675 AppleService - Content-Type: application/json;charset=UTF-8 15:56:21.675 AppleService - Content-Length: 27 15:56:21.675 AppleService - Connection: keep-alive 15:56:21.675 AppleService - Pragma: no-cache 15:56:21.675 AppleService - Cache-Control: no-store 15:56:21.676 AppleService - 15:56:21.676 AppleService - {"error":"invalid_request"} 15:56:21.676 AppleService - <-- END HTTP (27-byte body) ` Current Team ID: Q39TSPG297 Recipient Team ID: WLN67KBBV8 CLIENT_ID: com.hawatalk.live

I would like to confirm about fraud prevention using Device Check when publishing multiple apps. If the Team ID and Key ID are the same, will the values be shared across all apps with Device Check? With Device Check, only two keys can be created per developer account, and these two are primarily intended for key renewal in case of a leak, rather than for assigning different keys to each app, correct? If both 1 and 2 are correct, does that mean that Device Check should not be used to manage "one-time-only rewards per device" when offering them across multiple apps? Thank you very much for your confirmation.

Hi Apple Devs, For our app, we utilize passkeys for account creation (not MFA). This is mainly for user privacy, as there is 0 PII associated with passkey account creation, but it additionally also satisfies the 4.8: Login Services requirement for the App Store. However, we're getting blocked in Apple Review. Because the AASA does not get fetched immediately upon app install, the reviewers are not able to create an account immediately via passkeys, and then they reject the build. I'm optimistic I can mitigate the above. But even if we pass Apple Review, this is a pretty catastrophic issue for user security and experience. There are reports that 5% of users cannot create passkeys immediately (https://aninterestingwebsite.com/forums/thread/756740). That is a nontrivial amount of users, and this large of an amount distorts how app developers design onboarding and authentication flows towards less secure experiences: App developers are incentivized to not require MFA setup on account creation because requiring it causes significant churn, which is bad for user security. If they continue with it anyways, for mitigation, developers are essentially forced to add in copy into their app saying something along the lines of "We have no ability to force Apple to fetch the config required to continue sign up, so try again in a few minutes, you'll just have to wait." You can't even implement a fallback method. There's no way to check if the AASA is available before launching the ASAuthorizationController so you can't mitigate a portion of users encountering an error!! Any app that wants to use the PRF extension to encrypt core functionality (again, good for user privacy) simply cannot exist because the app simply does not work for an unspecified amount of time for a nontrivial portion of users. It feels like a. Apple should provide a syscall API that we can call to force SWCD to verify the AASA or b. implement a config based on package name for the app store such that the installation will immediately include a verified AASA from Apple's CDN. Flicking the config on would require talking with Apple. If this existed, this entire class of error would go away. It feels pretty shocking that there isn't a mitigation in place for this already given that it incentivizes app developers to pursue strictly less secure and less private authentication practices.

I was experiencing a weird sign in error when using apple sign in with my app and wanted to put it here for anyone else who might experience it in the future, and so apple can make this requirement more clear. I was using CloudKit and apple sign in. If you are not using both this probably does not apply to you. Every time I would go to sign in in the iOS simulator I would enter my password, hit "sign in", and everything just froze. The very odd reason for this is if you are using iCloudKit and apple sign in you need to go to specifically the "identifiers" in the "Certificates, Identifiers & Profiles" menu (https://aninterestingwebsite.com/account/resources/identifiers/list). And from there you specifically need an App ID Configuration with apple sign in enabled. From there you have to have the same exact bundle identifier in Xcode under project settings(not an upper tab just click your project in the left panel). And that should allow you to both pass validation and have your sign in work. Hope this helps!

Hi, preivously on appleid.apple.com, navigating to this page on safari would show the in-app modal to continue with Apple. Now with account.apple.com, this is not the case. We are not seeing the in-app modal to continue with Apple

Hi, we are experiencing a specific issue with the Private Email Relay service. Our domain e.glassesdirect.co.uk consistently fails SPF verification while our other domains pass. The Pattern: We've noticed that domains with SPF records fitting in 1-2 TXT strings pass, but this specific domain (~750 chars, 3 TXT strings) fails. Technical Details: Team ID: SM2J7LWD33 Domain: e.glassesdirect.co.uk SPF Record length: ~750 characters Third-party tools (MxToolbox) confirm the record is valid. We suspect Apple's verification parser might be failing to handle concatenated TXT strings or hitting a size limit. Could any Apple engineers confirm if there is a character limit or a bug in handling multi-part TXT records?

For my api I have a domain scheme of env.service.example.com. I am trying to setup sign in with apple, however, when trying to set my return urls, the env subdomain is stripped, making the return url incorrect. For example, when I try to set https://env.service.example.com/ it is changed to https://service.example.com/ when submitted. Is there any way around this issue?

Hello everyone, I'm developing a FIDO2 service using the AuthenticationServices framework. I've run into an issue when a user manually deletes a passkey from their password manager. When this happens, the ASAuthorizationError I get doesn't clearly indicate that the passkey is missing. The error code is 1001, and the localizedDescription is "The operation couldn't be completed. No credentials available for login." The userInfo also contains "NSLocalizedFailureReason": "No credentials available for login." My concern is that these localized strings will change depending on the user's device language, making it unreliable for me to programmatically check for a "no credentials" scenario. Is there a more precise way to determine that the user has no passkey, without relying on localized string values? Thank you for your help.

Hi everyone, I'm integrating Apple's DeviceCheck API into my app and have run into a strange issue that I can't find documented anywhere. The Problem When I call Apple's DeviceCheck query endpoint (POST https://api.devicecheck.apple.com/v1/query_two_bits), the response occasionally returns a last_update_time value that is in the future — ahead of the current server time. Example response: { "bit0": true, "bit1": false, "last_update_time": "2026-05" // future month, not yet reached } What I've Checked My server's system clock is correctly synced via NTP The JWT token I generate uses the current timestamp for the iat field This doesn't happen on every device — only on some specific devices The issue is reproducible on the same device across multiple calls Questions Is last_update_time sourced from the device's local clock at the time update_two_bits was called? Or is it stamped server-side by Apple? Could a device with an incorrectly set system clock (set to the future) cause Apple's servers to record a future last_update_time? Is there a recommended way to validate or sanitize last_update_time on the server side to handle this edge case? Has anyone else encountered this behavior? Any known workarounds? Any insight would be greatly appreciated. Thanks!

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

We are integrating Sign in with Apple for our web application and have been stuck on an invalid_client error during the token exchange step. The Problem The authorization step works fine — the user authenticates on Apple's page and a valid authorization code is returned to our callback URL. However, when we exchange that code at https://appleid.apple.com/auth/token, it returns: {"error": "invalid_client"} The Puzzling Part When we send a dummy/expired authorization code with the exact same client_id and client_secret, Apple returns: {"error": "invalid_grant", "error_description": "The code has expired or has been revoked."} This confirms that our client credentials (client_id + client_secret JWT) are valid and accepted by Apple. The invalid_client error only occurs when a real, freshly-issued authorization code is used. Configuration Service ID configured with Sign in with Apple enabled Primary App ID with Sign in with Apple capability enabled Domain verified, Return URL registered Key created with Sign in with Apple enabled, linked to the correct Primary App ID Client Secret JWT Generated per Apple's documentation: Header: alg: ES256, kid set to our Key ID Claims: iss: Team ID iat: current timestamp exp: iat + 6 months (within Apple's limit) aud: https://appleid.apple.com sub: Service ID (matches the client_id used in authorization) Signed with: the .p8 private key associated with the Key Token Exchange Request POST https://appleid.apple.com/auth/tokenContent-Type: application/x-www-form-urlencodedclient_id=client_secret=code=grant_type=authorization_coderedirect_uri= What We've Tried Standalone test endpoint — built a minimal endpoint (no framework) that does the token exchange via server-side curl. Same invalid_client. Multiple Service IDs — created and tried 3 different Service IDs. All produce the same error with real codes. Multiple Keys — tried 2 different keys. Same error. Verified redirect_uri matches exactly between the authorization request and token request. Verified client_id matches exactly between the authorization URL and token request. Used client_secret_post (credentials in body, not Basic auth header). Freshness — code is used immediately upon receipt (within seconds), well before the 5-minute expiry. Filed a Developer Support case — was directed to Forums. Summary Scenario code Result Dummy/expired code abc123 invalid_grant (credentials accepted) Real fresh code from Apple callback invalid_client This pattern suggests something goes wrong specifically when Apple validates the authorization code against the client — even though the client credentials themselves are accepted in isolation. Has anyone encountered this behavior? Is there a known configuration issue that could cause invalid_client only with valid authorization codes? Any guidance would be greatly appreciated.

I have two applications, and I recently decided to add the Apple Sign In feature. Initially, I configured it for one of the apps as the Primary ID for this feature. Everything worked well, and I decided to add it to the second app. I made a mistake and used the First app as Primary ID using the "Group with an existing primary App ID" flag. Now, when I sign in using the second app, I don't see it in the list of apps in iPhone Settings for Apple Sign In; I only see the primary app. And with that, I no longer see a prompt for sharing/hiding email, and I am unable to revoke credentials correctly. I decided to change the Second app's Sign-in config and set it as the Primary ID for the feature. I was hoping to get two apps independent for the SignIn. However, it doesn't seem to make a difference. The second app behaves the same way, as long as the first app used SignIn, the second one always thinks that the user has already used that feature and never shows the correct prompt. Is there something I missed after changing the Configuration?