On Wednesday, June 18, 2025, Sign in with Apple was impacted by a configuration issue which affected some developer accounts that created new app or Services ID configurations, or edited existing configurations, resulting in the following errors: invalid_client response error returned by the authentication, token validation/revocation, and user migration requests "Sign Up Not Completed" (or equivalent) error presented from the Authentication Services framework. On Monday, June 23, 2025, this issue was resolved. Please retry the Sign in with Apple flows in your Sign in with Apple enabled apps and websites to confirm your developer account configuration has been fixed. Please let us know if you can still reproduce this issue with your developer account. If so, follow the steps outlined in the post below: Gathering required information for troubleshooting Sign in with Apple authorization and token requests https://developer.apple.com/forums/thread/762831 Finally, reply (not comment) with your Feedback ID on either of the posts below: https://developer.apple.com/forums/thread/789011 https://developer.apple.com/forums/thread/789132 Cheers, Paris X Pinkney |  WWDR | DTS Engineer

As I had mentioned earlier, I was facing two issues after the initial update, but I’m happy to inform you that both of those issues have now been resolved. However, after updating to iOS 26.0 (23A5297m), I’ve started experiencing a new issue related to overheating. Since yesterday, my iPhone has been getting extremely hot while charging. It also became very hot after clicking just a few photos. The same heating issue occurred again today during charging. This problem only started after the latest update. Kindly look into this issue and advise on how to resolve it.

Hi everyone, I'm developing an iOS app using the AppsFlyer SDK. I understand that starting with iOS 14.5, if a user denies the App Tracking Transparency (ATT) permission, we are not allowed to access the IDFA or perform cross-app tracking. However, I’d like to clarify which in-app events are still legally and technically safe to send when the user denies ATT permission. Specifically, I want to know: Is it acceptable to send events like onboarding_completed, paywall_viewed, subscription_started, subscribe, subscribe_price, or app_opened if they are not linked to IDFA or any form of user tracking? Would sending such internal behavioral events (used purely for SKAdNetwork performance tracking or in-app analytics) violate Apple’s privacy policy if no device identifiers are attached? Additionally, if these events are sent in fully anonymous form (i.e., not associated with IDFA, user ID, email, or any identifiable metadata), does Apple still consider this a privacy concern? In other words, can onboarding_completed, paywall_viewed, subsribe, subscribe_price, etc., be sent in anonymous format without violating ATT policies? Are there any official Apple guidelines or best practices that outline what types of events are considered compliant in the absence of ATT consent? My goal is to remain 100% compliant with Apple’s policies while still analyzing meaningful user behavior to improve the in-app experience. Any clarification or pointers to documentation would be greatly appreciated. Thanks in advance!

Hi I'm developing an app that autofills Passkeys. The app allows the user to authenticate to their IdP to obtain an access token. Using the token the app fetches from <server>/attestation/options. The app will generate a Passkey credential using a home-grown module - the extension has no involvement, neither does ASAuthorizationSecurityKeyPublicKeyCredentialProvider. I can confirm the passkey does get created. Next the credential is posted to <server>/attestation/results with the response JSON being parsed and used to create a ASPasskeyCredentialIdentity - a sample of the response JSON is attached. Here is my save function: static func save(authenticator: AuthenticatorInfo) async throws { guard let credentialID = Data(base64URLEncoded: authenticator.attributes.credentialId) else { throw AuthenticatorError.invalidEncoding("Credential ID is not a valid Base64URL string.") } guard let userHandle = authenticator.userId.data(using: .utf8) else { throw AuthenticatorError.invalidEncoding("User handle is not a valid UTF-8 string.") } let identity = ASPasskeyCredentialIdentity( relyingPartyIdentifier: authenticator.attributes.rpId, userName: authenticator.userId, // This is what the user sees in the UI credentialID: credentialID, userHandle: userHandle, recordIdentifier: authenticator.id ) try await ASCredentialIdentityStore.shared.saveCredentialIdentities([identity]) } Although no error occurs, I don't get any identities returned when I call this method: let identities = await ASCredentialIdentityStore.shared.credentialIdentities( forService: nil, credentialIdentityTypes: [.passkey] ) Here is the Info.plist in the Extension: <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionAttributes</key> <dict> <key>ASCredentialProviderExtensionCapabilities</key> <dict> <key>ProvidesPasskeys</key> <true/> </dict> <key>ASCredentialProviderExtensionShowsConfigurationUI</key> <true/> </dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.authentication-services-credential-provider-ui</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).CredentialProviderViewController</string> </dict> </dict> </plist> The entitlements are valid and the app and extension both support the same group. I'm stumped as to why the identity is not getting saved. Any ideas and not getting retrieved. attestationResult.json

I’ve been running into an issue for over a day when trying to create a Sign in with Apple key. Each time I attempt to download it, I’m redirected to a page that displays an error and provides no further guidance. I’ve contacted Support and haven’t yet received a reply. I’ve also tried across multiple browsers (Chrome, Safari, Firefox), including incognito modes. Any ideas on how to resolve this? We’re currently stuck and would appreciate guidance.

Recently, we have adapted the passkey function on the Mac, but we always encounter the error message "Unable to verify the web credentials association of xxx with domain aaa. Please try again in a few seconds." We can confirm that https://aaa/.well-known/apple-app-site-association has been configured and is accessible over the public network. Additionally, the entitlements in the app have also been set with webcredentials:aaa. This feature has been experiencing inconsistent performance. When I restart my computer or reinstall the pkg, this feature may work or it may still not work. I believe this is a system issue. Here is feed back ID: FB20876945 In the feedback, I provided the relevant logs. If you have any suggestions or assistance, please contact me. I would be extremely grateful!

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?

Hi, We are operating a service that uses Sign in with Apple for user registration and login. As part of our security incident response and periodic security improvements, we are planning to rotate the private key used to generate the client secret (JWT) for Sign in with Apple. I have read the Human Interface Guidelines and the AuthenticationServices documentation, but I could not find a clear description of the behavior and user impact when rotating this private key. I would like to ask the following questions: Background: We issue a Sign in with Apple private key (with a Key ID) in our Apple Developer account. Our server uses this private key to generate the client secret (JWT). This is used for Sign in with Apple login on our web / mobile app. We are planning to invalidate the existing private key and switch to a newly issued one. Questions: Impact on existing logged-in sessions Will rotating the private key force already logged-in users (who previously signed in with Apple) to be logged out from our service? Can the user identifier (such as the "sub" claim) for existing Sign in with Apple users change due to key rotation? Recommended frequency and best practices Does Apple recommend rotating this private key only when it is compromised, or on a regular basis? If there are any official documents or examples that describe how to safely perform key rotation in production, we would appreciate a pointer. Impact on marketing / analytics We are using user IDs (linked via Sign in with Apple) for analytics and marketing attribution. Is there any expected impact on such use cases caused by rotating the private key? For example, is there any possibility that user identifiers change as a result of key rotation, or anything we should be careful about from a data linkage perspective? Our goal is to rotate the private key in a secure way without causing service downtime, mass logouts, or loss of account linkage. If there is already an official document that covers this, please let me know the URL. Thank you in advance.

I am working on a SDK which helps identify the device authenticity. I am in need of something which can confirm the firmware/Hardware/OS is signed by Apple and is authentic. There will be no tempering to device?

Our business model is to identify Frauds using our advanced AI/ML model. However, in order to do so we need to collect many device information which seems to be ok according to https://developer.apple.com/app-store/user-privacy-and-data-use/ But it's also prohibited to generate a fingerprint, so I need more clarification here. Does it mean I can only use the data to identify that a user if either fraud or not but I cannot generate a fingerprint to identify the device? If so, I can see many SKD in the market that generates Fingerprints like https://fingerprint.com/blog/local-device-fingerprint-ios/ and https://shield.com/?

Hello, We are working on integrating app integrity verification into our service application, following Apple's App Attest and DeviceCheck guide. Our server issues a challenge to the client, which then sends the challenge, attestation, and keyId in CBOR format to Apple's App Attest server for verification. However, we are unable to reach both https://attest.apple.com and https://attest.development.apple.com due to network issues. These attempts have been made from both our internal corporate network and mobile hotspot environments. Despite adjusting DNS settings and other configurations, the issue persists. Are there alternative methods or solutions to address this problem? Any recommended network configurations or guidelines to successfully connect to Apple's App Attest servers would be greatly appreciated. Thank you.

we develop extension "Autofill Credential Provider" function for passkey. 1.first step registe passkey 2.second step authenticate with passkey step 1 &amp; step 2 has finished and run success with provideCredentialWithoutUserInteraction. But we want to prepare our interface for use to input password and select passkey what the want. however the func prepareInterfaceToProvideCredential in ASCredentialProviderViewController does call? what i missed? how can i do it?

override func prepareInterface(forPasskeyRegistration registrationRequest: any ASCredentialRequest) int this function how can i get the "challenge" from user agent, the params "challenge" need to be used in webauthn navigator.credentials.create

I am developing a Flutter iOS application and encountering a crash when using biometric authentication (Face ID) via the local_auth plugin. ■ Environment Flutter: 3.x local_auth: 2.2.0 (also tested with 2.1.6) iOS: real device (Face ID is working normally for device unlock) Firebase Authentication (email/password) Xcode build ■ Issue When calling biometric authentication, the app crashes immediately. Code: final didAuthenticate = await auth.authenticate( localizedReason: 'Authenticate to login', options: const AuthenticationOptions( biometricOnly: false, useErrorDialogs: false, ), ); ■ Error Thread 1: signal SIGABRT Crash occurs in libsystem_kernel.dylib (__pthread_kill) Happens immediately when authenticate() is called No exception is caught in Dart (native crash) ■ Verified NSFaceIDUsageDescription is correctly included in Info.plist Confirmed it exists in the built Runner.app Info.plist localizedReason is non-empty and in English Flutter clean / pod install executed App reinstalled on device Face ID works normally outside the app ■ Question Under what conditions does LAContext.evaluatePolicy trigger SIGABRT instead of returning an error? Are there known issues with presenting biometric authentication UI in certain UI states (e.g., view controller hierarchy, scene lifecycle)? Could this be related to UIScene / rootViewController issues? What is the correct timing and context to call biometric authentication safely in iOS apps? I suspect this is related to native iOS behavior rather than Flutter logic. Any guidance would be appreciated.

Hi Community, We've implemented Sign In with Apple in our application. Our domains are properly registered in the developer console, but we're experiencing inconsistent email functionality with Apple's privacy email service. Some domains work correctly while others show delivery problems, even though all domains have identical configurations. Apple's console displays green verification status for all domains, yet testing reveals that emails to privacy-protected accounts don't arrive as expected. We're using SendGrid as our email service provider, and all domains have valid authentication records (SPF, DKIM, DMARC) in place. Has anyone encountered similar inconsistencies with Apple's privacy email service? Would appreciate any configuration tips or troubleshooting guidance. Thanks.

冷启动后我们读文件，发现："error_msg":"未能打开文件“FinishTasks.plist”，因为你没有查看它的权限。 是否有这些问题： 「iOS 26 iPhone 16,2 cold launch file access failure」） 核心内容：多名开发者反馈 iPhone 15 Pro（iOS 26.0/26.1）冷启动时读取 Documents 目录下的 plist 文件提示权限拒绝，切后台再切前台恢复，苹果员工回复「建议延迟文件操作至 applicationDidBecomeActive 后」。

On Tahoe and earlier, ScreenCapture permissions can disappear and not return. Customers are having an issue with this disappearing and when our code executes CGRequestScreenCaptureAccess() nothing happens, the prompt does not appear. I can reproduce this by using the "-" button and removing the entry in the settings, then adding it back with the "+" button. CGPreflightScreenCaptureAccess() always returns the correct value but once the entry has been removed, CGRequestScreenCaptureAccess() requires a reboot before it will work again.

Our proposed solution to identify an app user when opening a website operated by app developer is: Apps sends a request to backed with app users auth header Backend fetches a generated authenticated url from website backend, based on users auth header App opens it in browser The browser journey is self contained within domain of the business. Would this interaction require an ATT request given that the users identity cannot be tracked back to the app user ? Thanks

Dear Apple Developer Support Team, We are experiencing a recurring issue with the DeviceCheck API where the following error is being returned: com.apple.devicecheck.error 0 Upon analyzing our logs, we have noticed that this error occurs significantly more often when users are connected to Wi-Fi networks, compared to mobile networks. This leads us to suspect that there might be a relationship between Wi-Fi configuration and the DeviceCheck service’s ability to generate or validate tokens. We would like to know: Is this error code (0) known to be caused by specific types of network behavior or misconfigurations on Wi-Fi networks (e.g., DNS filtering, firewall restrictions, proxy servers)? Are there any recommended best practices for ensuring reliable DeviceCheck API communication over Wi-Fi networks? Additionally, could you please clarify what general conditions could trigger this com.apple.devicecheck.error 0? The lack of specific documentation makes debugging this issue difficult from our side. Any guidance or internal documentation on this error code and its potential causes would be greatly appreciated. IDE: Xcode 16.3 Looking forward to your support. Best regards,

I received a notification stating that we need to register a server-to-server notification endpoint to handle the following three events: Changes in email forwarding preferences. Account deletions in your app. Permanent Apple Account deletions. However, even though we have registered the API endpoint under our Identifier configuration, it appears that we are not receiving any API calls when these events trigger. I honestly have no idea what’s going wrong. I’ve checked our WAF logs and there’s no trace of any incoming traffic at all. Is it possible that Apple hasn't started sending these notifications yet, or is there something I might be missing? I’m stuck and don’t know how to resolve this. I would really appreciate any help or insights you could share. Thank you.