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.

Question detail 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.xxxx", # New Primary 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!

Is there any particular reason why ASWebAuthenticationSession doesn't have support for async/await? (example below) do { let callbackURL = try await webAuthSession.start() } catch { // handle error } I'm curious if this style of integration doesn't exist for architectural reasons? Or is the legacy completion handler style preserved in order to prevent existing integrations from breaking?

Is there a step by step program on Sending Push notifications? I seem to be stuck at load private key. I get this error. SecKeyCreateWithData failed with error: Error Domain=NSOSStatusErrorDomain Code=-50 "EC private key creation from data failed" It is a new p8 file. I tried different format. I read some articles that say that there is a bug I think. I don't know for sure because it was written in jibberish. 90% of the code is dealing with these stupid keys. This should be 1 function setting the pipe and then I can use the pipe. This is ridiculous. If anybody has any ideas. The code is a mess because I tried so many different ideas. Push Notification.txt

Hi. We're writing Authorization Plugin and started with NullAuthPlugin compilation. When tried to run it on VM (Sonoma 14.6, SIP enabled), we're going into the following issue: `2025-03-08 13:38:20.699503-0800 0xdcb0 Error 0x0 0 0 kernel: (AppleMobileFileIntegrity) [com.apple.MobileFileIntegrity:library_validation_failure] Library Validation failed: Rejecting '/Library/Security/SecurityAgentPlugins/NullAuthPlugin.bundle/Contents/MacOS/NullAuthPlugin' (Team ID: ABCD12EF34, platform: no) for process 'SecurityAgentHel(2094)' (Team ID: N/A, platform: yes), reason: mapping process is a platform binary, but mapped file is not' As I understand, the platform binary is the one signed with Apple signature, which indeed is unavailable for us. How can we avoid this issue and run the plugin? Perhaps we're missing some build setting requirement?

I've made a simple command line app that requires Screen recording permission. When I ran it from Xcode, it prompts for a permission and once I allowed it from the settings, it runs well. #include &lt;stdio.h&gt; #include &lt;stdlib.h&gt; #include &lt;unistd.h&gt; #include &lt;CoreGraphics/CGDisplayStream.h&gt; int main() { printf("# Start #\n"); if (CGPreflightScreenCaptureAccess()) { printf("# Permitted.\n"); } else { printf("# Not permitted.\n"); if (CGRequestScreenCaptureAccess() == false) { printf("# CGRequestScreenCaptureAccess() returning false\n"); } } size_t output_width = 1280; size_t output_height = 720; dispatch_queue_t dq = dispatch_queue_create("com.domain.screengrabber", DISPATCH_QUEUE_SERIAL); CGError err; CGDisplayStreamRef sref = CGDisplayStreamCreateWithDispatchQueue( 1, output_width, output_height, 'BGRA', NULL, dq, ^( CGDisplayStreamFrameStatus status, uint64_t time, IOSurfaceRef frame, CGDisplayStreamUpdateRef ref ) { printf("Got frame: %llu, FrameStatus:%d \n", time, status); } ); err = CGDisplayStreamStart(sref); if (kCGErrorSuccess != err) { printf("Error: failed to start streaming the display. %d\n", err); exit(EXIT_FAILURE); } while (true) { usleep(1e5); } CGDisplayStreamStop(sref); printf("\n\n"); return 0; } Now I want to execute this from terminal, so I went to the build folder and typed the app name. cd /Users/klee/Library/Developer/Xcode/DerivedData/ScreenStreamTest-ezddqbkzhndhakadslymnvpowtig/Build/Products/Debug ./ScreenStreamTest But I am getting following output without any prompt for permission. # Start # # Not permitted. # CGRequestScreenCaptureAccess() returning false Error: failed to start streaming the display. 1001 Is there a something I need to consider for this type of command line app?

It seems it is not possible to give a CLI app (non .app bundle) full disk access in macOS 26.1. This seems like a bug and if not that is a breaking change. Anybody seeing the same problem? Our application needs full disk access for a service running as a LaunchDaemon. The binary is located in a /Library subfolder.

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

I've been spending days trying to solve the memory leak in a small menu bar application I've wrote (SC Menu). I've used Instruments which shows the leaks and memory graph which shows unreleased allocations. This occurs when someone views a certificate on the smartcard. Basically it opens a new window and displays the certificate, the same way Keychain Access displays a certificate. Whenever I create an SFCertificateView instance and set setDetailsDisclosed(true) - a memory leak happens. Instruments highlights that line. import Cocoa import SecurityInterface class ViewCertsViewController: NSViewController { var selectedCert: SecIdentity? = nil override func viewDidLoad() { super.viewDidLoad() self.view = NSView(frame: NSRect(x: 0, y: 0, width: 500, height: 500)) self.view.wantsLayer = true var secRef: SecCertificate? = nil guard let selectedCert else { return } let certRefErr = SecIdentityCopyCertificate(selectedCert, &secRef) if certRefErr != errSecSuccess { os_log("Error getting certificate from identity: %{public}@", log: OSLog.default, type: .error, String(describing: certRefErr)) return } let scrollView = NSScrollView() scrollView.translatesAutoresizingMaskIntoConstraints = false scrollView.borderType = .lineBorder scrollView.hasHorizontalScroller = true scrollView.hasVerticalScroller = true let certView = SFCertificateView() guard let secRef = secRef else { return } certView.setCertificate(secRef) certView.setDetailsDisclosed(true) certView.setDisplayTrust(true) certView.setEditableTrust(true) certView.setDisplayDetails(true) certView.setPolicies(SecPolicyCreateBasicX509()) certView.translatesAutoresizingMaskIntoConstraints = false scrollView.documentView = certView view.addSubview(scrollView) // Layout constraints NSLayoutConstraint.activate([ scrollView.leadingAnchor.constraint(equalTo: view.leadingAnchor), scrollView.trailingAnchor.constraint(equalTo: view.trailingAnchor), scrollView.topAnchor.constraint(equalTo: view.topAnchor), scrollView.bottomAnchor.constraint(equalTo: view.bottomAnchor), // Provide certificate view a width and height constraint certView.widthAnchor.constraint(equalTo: scrollView.widthAnchor), certView.heightAnchor.constraint(greaterThanOrEqualToConstant: 500) ]) } } https://github.com/boberito/sc_menu/blob/dev_2.0/smartcard_menu/ViewCertsViewController.swift Fairly simple.

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!

Hi,is there an option to mark the file or folder or item stored in user defaults ... not to be backed up when doing unencrypted backup in iTunes?We are developing iOS app that contains sensitive data. But even if we enable Data Protection for the iOS app it can be backed up on mac unencrypted using iTunes. Is there a way to allow backing up content only if the backup is encrypted?

Hi Apple, Currently we want to have enhancement for SMS OTP that we want to implement OTP Autofill, But after do some research we're stuck with option that the OTP only show in keyboard suggestion, is there any way for making OTP is automatically filled without user have to click the keyboard suggestion when receiving the SMS. Thanks Best Regards, Admiral Sultano Harly.

Hello I have a problem with provisionprofile file. I have created Identifier with Sign in with Apple capability turned on, created Profile with Developer ID selected and now I try to export archive with generated Developer ID provision file but it says "Profile doesn't support Sign in with Apple" Also interesting thing that default provisions like macOS App Development Mac App Store Connect don't show such error when I try to export archive Maybe this problem is only related to Developer ID provision and Direct Distribution doesn't support Sign in with Apple, but I havent found proves about this idea

Hello! I do know apple does not support electron, but I do not think this is an electron related issue, rather something I am doing wrong. I'd be curious to find out why the keychain login is happenning after my app has been signed with the bundleid, entitlements, and provision profile. Before using the provision profile I did not have this issue, but it is needed for assessments feature. I'm trying to ship an Electron / macOS desktop app that must run inside Automatic Assessment Configuration. The build signs and notarizes successfully, and assessment mode itself starts on Apple-arm64 machines, but every single launch shows the system dialog that asks to allow access to the "login" keychain. The dialog appears on totally fresh user accounts, so it's not tied to anything I store there. It has happened ever since I have added the provision profile to the electron builder to finally test assessment out. entitlements.inherit.plist keys &lt;key&gt;com.apple.security.cs.allow-jit&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.cs.allow-unsigned-executable-memory&lt;/key&gt; &lt;true/&gt; entitlements.plist keys: &lt;key&gt;com.apple.security.cs.allow-jit&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.security.cs.allow-unsigned-executable-memory&lt;/key&gt; &lt;true/&gt; &lt;key&gt;com.apple.developer.automatic-assessment-configuration&lt;/key&gt; &lt;true/&gt; I'm honestly not sure whether the keychain is expected, but I have tried a lot of entitlement combinations to get rid of It. Electron builder is doing the signing, and we manually use the notary tool to notarize but probably irrelevant. mac: { notarize: false, target: 'dir', entitlements: 'buildResources/entitlements.mac.plist', provisioningProfile: 'buildResources/xyu.provisionprofile', entitlementsInherit: 'buildResources/entitlements.mac.inherit.plist', Any lead is welcome!

We have an app that has failed during the app review for the Japanese market but has been accepted in several other markets successfully. We need the user's name in native Katakana format as we need it to be displayed in our restaurant Point of Sale systems for workers to be able to read and understand. We use 'Sign up with Apple', but when doing so, if this returns an anglicised given and family name, we have to request the customer supply their Katakana format name so that our in-store systems and staff can process and fulfil their orders. When the App Review process automatically tests the app, it uses "Apple John" as a customer's name. Since this is not a Japanese name, we ask for it again in the correct format, or we cannot allow the user to register. This contravenes Apple's rules, and thus, our app is rejected. If the Apple identity used belonged to a user more typical of the target market, it would work as required. Does anyone else have this issue, and how did you work around it? Tim

I have Authorisation Plugin which talks using XPC to my Launch Daemon to perform privileged actions. I want to protect my XPC service narrowing it to be called from known trusted clients. Now since I want authorisation plugin code which is from apple to call my service, I cannot use my own team id or app group here. I am currently banking on following properties of client connection. Apple Team ID : EQHXZ8M8AV Bundle ID starting with com.apple. Client signature verified By Apple. This is what I have come up with. func isClientTrusted(connection: NSXPCConnection) -> Bool { let clientPID = connection.processIdentifier logInfo("🔍 Checking XPC Client - PID: \(clientPID)") var secCode: SecCode? var secStaticCode: SecStaticCode? let attributes = [kSecGuestAttributePid: clientPID] as NSDictionary let status = SecCodeCopyGuestWithAttributes(nil, attributes, [], &secCode) guard status == errSecSuccess, let code = secCode else { logInfo("Failed to get SecCode for PID \(clientPID)") return false } let staticStatus = SecCodeCopyStaticCode(code, [], &secStaticCode) guard staticStatus == errSecSuccess, let staticCode = secStaticCode else { logInfo("Failed to get SecStaticCode") return false } var signingInfo: CFDictionary? let signingStatus = SecCodeCopySigningInformation(staticCode, SecCSFlags(rawValue: kSecCSSigningInformation), &signingInfo) guard signingStatus == errSecSuccess, let info = signingInfo as? [String: Any] else { logInfo("Failed to retrieve signing info") return false } // Extract and Verify Team ID if let teamID = info["teamid"] as? String { logInfo("XPC Client Team ID: \(teamID)") if teamID != "EQHXZ8M8AV" { // Apple's official Team ID logInfo("Client is NOT signed by Apple") return false } } else { logInfo("Failed to retrieve Team ID") return false } // Verify Bundle ID Starts with "com.apple." if let bundleID = info["identifier"] as? String { logInfo("XPC Client Bundle ID: \(bundleID)") if !bundleID.hasPrefix("com.apple.") { logInfo("Client is NOT an Apple system process") return false } } else { logInfo("Failed to retrieve Bundle Identifier") return false } // Verify Apple Code Signature Trust var trustRequirement: SecRequirement? let trustStatus = SecRequirementCreateWithString("anchor apple" as CFString, [], &trustRequirement) guard trustStatus == errSecSuccess, let trust = trustRequirement else { logInfo("Failed to create trust requirement") return false } let verifyStatus = SecStaticCodeCheckValidity(staticCode, [], trust) if verifyStatus != errSecSuccess { logInfo("Client's signature is NOT trusted by Apple") return false } logInfo("Client is fully verified as Apple-trusted") return true } Q: Just wanted community feedback, is this correct approach?

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,

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.

I am developing a background program that is included in the app as an extension. I would like to include logic to check the teamID and code signature validity of the program I created to ensure that it has not been tampered with. Is this possible?

With Let's Encrypt having completely dropped support for OCSP recently [1], I wanted to ask if macOS has a means of keeping up to date with their CRLs and if so, roughly how often this occurs? I first observed an issue where a revoked-certificate test site, "revoked.badssl.com" (cert signed by Let's Encrypt), was not getting blocked on any browser, when a revocation policy was set up using the SecPolicyCreateRevocation API, in tandem with the kSecRevocationUseAnyAvailableMethod and kSecRevocationPreferCRL flags. After further investigation, I noticed that even on a fresh install of macOS, Safari does not block this test website, while Chrome and Firefox (usually) do, due to its revoked certificate. Chrome and Firefox both have their own means of dealing with CRLs, while I assume Safari uses the system Keychain and APIs. I checked cert info for the site here [2]. It was issued on 2025-07-01 20:00 and revoked an hour later. [1] https://letsencrypt.org/2024/12/05/ending-ocsp/ [2] https://www.ssllabs.com/ssltest/analyze.html?d=revoked.badssl.com