Trying to apply 'always trust' to certificate added to keychain using both SecItemAdd() and SecPKCS12Import() with SecTrustSettingsSetTrustSettings(). I created a launchdaemon for this purpose. AuthorizationDB is modified so that any process running in root can apply trust to certificate. let option = SecTrustSettingsResult.trustRoot.rawValue // SecTrustSettingsResult.trustAsRoot.rawValue for non-root certificates let status = SecTrustSettingsSetTrustSettings(secCertificate, SecTrustSettingsDomain.admin, [kSecTrustSettingsResult: NSNumber(value: option.rawValue)] as CFTypeRef). Above code is used to trust certificates and it was working on os upto 14.7.4. In 14.7.5 SecTrustSettingsSetTrustSettings() returns errAuthorizationInteractionNotAllowed. In 15.5 modifying authorization db with AuthorizationRightSet() itself is returning errAuthorizationDenied.Tried manually editing authorization db via terminal and same error occurred. Did apple update anything on Security framework? Any other way to trust certificates?

In the hopes of saving others time, the updated demo project (i.e. the new Shiny) can be found from the video 'Resources' section under 'Performing fast account creation with passkeys'. The beta documentation can also be found from there. All of the new functionality is available only on *OS 26 at this time.

Hi everyone, I'm developing a C++ plugin (.bundle) for a third-party host application (Autodesk Maya) on macOS, and I'm finalizing the design for our licensing system. The plugin is distributed outside the Mac App Store. My goal is to securely store a license key in the user's Keychain. After some research, my proposed implementation is as follows: On activation, store the license data in the user's login keychain as a Generic Password (kSecClassGenericPassword) using the SecItem APIs. To ensure the plugin can access the item when loaded by Maya, I will use a specific Keychain Access Group (e.g., MY_TEAM_ID.com.mywebsite). The final .bundle will be code-signed with our company's Developer ID certificate. The signature will include an entitlements file (.entitlements) that specifies the matching keychain-access-groups permission. My understanding is that this combination of a unique Keychain Access Group and a properly signed/entitled bundle is the key to getting reliable Keychain access. This should also correctly trigger the one-time user permission prompt on first use. Does this sound like the correct and most robust approach for this scenario? Are there any common pitfalls with a plugin's Keychain access from within a host app that I should be aware of? Thanks for any feedback!

I’m implementing passkey registration and authentication in an iOS 17 app with a credential provider extension, but I’m running into an issue. Setup: I have a credential provider target configured. The app correctly shows the pop-up to register the passkey with my app. My Info.plist is set up properly. Issue: When the following function is triggered: override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { "code to generate registrationRequest..." let controller = ASAuthorizationController(authorizationRequests: [registrationRequest]) controller.delegate = self controller.presentationContextProvider = self controller.performRequests() } I get the following error: Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 I do not own the relying party domain (e.g., https://webauthn.io), so I cannot configure an apple-app-site-association file on the website. Question: How can I register and authenticate passkeys on any site that allows passkeys (such as webauthn.io) when I don’t control the webpage? Are there any workarounds or best practices for handling this in iOS 17? Any insights would be greatly appreciated!

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 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://developer.apple.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!

My high-level goal is to add support for Game Mode in a Java game, which launches via a macOS "launcher" app that runs the actual java game as a separate process (e.g. using the java command line tool). I asked this over in the Graphics & Games section and was told this, which is why I'm reposting this here. I'm uncertain how to speak to CLI tools and Java games launched from a macOS app. These sound like security and sandboxing questions which we recommend you ask about in those sections of the forums. The system seems to decide whether to enable Game Mode based on values in the Info.plist (e.g. for LSApplicationCategoryType and GCSupportsGameMode). However, the child process can't seem to see these values. Is there a way to change that? (The rest of this post is copied from my other forums post to provide additional context.) Imagine a native macOS app that acts as a "launcher" for a Java game.** For example, the "launcher" app might use the Swift Process API or a similar method to run the java command line tool (lets assume the user has installed Java themselves) to run the game. I have seen How to Enable Game Mode. If the native launcher app's Info.plist has the following keys set: LSApplicationCategoryType set to public.app-category.games LSSupportsGameMode set to true (for macOS 26+) GCSupportsGameMode set to true The launcher itself can cause Game Mode to activate if the launcher is fullscreened. However, if the launcher opens a Java process that opens a window, then the Java window is fullscreened, Game Mode doesn't seem to activate. In this case activating Game Mode for the launcher itself is unnecessary, but you'd expect Game Mode to activate when the actual game in the Java window is fullscreened. Is there a way to get Game Mode to activate in the latter case? ** The concrete case I'm thinking of is a third-party Minecraft Java Edition launcher, but the issue can also be demonstrated in a sample project (FB13786152). It seems like the official Minecraft launcher is able to do this, though it's not clear how. (Is its bundle identifier hardcoded in the OS to allow for this? Changing a sample app's bundle identifier to be the same as the official Minecraft launcher gets the behavior I want, but obviously this is not a practical solution.)

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!

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)

Hi Apple Team and Community, We've encountered a sudden and widespread failure with the App Attest service starting today across multiple production apps and regions. The previously working implementation is now consistently returning the following error on iOS: The operation couldn’t be completed. (com.apple.devicecheck.error error 4.) (serverUnavailable) Despite the green status on Apple’s System Status page, this appears to be a backend issue—possibly infrastructure or DNS-related. Notably: The issue affects multiple apps. It is reproducible across different geographies. No code changes were made recently to the attestation logic. We previously reported a similar concern in this thread: App Attest Attestation Failing, but this new occurrence seems unrelated to any client-side cause. Update: An Apple engineer in this thread(https://developer.apple.com/forums/thread/782987) confirmed that the issue was due to a temporary DNS problem and has now been resolved. Can anyone else confirm seeing this today? Any insights from Apple would be appreciated to ensure continued stability. Thanks!

In my app, I use SecItem to store some data in the Keychain. I’d like to know — when a user sets up a new iPhone and transfers data from the old device, will those Keychain items be migrated or synced to the new device?

Hello, I want to access the Docker socket API from inside the macOS App Sandbox. The method queries the API using curl with --unix-socket. However, the Sandbox blocks the request, as shown by the log: curl(22299) deny(1) network-outbound /Users/user/.docker/run/docker.sock Outgoing network traffic is generally allowed, but access to the Docker Unix socket is denied. Here’s the code I’m using: private func executeDockerAPI() -> String { let process = Process() let pipe = Pipe() process.executableURL = URL(fileURLWithPath: "/usr/bin/curl") process.arguments = [ "--unix-socket", "/Users/user/.docker/run/docker.sock", "http://127.0.0.1/containers/json" ] process.standardOutput = pipe process.standardError = pipe do { try process.run() process.waitUntilExit() let data = pipe.fileHandleForReading.readDataToEndOfFile() if let output = String(data: data, encoding: .utf8) { return output } else { return "Error while decoding" } } catch { return "Error running command: \(error.localizedDescription)" } } Is there any entitlement or sandbox configuration I’m missing to allow access to /Users/user/.docker/run/docker.sock from inside the sandbox?

Issue Summary I'm encountering a DCError.invalidInput error when calling DCAppAttestService.shared.generateAssertion() in my App Attest implementation. This issue affects only a small subset of users - the majority of users can successfully complete both attestation and assertion flows without any issues. According to Apple Engineer feedback, there might be a small implementation issue in my code. Key Observations Success Rate: ~95% of users complete the flow successfully Failure Pattern: The remaining ~5% consistently fail at assertion generation Key Length: Logs show key length of 44 characters for both successful and failing cases Consistency: Users who experience the error tend to experience it consistently Platform: Issue observed across different iOS versions and device types Environment iOS App Attest implementation Using DCAppAttestService for both attestation and assertion Custom relying party server communication Issue affects ~5% of users consistently Key Implementation Details 1. Attestation Flow (Working) The attestation process works correctly: // Generate key and attest (successful for all users) self.attestService.generateKey { keyId, keyIdError in guard keyIdError == nil, let keyId = keyId else { return completionHandler(.failure(.dcError(keyIdError as! DCError))) } // Note: keyId length is consistently 44 characters for both successful and failing users // Attest key with Apple servers self.attestKey(keyId, clientData: clientData) { result in // ... verification with RP server // Key is successfully stored for ALL users (including those who later fail at assertion) } } 2. Assertion Flow (Failing for ~5% of Users with invalidInput) The assertion generation fails for a consistent subset of users: // Get assertion data from RP server self.assertRelyingParty.getAssertionData(kid, with: data) { result in switch result { case .success(let receivedData): let session = receivedData.session let clientData = receivedData.clientData let hash = clientData.toSHA256() // SHA256 hash of client data // THIS CALL FAILS WITH invalidInput for ~5% of users // Same keyId (44 chars) that worked for attestation self.attestService.generateAssertion(kid, clientDataHash: hash) { assertion, err in guard err == nil, let assertion = assertion else { // Error: DCError.invalidInput if let err = err as? DCError, err.code == .invalidKey { return reattestAndAssert(.invalidKey, completionHandler) } else { return completionHandler(.failure(.dcError(err as! DCError))) } } // ... verification logic } } } 3. Client Data Structure Client data JSON structure (identical for successful and failing users): // For attestation (works for all users) let clientData = ["challenge": receivedData.challenge] // For assertion (fails for ~5% of users with same structure) var clientData = ["challenge": receivedData.challenge] if let data = data { // Additional data for assertion clientData["account"] = data["account"] clientData["amount"] = data["amount"] } 4. SHA256 Hash Implementation extension Data { public func toSHA256() -> Data { return Data(SHA256.hash(data: self)) } } 5. Key Storage Implementation Using UserDefaults for key storage (works consistently for all users): private let keyStorageTag = "app-attest-keyid" func setKey(_ keyId: String) -> Result<(), KeyStorageError> { UserDefaults.standard.set(keyId, forKey: keyStorageTag) return .success(()) } func getKey() -> Result<String?, KeyStorageError> { let keyId = UserDefaults.standard.string(forKey: keyStorageTag) return .success(keyId) } Questions User-Specific Factors: Since this affects only ~5% of users consistently, could there be device-specific, iOS version-specific, or account-specific factors that cause invalidInput? Key State Validation: Is there any way to validate the state of an attested key before calling generateAssertion()? The key length (44 chars) appears normal for both successful and failing cases. Keychain vs UserDefaults: Could the issue be related to using UserDefaults instead of Keychain for key storage? Though this works for 95% of users. Race Conditions: Could there be subtle race conditions or timing issues that only affect certain users/devices? Error Recovery: Is there a recommended way to handle this error? Should we attempt re-attestation for these users? Additional Context & Debugging Attempts Consistent Failure: Users who experience this error typically experience it on every attempt Key Validation: Both successful and failing users have identical key formats (44 character strings) Device Diversity: Issue observed across different device models and iOS versions Server Logs: Our server successfully provides challenges and processes attestation for all users Re-attestation: Forcing re-attestation sometimes resolves the issue temporarily, but it often recurs The fact that 95% of users succeed with identical code suggests there might be some environmental or device-specific factor that we're not accounting for. Any insights into what could cause invalidInput for a subset of users would be invaluable.

we can get token but when send to verity from apple. it reture Error : {"responseCode":"400","responseMessage":"Missing or incorrectly formatted device token payload"}

Can someone please guide me on the entire process of integrating ads in an IOS application using google's admob sdk? Not related to code but things related to Apple's privacy policy. Which options do need to select or specify in my app profile's privacy policy (identifier) section?

Before device Reboot: Here no issue from keychain. 2025-06-17 11:18:17.956334 +0530 WAVE PTX [DB_ENCRYPTION] Key successfully retrieved from the Keychain default When device is in reboot and locked (Keychain access is set to FirstUnlock) App got woken up in background SEEMS(NOT SURE) DEVICE STILL IN LOCKED STARE IF YES THEN WHICH IS EXPECTED 2025-06-17 12:12:30.036184 +0530 WAVE PTX <ALA_ERROR>: [OS-CCF] [DB_ENCRYPTION] Error while retriving Private key -25308 default 2025-06-17 12:15:28.914700 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default —————————————————— And as per logs, here user has launch the application post unlock and application never got the keychain access here also. HERE STILL HAS ISSUE WITH KEYCHAIN ACCESS. 2025-06-17 12:52:55.640976 +0530 WAVE PTX DEBUG : willFinishLaunchingWithOptions default 2025-06-17 12:52:55.651371 +0530 WAVE PTX <ALA_ERROR> [DB_ENCRYPTION] Error retrieving key from the Keychain: -25300 default

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 Apple Developer Support, We are implementing Sign in with Apple for our web application hosted on example.com. In the Service ID settings, we have configured the following: Service ID (client_id): com.example.service.local Web Domain: example.com Return URL: https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple We also tested login via the following URL from our web application: https://appleid.apple.com/auth/authorize?response_mode=form_post&response_type=code&client_id=com.example.service.local&scope=name%20email&state=2f9gMY1rTe12-O7Wbnb7KWe504HQ0KWBSHTKHbg9ZEY=&redirect_uri=https://2db2-121-160-153-88.ngrok-free.app/login/oauth2/code/apple However, we’re receiving an invalid_client error after submission. Our questions: Is it valid to use an ngrok URL like https://2db2-121-160-153-88.ngrok-free.app/... as the Return URL for development and testing? Does the Web Domain need to match the ngrok domain, or is it enough to register the production domain (e.g., example.com)? Is there any propagation delay or approval process after updating the Return URL in the Service ID? Is the client_id strictly required to match the Service ID exactly? We would greatly appreciate any insights or best practices to help us resolve this issue. Thank you in advance!

When use apple login, It always failed, other app developer by me is success, but the new app failed, the code is the same, it tips Sign up not Completed

Dear Apple Developer Technical Support, We are currently following the official Apple documentation “TN3159: Migrating Sign in with Apple users for an app transfer” to carry out a Sign in with Apple user migration after successfully transferring several apps to a new developer account. Here is a summary of our situation: Under the original Apple developer account, we had five apps using Sign in with Apple, grouped under a shared primary app using App Grouping. Recently, we transferred three of these apps to our new Apple developer account via App Store Connect. After the transfer, these three apps are no longer associated with the original primary App ID. We reconfigured individual Services IDs for each app in the new account and enabled Sign in with Apple for each. More than 24 hours have passed since the app transfer was completed. Now we are attempting to follow the migration process to restore user access via the user.migration flow. Specifically, we are using the following script to request an Apple access token: url = "https://appleid.apple.com/auth/token" headers = {"Content-Type": "application/x-www-form-urlencoded"} data = { "grant_type": "client_credentials", "scope": "user.migration", "client_id": "com.game.friends.ios.toptop.sea", # New Services ID in the new account "client_secret": "<JWT signed with new p8 key>" } response = requests.post(url, headers=headers, data=data) However, the API response consistently returns: { "error": "invalid_client" } We have verified that the following configurations are correct: The client_secret is generated using the p8 key from the new account, signed with ES256 and correct key_id, team_id, and client_id. The client_id corresponds to the Services ID created in the new account and properly associated with the migrated app. The scope is set to user.migration. The JWT payload contains correct iss, sub, and aud values as per Apple documentation. The app has been fully transferred and reconfigured more than 24 hours ago. Problem Summary & Request for Support: According to Apple’s official documentation: “After an app is transferred, Apple updates the Sign in with Apple configuration in the background. This can take up to 24 hours. During this time, attempts to authenticate users or validate tokens may fail.” However, we are still consistently receiving invalid_client errors after the 24-hour waiting period. We suspect one of the following issues: The transferred apps may still be partially associated with the original App Grouping or primary App ID. Some Sign in with Apple configuration in Apple’s backend may not have been fully updated after the transfer. Or the Services ID is not yet fully operational for the transferred apps in the new account. We kindly request your assistance to: Verify whether the transferred apps have been completely detached from the original App Grouping and primary App ID. Confirm whether the new Services IDs under the new account are fully functional and eligible for Sign in with Apple with user.migration scope. Help identify any remaining configuration or migration issues that may cause the invalid_client error. If necessary, assist in manually ungrouping or clearing any residual App Grouping relationships affecting the new environment. We have also generated and retained the original transfer_sub identifiers and are fully prepared to complete the sub mapping once the user.migration flow becomes functional. Thank you very much for your time and support!