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?

Hi, I’ve added attestation to my app, and everything worked as expected during setup. However, after deployment, I noticed some unknownSystemFailure entries in the production logs on New Relic. Could you help me understand what typically causes this error? The documentation suggests issues such as failing to generate a token. What scenarios could lead to that?

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://aninterestingwebsite.com/documentation/security/enabling-autofill-for-domain-bound-sms-codes

Hello I'm using Auth0 for handling auth in my app When the user wants to sign in, it will show the auth system pop-up And when the user wants to log out it shows the same pop-up My issue is how to replace the Sign In text in this pop-up to show Sign Out instead of Sign In when the user wants to sign out?

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

Estou compartilhando algumas observações técnicas sobre Crash Detection / Emergency SOS no ecossistema Apple, com base em eventos amplamente observados em 2022 e 2024, quando houve chamadas automáticas em massa para serviços de emergência. A ideia aqui não é discutir UX superficial ou “edge cases isolados”, mas sim comportamento sistêmico em escala, algo que acredito ser relevante para qualquer time que trabalhe com sistemas críticos orientados a eventos físicos. Contexto resumido A partir do iPhone 14, a Detecção de Acidente passou a correlacionar múltiplos sensores (acelerômetros de alta faixa, giroscópio, GPS, microfones) para inferir eventos de impacto severo e acionar automaticamente chamadas de emergência. Em 2022, isso resultou em um volume significativo de falsos positivos, especialmente em atividades com alta aceleração (esqui, snowboard, parques de diversão). Em 2024, apesar de ajustes, houve recorrência localizada do mesmo padrão. Ponto técnico central O problema não parece ser hardware, nem um “bug pontual”, mas sim o estado intermediário de decisão: Aceleração ≠ acidente Ruído ≠ impacto real Movimento extremo ≠ incapacidade humana Quando o classificador entra em estado ambíguo, o sistema depende de uma janela curta de confirmação humana (toque/voz). Em ambientes ruidosos, com o usuário em movimento ou fisicamente ativo, essa confirmação frequentemente falha. O sistema então assume incapacidade e executa a ação fail-safe: chamada automática. Do ponto de vista de engenharia de segurança, isso é compreensível. Do ponto de vista de escala, é explosivo. Papel da Siri A Siri não “decide” o acidente, mas é um elo sensível na cadeia humano–máquina. Falhas de compreensão por ruído, idioma, respiração ofegante ou ausência de resposta acabam sendo interpretadas como sinal de emergência real. Isso é funcionalmente equivalente ao que vemos em sistemas automotivos como o eCall europeu, quando a confirmação humana é inexistente ou degradada. O dilema estrutural Há um trade-off claro e inevitável: Reduzir falsos negativos (não perder um acidente real) Aumentar falsos positivos (chamadas indevidas) Para o usuário individual, errar “para mais” faz sentido. Para serviços públicos de emergência, milhões de dispositivos errando “para mais” criam ruído operacional real. Por que isso importa para developers A Apple hoje opera, na prática, um dos maiores sistemas privados de segurança pessoal automatizada do mundo, interagindo diretamente com infraestrutura pública crítica. Isso coloca Crash Detection / SOS na mesma categoria de sistemas safety-critical, onde: UX é parte da segurança Algoritmos precisam ser auditáveis “Human-in-the-loop” não pode ser apenas nominal Reflexões abertas Alguns pontos que, como developer, acho que merecem discussão: Janelas de confirmação humana adaptativas ao contexto (atividade física, ruído). Cancelamento visual mais agressivo em cenários de alto movimento. Perfis de sensibilidade por tipo de atividade, claramente comunicados. Critérios adicionais antes da chamada automática quando o risco de falso positivo é estatisticamente alto. Não é um problema simples, nem exclusivo da Apple. É um problema de software crítico em contato direto com o mundo físico, operando em escala planetária. Justamente por isso, acho que vale uma discussão técnica aberta, sem ruído emocional. Curioso para ouvir perspectivas de quem trabalha com sistemas similares (automotivo, wearables, safety-critical, ML embarcado). — Rafa

I keep getting the following error when trying to run Passkey sign in on macOS. Told not to present authorization sheet: Error Domain=com.apple.AuthenticationServicesCore.AuthorizationError Code=1 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "(null)" This is the specific error. Application with identifier a is not associated with domain b I have config the apple-app-site-association link and use ?mode=developer Could there be any reason for this?

Hi, I'm using webauthn.io to test my macOS Passkey application. When registering a passkey whichever value I set for User Verification, that's what I get when I check registrationRequest.userVerificationPreference on prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest). However, when authenticating my passkey I can never get discouraged UV on prepareInterfaceToProvideCredential(for credentialRequest: any ASCredentialRequest). In the WWDC 2022 Meet Passkeys video, it is stated that Apple will always require UV when biometrics are available. I use a Macbook Pro with TouchID, but if I'm working with my lid closed, shouldn't I be able to get .discouraged?

Hello Developers, I have ran into a problem while sending mail to apple private relay email. We have built a mobile application where user can sign up through apple and they can sign up using hide-my-email feature. Which provides private relay address for us. Now we want to communicate with them using private relay mail address. The technology we are using to send emails are amazon SES, have done SPF, DMIK, DMARC and added domains in apple identity services for mail communication, passed an SPF check as well. But still mail is not getting delivered what am i doing wrong or apple doesn't support third party apps for sending emails to private relay? Is there any other way to achieve this please let me know Using the same body as attached in image is working fine for rest emails.

Hello, We received a rejection on one of our IOS applications because we were doing Microsoft MSAL login through the user's browser. The representative recommended that we use Webview to do in-app logins. However when we tried to handle the custom app uri redirection (looking like myapp://auth/), Webview does not seem to send the user back to the application. Does anyone have a fix for this? Thanks!

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?

I noticed, that even though my AutoFill Credential Provider Extension works with Safari for both Passwords and Passkeys, it doesn't work in context menus inside arbitrary textfields, meanwhile the same is true for the Apple Passwords app. This is a great hit to AutoFill productivity, as my extension is unable to fill textfields by just going to the context menu and clicking AutoFill > Passwords.. Is this a feature only available to Apple via private APIs, or is this something I can interface with? I checked and the Passwords app does use some undocumented but non-private entitlements: [Key] com.apple.authentication-services.access-credential-identities [Value] [Bool] true I also checked the responsible executable for some hints (AutoFillPanelService) however found nothing that would lead me to believe this is a public extension point. Another idea I had was trying to use a macOS Service for this, however Services in the "General" category won't show up in any context menu, only in the Application's Main Menu.

Hello Apple Developer Community and Support, Our team is encountering a critical and persistent issue with our backend integration of Sign In with Apple, and we are hoping for some insights or assistance. Problem: We consistently receive an "invalid_client" error (HTTP 400 status) when our backend service attempts to exchange the authorization code for tokens at Apple's https://appleid.apple.com/auth/token endpoint. The error message from Apple's response is simply {"error":"invalid_client"}. Our Setup: Client Application: An iOS native application. Backend Service: A Go backend responsible for server-to-server token exchange and user management. Sign In with Apple Flow: The iOS app initiates the Sign In with Apple flow, obtains an authorization code, and then passes this code to our backend for token exchange. Extensive Troubleshooting Performed (No Success): We have meticulously followed all official Apple documentation (including TN3107: Resolving Sign In with Apple Response Errors) and industry best practices. Here's a summary of our verification steps, all of which currently show correct configurations and parameters: Backend client_secret JWT Construction: We generate a client_secret JWT as required for server-to-server communication. We've confirmed the claims in the generated JWT are correct: iss (Issuer): Our Team ID (e.g., XXXXXXXXXX). sub (Subject): Our Service ID (e.g., com.example.service.backendauth). aud (Audience): https://appleid.apple.com. kid (Key ID): The Key ID associated with our .p8 private key (e.g., YYYYYYYYYY). We have performed rigorous verification of the .p8 private key content itself, ensuring no corruption, extra characters, or formatting issues in the environment variable. Our backend logs confirm it's parsing the correct PEM content. Token Exchange Request Parameters: The client_id parameter sent in the POST request to /auth/token is correctly set to our App Bundle ID (e.g., com.example.app.ios), as this is the identifier for which the code was originally issued. The redirect_uri parameter sent in the POST request to /auth/token is precisely matched to a registered "Return URL" in our Apple Developer Portal (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Apple Developer Portal Configuration (Meticulously Verified): App ID: Enabled for "Sign In with Apple". Service ID: Enabled for "Sign In with Apple". Its "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). Its "Return URLs" exactly match our backend's redirect_uri (e.g., https://api.example.com:port/api/auth/callback?provider=apple). Key: Our .p8 key has "Sign In with Apple" enabled. Crucially, in its configuration panel, the "Primary App ID" is correctly linked to our App Bundle ID (e.g., com.example.app.ios). We've ensured this key is specifically created for "Sign In with Apple" and not other services like APNs. We have performed multiple full revocations and meticulous re-creations of the App ID, Service ID, and Key in the Apple Developer Portal, ensuring correct linkages and using new identifiers to bypass any potential caching issues. Network & System Health Checks: Network connectivity from our backend server to https://appleid.apple.com (port 443) has been confirmed as fully functional via ping and curl -v. The incoming TLS handshake from our iOS client app to our backend server's callback URL (https://api.example.com:port/...) is successful and verified via openssl s_client -connect. There are no longer any TLS handshake errors (EOF). Our backend server's system clock is accurately synchronized via NTP. Request for Assistance: Given that all our visible configurations, environment variables, and request parameters appear to be correct and align with Apple's documentation, and network connectivity is confirmed, we are at a loss for why the invalid_client error persists. Based on TN3107, this error typically implies an issue with the client secret's signature or its validity for the given client_id. However, our logs confirm correct iss, sub, aud, and kid, and the private key content. Has anyone encountered this persistent invalid_client error when all checks pass? Are there any less common configurations or troubleshooting steps we might be missing? Could this indicate a caching or propagation delay on Apple's servers, even after waiting periods? Any insights or guidance would be greatly appreciated. We are prepared to provide detailed, anonymized logs and screenshots to Apple Developer Support privately if requested. Thank you.

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.

Hello everyone, We are currently preparing for an App Transfer to a new Apple Developer account due to a corporate merger. We are trying to figure out the best way to handle Apple Sign-In user migration and would love to get some advice on our proposed fallback plan. 📌 Current Situation We need to transfer our app's ownership to a new corporate entity. The app heavily relies on Apple Sign-In. The Issue: We did not collect the transfer_sub values during our initial development phase. Although we started collecting them recently, we will not have them for all existing users by the time the transfer happens. 🚨 The Risk (The 60-Day Rule) Based on Apple's documentation, even if we provide the transfer_sub, users must log into the app within 60 days of the transfer to successfully migrate their accounts. This means that users who log in after 60 days, or those whose transfer_sub is missing, will fail the Apple migration process. They will be treated as "new users" and will lose access to their existing account data. 💡 Our Proposed Custom Recovery Flow Since we cannot rely entirely on Apple's automated migration, we are planning to build a custom internal account recovery process to prevent user drop-off: A user (who failed the migration or logged in after 60 days) attempts to use Apple Sign-In on the transferred app. Since the existing account isn't linked, Apple generates a new identifier (sub), and the user enters the new sign-up flow. During the sign-up process, we enforce a mandatory identity verification step (e.g., SMS phone number verification). We query our existing user database using this verified information. If a matching existing user is found: We interrupt the sign-up process and display a prompt: "An existing account was found. We will link your account." We then update our database by mapping the new Apple sub value to their existing account record, allowing them to log in seamlessly. ❓ My Questions App Review Risk: Could this manual mapping approach—overwriting the Apple sub on an existing account based on internal identity verification—violate any Apple guidelines or result in an App Store rejection? Shared Experiences: Has anyone dealt with missing transfer_sub values or the 60-day migration limit during an App Transfer? How did you mitigate user loss? Best Practices: Are there any alternative, safer, or more recommended workarounds for this scenario?

I would like to make an app that uses Sign in with Apple to provide the users with a very convenient way of authenticating their (anonymous) identity. I'm using the identityToken that the SignInWithAppleButton provides to the onCompletion closure to build an AWS Identity Resolver that will be used to access AWS resources for that user. At the moment, everything works fine, except that the identityToken eventually stops working (I think after 24 hours) and is no longer usable for AWS identity resolvers. Is there a way to refresh the identityToken, or to generate a new one, without user interaction? I don't mind at all, if in some situations (eg logout from another device, deletion of account, etc), it cannot refresh the token, and it directs me to take further action by giving an error. Most importantly, I don't want the user to be forced to deal with the SignInWithAppleButton every time that they interact with web services. From the user's point of view, I would like the experience to be that they simply confirm that they agree to use SignInWithApple on first use (maybe once per device), and are never inconvenienced by it again. P.S. Sorry for posting this here. I tried to set the topic to "Privacy & Security" and ran into form validation errors.

Hi, I'm looking at adding App Attest to an app, and I think I understand the mechanics of the attestation process, but I'm having trouble figuring out how development and testing are supposed to work. Two main questions: The "App Attest Environment" -- the documentation says that attestation requests made in the .development sandbox environment don't affect the app's risk metrics, but I'm not sure how to actually use this sandbox. My understanding is that one of the things App Attest does is to ensure that your app has been appropriately signed by the App Store, so it knows that it hasn't been tampered with. But the docs say that App Store builds (and Test Flight and Developer Enterprise Program) always use the .production environment. Does App Attest actually work for local developer-build apps if you have this entitlement set? Presumably only on hardware devices since it requires the Secure Enclave? Does our headend have to do something different when verifying the public key and subsequent attested requests for an app that's using the .development sandbox? The docs do mention that a headend server should potentially track two keys per device/user pair so that it can have a production and development key. How does the headend know if a key is from the sandbox environment? Thanks!

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.

Hello, I have a question regarding the lifecycle of user consent and tokens in "Sign in with Apple." Specifically, I would like to understand the behavior of the auth/revoke API in relation to App Store Connect status changes. Impact of App Status Changes If an app is "Removed from Sale" or "Deleted" from App Store Connect, does Apple automatically revoke all associated user tokens and consent? Or is it still the developer's responsibility to programmatically revoke each user's token via the REST API to ensure the app is removed from the user’s "Apps Using Apple ID" list? API Availability after Removal Once an app is no longer available on the App Store (or its record is deleted in App Store Connect), is the auth/revoke REST API still accessible? I want to ensure that a developer can still perform necessary privacy clean-up tasks (revoking consent) even if the app is not currently distributed. Specific User Impacts of Non-Revocation If we do not call the revocation API, besides the app remaining in the "Sign in with Apple" list, what are the specific consequences for the user? Thank you for your guidance.

Our product includes a background sync process that synchronizes credentials between devices. We need to update ASCredentialIdentityStore when credentials are changed, we have noticed that the ASCredentialIdentityStore.shared.saveCredentialIdentities() fails to run when the device is locked. Is it possible to update ASCredentialIdentityStore when the device is locked?