Since Sun 15th Jun 04:30 (UTC+7) we received lots of following error that causes our device test failure. Could Apple please investigate further? ############################# Operations could not be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable)

Hello, I’m planning to develop a custom referral-based attribution system for my app. The goal is to log the number of installs that come from unique referral links and then track subsequent in‑app analytics (for example, when a user reaches level 5 in a game). I’d also like to capture the user’s country to further segment these analytics. I want to build this system myself—without relying on third‑party services (such as AppsFlyer or Branch) since I only need a few key data points and want to keep costs low. However, I’m aware of the privacy restrictions in iOS and want to ensure that my implementation complies with Apple’s guidelines. Specifically, I would appreciate guidance on the following: Permissible Signals: Is it acceptable to log signals like IP address (or a suitably anonymized version), device model, and timestamp to help correlate the referral click to a successful install and subsequent in‑app events? Are there any other recommended non‑PII signals that can be used to confirm a referral install without risking rejection during App Review? Best Practices: What are the best practices for handling and transmitting these signals (e.g., should IP addresses be truncated or hashed)? How can I ensure that my system remains compliant with Apple’s App Tracking Transparency and other privacy guidelines? I’d appreciate any insights or references to relevant documentation that might help me build this system without getting rejected by Apple. Thank you in advance for your assistance!

Hello, We are experiencing an issue related to Sign in with Apple Server-to-Server (S2S) notifications, specifically involving repeated delivery of the account-deleted event, and would like to ask whether this behavior is expected or known. Background We have configured an S2S notification endpoint for Sign in with Apple in accordance with Apple’s requirements for account status change notifications. Our endpoint: Is reachable over HTTPS Consistently returns HTTP 200 OK Successfully receives other S2S events, including: email-enabled email-disabled consent-revoked Issue: Repeated 'account-deleted' events for the same Apple ID For most users, the account-deleted event is delivered only once, as expected. However, for a specific Apple ID used with Sign in with Apple, we are observing repeated deliveries of the same account-deleted event, arriving at regular intervals (approximately every 5 minutes). The payload contents are identical between deliveries and include the same user identifier (sub) and event timestamp. Notably: The Apple ID deletion itself completed successfully The payload does not change between deliveries Our endpoint continues to return HTTP 200 OK for every request Questions We would appreciate clarification on the following points: Is repeated delivery of the same account-deleted event expected behavior in any scenario? Is there a retry or redelivery mechanism for this event type, even when HTTP 200 is returned? Could repeated deliveries indicate that the deletion process is still considered “in progress” on Apple’s side? Are developers expected to treat account-deleted events as at-least-once delivery and handle them idempotently? Additional context While researching this issue, we found a forum thread describing a very similar case: https://developer.apple.com/forums/thread/735674 In that discussion, Apple staff advised submitting the issue via Feedback Assistant, which suggests that this behavior may already be understood internally. We have also submitted a Feedback Assistant report with detailed logs and timestamps. Any clarification on the expected behavior or recommended handling for this scenario would be greatly appreciated. Thank you for your time and support.

Hi, I'm trying to implement web-browser SignIn with Apple with my new app. I'm trying to "Associate your website to your app" like described in this doc: https://developer.apple.com/help/account/capabilities/configure-sign-in-with-apple-for-the-web So I created a Service ID for this specific login. I want this login page to display my app icon and name when presented to users. My issue: When I associate my new app the the service, the link is somehow not working. The login page show the "service" login (with a generic apple logo and the Service ID's name) instead of the actual App name. I'v been able to link my new service to older apps succesfully !!! (the login page correctly shows the old apps icons and names) Why is my new app not associated with the service ? I am missing something here ? is there an additionnal step that I need to take in order to link the service to my newest app ? Thanks !

Hello Team, We’ve recently started receiving reports from our customer base (Trellix) regarding issues with Full Disk Access (FDA) for Trellix binaries on macOS devices running Tahoe 26.1 (released on November 3, 2025). The issue occurs when users attempt to add Trellix CLI binaries under FDA to grant the required permissions; the binaries fail to appear under the FDA settings, even after selection. Upon further investigation, this appears to be a macOS 26.1–specific issue and not observed in earlier versions. Similar reports have been noted across various forums, indicating that the issue affects multiple binaries, not just Trellix: Some of the discussions on the same issue I see online. https://developer.apple.com/forums/thread/806187 https://developer.apple.com/forums/thread/806156 https://forum.logik.tv/t/macos-26-1-installation-issue-wait-before-updating/13761 https://www.reddit.com/r/MacOS/comments/1os1ph3/cant_add_anything_to_privacy_security_full_disk/ I have also logged FB21009024 for the same. We would like to understand when we can expect this to be fixed, since the issue persists even in 26.2 Beta and also whether the workaround of dragging and dropping the binaries can still be suggested?

We're integrating Sign in with Apple into our iOS app using both SwiftUI and UIKit. The Apple ID login UI appears correctly on real devices, but after tapping Continue, the system immediately stops and shows code 1001. This issue happens across multiple devices and Apple ID accounts, even with no prior login history. We’ve confirmed the following: Sign in with Apple is enabled in both Developer Portal and Xcode Capabilities Automatic signing and provisioning are set correctly Device is signed into iCloud and system time is synced Performed clean build, app reinstall, and other standard debugging steps We suspect that the sign-in process may not be completing properly due to some kind of account or server-side restriction, and we’d appreciate any insights into this behavior.

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.

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)

We are developing an app that uses Authentication Services to authenticate users. According to the documentation, this framework will open the default web browser if it supports auth session handling, and Safari otherwise. This is not entirely true, and users will be frustrated! macOS version: Sequoia 15.5; Safari version: 18.5. When: The default browser is not Safari, and supports auth session handling (Google Chrome and Microsoft Edge as examples); and - The Safari app is already running; The auth flow will: Present the confirmation dialog box with the default browser icon. Good! Open a Safari window, instead of the default browser's one. Bad! Respond with "User Cancelled" error to the app, after making the end user believe the auth was good. Very Bad!! If the app retries the auth session, the default browser window will open as expected, and it will work as expected. However, requiring users to authenticate twice is a very bad users experience... This issue does not reproduce, when either: Safari is not running at the moment of auth session start; The default browser does not support auth session handling; or - Safari is the default browser. Fellow developers, be warned! Apple engineers, feedback #18426939 is waiting for you. Cheers!

Hi! We're having issues with the sign in flow, starting today. As per the documentation, the issuer of the tokens should be https://appleid.apple.com sign in docs. But in the published configuration, it is now stated as https://account.apple.com metadata endpoint. Once the token is received through the sign in flow, the issuer is however still appleid.apple.com. This is causing problems for us where we expect the issuer in the metadata endpoint to be the same as the actual token issuer. What is correct here?

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.

I'm developing a Unity iOS app using the official "Sign In with Apple" Unity plugin (v1.5.0), and I'm encountering persistent errors during authentication. Here’s the full context: App Info: Unity version: 6000.0.32f1 Bundle ID: com.pfcgaming.applesignin Sign In with Apple enabled in the Apple Developer portal Real iOS device, not simulator Error Logs: txt Copy Edit Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.pfcgaming.applesignin} ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)" Description: The operation couldn’t be completed. No credentials available for login. What I’ve Done So Far: Verified "Sign In with Apple" is enabled under the App ID in developer.apple.com. Provisioning profile has been regenerated with correct entitlements. Xcode project has the “Sign In with Apple” capability added. Tested on multiple real iOS devices with iCloud + Keychain enabled. Tried both PerformQuickLogin() and LoginWithAppleId() approaches in the plugin. My Observations: These errors started occurring right after enabling "Sign In with Apple" in the developer portal. Based on some community feedback, there may be a backend propagation delay after enabling SIWA (Sign In With Apple) which might cause these errors. Questions: Is it expected to receive error -7003 or 1001 immediately after enabling SIWA in the Developer Portal? How long does it typically take for entitlement changes to fully propagate? Is there any Apple-recommended workaround to test during this wait time? Any insight or confirmation would be helpful. Thanks in advance!

Why can’t sandboxed mac app store apps have full disk access available in the system settings for full disk access? I discovered mac app store apps in release mode cannot access the ai auggie command line program and other command line programs like opengrep on your system. Debug builds fine. I came up with a workaround: Since I have an ssh client built in for connecting to remote servers, why not connect to ssh on the same local machine… Ask the user for their username and password in a popup. To do this, you have to enable remote login on your mac in system settings -> sharing. In addition you must grant full disk access to cli ssh in system settings: add /usr/libexec/sshd-keygen-wrapper It all works, but I don’t see the cli program in mac settings. To remove the cli program you must run a command line program to remove all full disk access support from all apps. No way to just undo ssh. So my question is, even though I got CodeFrog all working for a mac app store release, should I not do it because it’s insecure or too complicated with the system settings? Should I instead sell the app off the store like Panic Nova? Need some advice. I have not implemented in app purchases yet. Should I just have a reality check and sell the app off the store, or try for app store approval? Bummer… Maybe I’m ahead of my time, but perhaps Apple could review the source code for apps requesting full disk access and make sure there’s nothing fraudulent in them. Then, developer tools app store apps could be in the store with the user’s assurance that nothing is happening behind the scenes that is scary. From: https://blog.greenrobot.com/2025/11/10/i-have-a-decision-to-make/ Related post: https://developer.apple.com/forums/thread/806187 I submitted a code level tech support question for this. They directed me here.

Hello, I am at wits' end with the Apple Sign-in api. I have tested in stage and it works beautifully, but when i push to production it gives me the error "invalid_client". I'm confident the setup is correct, when I asked Apple for help over the phone, they sent me a few forums with no answers. Has anyone had the same issue? How did you resolve? Could it be because I have two app IDs and two service IDs? (prod + stage) Help!

If a user triggers account revoke on their Apple ID—but does not perform an in-app account deletion—will Apple send a server-to-server notification to inform us of this revoke event? Additionally, in this scenario, if the user later wants to restore access to their existing game account data (for example, by re-binding Sign in with Apple or switching to another login method), are developers expected to restore all previously linked game data, or should the revoke event be treated as a permanent loss of authorization?

Hi. I enter a password using the security command at the command line. It appears in the keychain access app, but not in the passwords app. I don't understand why. rickhedin@Ricks-MacBook-Pro zalando % security add-generic-password -U -s "birds" -a "cats" -w "dogs" rickhedin@Ricks-MacBook-Pro zalando % rickhedin@Ricks-MacBook-Pro zalando % security find-generic-password -s "birds" -wa "cats" dogs rickhedin@Ricks-MacBook-Pro zalando % I'm told the two apps are two views of the same data, so I guess some filter must be being applied?

Hello, Thanks for the new video on Memory Integrity Enforcement! Is the presented app's sample code available (so that we can play with it and find & fix the bug on our own, using Soft Mode)? Thanks in advance!

I'm looking to implement USB monitoring for FIDO2 authentication through a custom Authorization Plugin, specifically for the below ones. This plugin applies to the following macOS authorization mechanisms: system.login.console — login window authentication system.login.screensaver — screensaver unlock authentication The goal is to build a GUI AuthPlugin, an authorization plugin that presents a custom window prompting the user to "Insert your FIDO key”. Additionally, the plugin should detect when the FIDO2 device is removed and respond accordingly. Additional Info: We have already developed a custom authorization plugin which is a primary authentication using OTP at login and Lock Screen. We are now extending to include FIDO2 support as a primary. Our custom authorization plugin is designed to replace the default loginwindow:login mechanism with a custom implementation. Question: Is there a reliable approach to achieve the USB monitoring functionality through a custom authorization plugin? Any guidance or pointers on this would be greatly appreciated.

Hi everyone, I’m looking for clarification on best practices for storing API keys in an iOS app — for example, keys used with RevenueCat, PostHog, AWS Rekognition, barcode scanners, and similar third-party services. I understand that hard-coding API keys directly in the app’s source code is a bad idea, since they can be extracted from the binary. However, using a .plist file doesn’t seem secure either, as it’s still bundled with the app and can be inspected. I’m wondering: What are Apple’s recommended approaches for managing these kinds of keys? Does Xcode Cloud offer a built-in or best-practice method for securely injecting environment variables or secrets at build time? Would using an external service like AWS Secrets Manager or another server-side solution make sense for this use case? Any insights or examples of how others are handling this securely within Apple’s ecosystem would be greatly appreciated. Thanks for considering my questions! — Paul

Hello, I'm an application developer related to Apple system extensions. I developed an endpoint security system extension that can run normally before the 14.x system. However, after I upgraded to 15.x, I found that when I uninstalled and reinstalled my system extension, although the system extension was installed successfully, a system warning box would pop up when I clicked enable in the Settings, indicating a failure. I conducted the following test. I reinstalled a brand-new MAC 15.x system. When I installed my applications, the system extensions could be installed successfully and enabled normally. However, when I uninstalled and reinstalled, my system extension couldn't be enabled properly and a system warning popped up as well. I tried disabling SIP and enabling System Extension Developers, but it still didn't work. When the system warning box pops up, I can see some error log information through the console application, including an error related to Failed to authorize right 'com.apple.system-extensions.admin' by client '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] for authorization created by '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] (3,0) (-60005) (engine 179) as shown in the screenshot. The same problem, mentioned in Cannot approve some extensions in MacOS Sequoia , but there is no solution