General: Forums topic: Privacy & Security Privacy Resources Security Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

This is a recap of the Q&A from the Meet with Apple activity Fortify your app: Essential strategies to strengthen security. If you attended the event and asked questions, thank you for coming and participating! If you weren’t able to join us live we hope this recap is useful. Memory Integrity Enforcement (MTE) What is Memory Integrity Enforcement and which devices support it? Memory Integrity Enforcement is supported on A19, A19 Pro, M5, M5 Pro, and M5 Max chips, which power iPhone 17e, the new MacBook Air (M5), and the new MacBook Pro (M5 Pro or M5 Max). Starting in the 26.4 OS versions, applications that enable MTE (checked-allocations) as part of Enhanced Security will also run with MTE enabled in the simulator when running on macOS hardware that supports MTE. How can I use Memory Integrity Enforcement with third-party SDKs? Third-party SDKs linked into your app will generally use the system allocator automatically and benefit from Memory Integrity Enforcement automatically. If there are memory corruption bugs in those SDKs that Memory Integrity Enforcement features like MTE detect and turn into crashes, you'll want to work with the developers of those SDKs to have them fix the underlying bugs. You could use MTE soft mode to avoid having those memory corruptions crash your app while you wait for fixes from the developers, at the cost of the relative reduction in security that entails. Why does my app crash on launch with MTE enabled, with tags showing as 0? Tag-check violations where the ltag (logical tag) is 0 and the atag (actual tag) is non-zero can be caused by code patterns that strip the high bits that the ltag is stored in and fail to restore them before use. Additionally, arm64 binaries produced by older versions of clang may have issues where the tag is incorrectly stripped from the pointer. Recompiling the binary with a recent compiler should remediate the issue. Can I use Memory Integrity Enforcement with older Swift versions? Yes, Memory Integrity Enforcement can be used with any Swift version. Pointer Authentication (PAC) How does Pointer Authentication work and why is it opt-in? PAC is an opt-in feature because although adopting PAC is frequently as easy as turning on the compiler flag, some software is not trivially compatible. For example, while it mostly works in arm64 to memcpy a C++ object, this is invalid and generates fatal exceptions in arm64e. Additionally, PAC is a compile time change as it requires different instructions throughout the program. Pointer authentication makes it more difficult to create a pointer (from an integer) or to modify an existing pointer. This complements technologies such as MTE (which can catch many bound and lifetime errors) and typed allocation (which mitigates the effects of memory re-use). Where are the cryptographic keys for Pointer Authentication stored? The keys used for generating PAC signatures are stored in the CPU itself as specified by the ARM architecture. These keys are ephemeral and can change across process launches and boots, depending on which PAC key is used. The signatures are, however, stored in the upper bits of the pointer itself. How does Pointer Authentication work with Objective-C method swizzling? When you use the functions provided by the ObjC runtime, they ensure that any necessary pointer signing is correctly handled. What deployment targets and OS versions support Pointer Authentication? PAC is tied to the arm64e architecture. arm64e is first supported in iOS 17.4, and generally supported starting with iOS 26 and macOS 26. Universal binaries can be built for arm64e + arm64, and arm64 will be used when arm64e isn't supported. When building the universal binary, both architectures can be compiled for an older deployment target, but keep in mind that arm64e will only be used on newer iOS. How do I enable Pointer Authentication in modular apps? arm64e is indeed required, and every target that contributes binary code that's linked or dynamically loaded into an app does need to have arm64e added as an architecture. When enabling the Enhanced Security capability, Xcode adds the ENABLE_POINTER_AUTHENTICATION build setting (that adds arm64e) as needed, but you may need to add that separately as well. Bounds Safety and Annotations How do bounds safety checks work in Clang? With -fbounds-safety enabled Clang will emit bounds checks wherever pointers are dereferenced or reassigned (exception: assigning to __bidi_indexable does not trigger a bounds check, since __bidi_indexable can track the fact that the pointer is out of bounds and defer the bounds check). If the bounds check fails the program will jump to an instruction that traps the process. Clang uses a combination of static analysis and runtime checks to enforce that pointer bounds are respected. How can I work with libraries that don't have bounds annotations? Forging safe pointers at the boundary (using __unsafe_forge_single etc.) is the recommended approach when interoperating with libraries that do not have bounds annotations, when you want to be explicit about the fact that you're interacting with unsafe code. This makes it easy to grep for "unsafe" in your code base when doing a security audit. If you are confident that the API adheres to a bounds safe interface but simply lacks the annotations, you can redeclare the signature in your local header with added bounds annotations, like this: //--- system_header.h bar_t * /* implicitly __unsafe_indexable */ foo(); //--- project_header.h #include <ptrcheck.h> #include <system_header.h> bar_t * __single foo(); How can I safely pass Swift data to C/C++ functions? This is a great question! Automatically generated wrapper functions that safely unwrap Span types and pass along the pointer to C/C++ is a feature available since Xcode 26 when the experimental feature SafeInteropWrappers is enabled. This requires annotating std::span<T> parameters with __noescape, or pointer parameters with both __noescape and __counted_by/__sized_by, directly in the header or using API notes. Note that this is only safe if Swift can accurately track the lifetime of the unwrapped pointer, which is why the Span wrapper is not generated without the __noescape annotation. Since this is an experimental feature with ongoing development, questions and feedback on the Swift forums are extra welcome to help us shape and stabilize this feature! Continued in next post...

Hi everyone, I’ve been working on an experimental prototype called FaceBridge that explores whether Secure Enclave–backed biometric authorization can be delegated between macOS and iPhone using only public Apple APIs. The goal of the project was to better understand the architectural boundaries of cross-device trust and approval flows that resemble Apple’s built-in Touch ID / Continuity authorization experiences. FaceBridge implements a local authorization pipeline where: macOS generates a signed authorization request the request is delivered to a trusted nearby iPhone over BLE / Network framework the iPhone verifies sender identity Face ID approval is requested using LocalAuthentication the iPhone signs the approval response using Secure Enclave–backed keys macOS validates the response and unlocks a protected action Security properties currently implemented: • Secure Enclave–backed signing identities per device • cryptographic device pairing and trust persistence • replay protection using nonce + timestamp binding • structured authorization request/response envelopes • signed responder identity verification • trusted-device registry model • local encrypted transport over BLE and local network This is intentionally not attempting to intercept or replace system-level Touch ID dialogs (App Store installs, Keychain prompts, loginwindow, etc.), but instead explores what is possible within application-level authorization boundaries using public APIs only. The project is open source: https://github.com/wesleysfavarin/facebridge Technical architecture write-up: https://medium.com/@wesleysfavarin/facebridge I’m particularly interested in feedback around: • recommended Secure Enclave identity lifecycle patterns • best practices for cross-device trust persistence • LocalAuthentication usage in delegated approval scenarios • whether similar authorization models are expected to become more formally supported across Apple platforms in the future Thanks in advance for any guidance or suggestions.

Thanks all for reading my post. A bit of context: We just finished an app transfer to our developer account. We successfully signed and generated the new release. We are already able to roll it out in testflight were we found an issue. We store valuable data in the Keychain like Authentication tokens, once the new app is installed over the old one we are experiencing a loss of all data as the keychain become "untrusted". This is worst case scenario for us because all users will immediately lose the access to the app and hence the whole system. Questions: Is there a way to solve this issue, something like migration of the Keychain data? We came to know the standard migration path: Release a version that copies items from the old access groups to a new group based on com.apple.security.application-groups (App Groups). Wait for most users to update and run the migration. Then perform the App ID prefix change. Is this still the best method? Any improvements or new tools available since the 2022 DTS post? The problem with this is that the app is already on our account and that might need to rollback the transfer. Right? How long should we realistically wait for user migration before making the prefix change? Is there a way to measure migration completion? Thank you in advance!

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.

Background We're building a macOS application that acts as a CryptoTokenKit software token. The architecture follows the documented pattern: a container app (a long-running agent process) manages token registration and identity updates via TKTokenDriverConfiguration, and a separate appex extension process handles the actual signing operations for client sessions. What we're doing At agent startup, the container app calls [TKTokenDriverConfiguration driverConfigurations] to obtain our token driver, then registers a token instance ID: NSDictionary<TKTokenDriverClassID, TKTokenDriverConfiguration *> *driverConfigurations = [TKTokenDriverConfiguration driverConfigurations]; TKTokenDriverConfiguration driver = / first value from driverConfigurations */; [driver addTokenConfigurationForTokenInstanceID:@"setoken"]; When the agent renews a certificate, it pushes updated TKTokenKeychainItem objects to ctkd by setting keychainItems on the TKTokenConfiguration: TKTokenConfiguration *tokenCfg = driver.tokenConfigurations[@"setoken"]; tokenCfg.keychainItems = updatedItems; This works correctly during normal operation. The failure When ctkd is restarted (e.g., killall ctkd, or the system restarts the daemon), all subsequent calls through the existing TKTokenDriverConfiguration reference silently fail. Specifically: [TKTokenDriverConfiguration driverConfigurations] returns the same stale object - it does not establish a new connection to the newly-started ctkd process. There is no error, no exception, and no indication the returned object is invalid. driver.tokenConfigurations[@"setoken"] still returns a non-nil value reflecting the pre-restart state - so any nil check intended to detect "token not registered with ctkd" does not fire. [driver addTokenConfigurationForTokenInstanceID:@"setoken"] appears to succeed (no error) but the token is not actually registered with the new ctkd instance. Setting tokenCfg.keychainItems = updatedItems appears to succeed but the new ctkd instance has no knowledge of the update. The only reliable recovery we've found is restarting the container app process itself, at which point [TKTokenDriverConfiguration driverConfigurations] returns a fresh object connected to the new ctkd instance. What we've investigated There is no public API on TKTokenDriverConfiguration to invalidate or refresh the internal XPC connection to ctkd TKTokenWatcher can observe token insertions/removals, but we found no documented way to use it to detect a ctkd process restart specifically The NSXPCConnection invalidation handler pattern is not accessible through the TKTokenDriverConfiguration abstraction Moving credential management into the appex extension. Since the appex extension is recreated when the ctkd process restarts, we are able to update keychainItems from the extension. However, this comes with it's own set of problems: the extension is ephemeral and using the keychain APIs directly from the extension is not well documented and does not appear to be a supported pattern. Questions Is there a supported API to detect that ctkd has restarted and that the existing TKTokenDriverConfiguration reference is no longer valid? Is there a supported way to obtain a fresh TKTokenDriverConfiguration without restarting the container app? Should the container app be re-architected to avoid holding long-lived TKTokenDriverConfiguration references?

I am not able to use Feedback because the app can not reset my password.

I lived with knowledge that one needs to provide his login password to unlock the login keychain. This does not seem to be entirely true after upgrading Tahoe to 26.4. For example, on 26.3: Go to ~/Library/Keychains Copy login.keychain-db to different name, say test.keychain-db. Double-click on test.keychain-db -> this should open Keychain Access with test in Custom keychains section, it will appear locked. Select test keychain and press Cmd+L to unlock it. When prompted, provide your login password. Result: the keychain is unlocked. When I preform above sequence of steps on 26.4 I am not able to unlock the copied keychain (the original login keychain appears implicitly unlocked).

Hi, I’m building a macOS tool that analyzes process behavior to detect autonomous / AI-like activity locally (process trees, file access patterns, and network usage). The system is fully user-space and runs locally in real time. I’m planning to use the Endpoint Security Framework for process and file event monitoring. This is an open-source project (non-enterprise), developed by a solo developer. My question: What are the realistic chances of getting Endpoint Security entitlements approved for this type of project? Are there specific requirements or common reasons for rejection I should be aware of? Thanks, sivan-rnd

We are using the CryptoTokenKit framework, specifically the classes TKSmartCardSlotManager, TKSmartCardSlot, and TKSmartCard, to communicate with smart cards through external USB readers on iOS and iPadOS. In most cases, we are able to detect readers via TKSmartCardSlotManager, and send APDU commands using transmitRequest method, with the following code (where self->_slot and self->_card are previously created TkSmartCardSlot and TkSmartCard, respectively): #import <CryptoTokenKit/CryptoTokenKit.h> - (NSData *)sendCardCommand:(NSData *)command { if (!self->_card || !self->_card.valid || self->_slot.state != TKSmartCardSlotStateValidCard) return nil; NSMutableData *res = [[NSMutableData alloc] init]; NSError *sessionError = nil; [self->_card inSessionWithError:&sessionError executeBlock:^BOOL(NSError **error) { dispatch_semaphore_t semaphore = dispatch_semaphore_create(0); try { [self->_card transmitRequest:command reply:^(NSData * _Nullable response, NSError* _Nullable apduError) { if (apduError != nil) self->_error = apduError; else [res appendData: response]; dispatch_semaphore_signal(semaphore); }]; } catch (NSException *exception) { dispatch_semaphore_signal(semaphore); } dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER); if (res.length == 0) return NO; return YES; }]; return res; } However, with certain other USB smart card readers, we occasionally encounter APDU communication failures when calling transmitRequest (for instance, with a HID Global OMNIKEY 5422), which returns the following error: "Domain: CryptoTokenKit Code: -2". Once a failure occurs and transmitRequest starts returning this error, all subsequent calls to transmitRequest fail with the same error. This persists even when: A different smart card is inserted The same card is reinserted A different USB reader (previously working correctly) is connected The TKSmartCard object is recreated via makeSmartCard The slot state changes (observed via KVO) All internal objects (TKSmartCard, TKSmartCardSlot) are reset in the application At this point, the system appears to be stuck in a non-recoverable state which affects all readers and cards, including those that were previously functioning correctly. The only way to recover from this state is terminating and restarting the application which is running the code. After restarting the app, everything works normally again. We have created a bug report: FB22339746. The issue has been reproduced on iOS 26.4 and 18.5. Also on iPadOS 18.1. Anyone has already faced a similar issue? Could it be related to some internal state of TKSmartCardSlotManager?

I am researching URL preview functionality. https://sec-research.invalid/poc"onmouseover="alert(document.domain) Can someone verify on iOS 17?

I have a question regarding Platform SSO and the use of Secure Enclave–backed keys with biometric policies. If we configure userSecureEnclaveKeyBiometricPolicy with userSecureEnclaveKey, my understanding is that the Secure Enclave key is protected by biometric authentication (e.g., Face ID / Touch ID). In this setup, during a login request that also refreshes the id_token and refresh_token, the assertion is signed using the userSecureEnclaveKey. My question is: Will this signing operation trigger a biometric prompt every time the assertion is generated (i.e., during login/token refresh) ?

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.

Hello, sorry for the awkward text formatting but I kept getting prevented from positing due to "sensitive language"... Help.txt

I’m developing an iOS application and aiming to install a PKCS#12 (.p12) certificate into the com.apple.token keychain access group so that Microsoft Edge for iOS, managed via MDM/Intune, can read and use it for client certificate authentication. I’m attempting to save to the com.apple.token keychain access group, but I’m getting error -34018 (errSecMissingEntitlement) and the item isn’t saved. This occurs on both a physical device and the simulator. I’m using SecItemAdd from the Security framework to store it. Is this the correct approach? https://developer.apple.com/documentation/security/secitemadd(::) I have added com.apple.token to Keychain Sharing. I have also added com.apple.token to the app’s entitlements. Here is the code I’m using to observe this behavior: public static func installToTokenGroup(p12Data: Data, password: String) throws -> SecIdentity { // First, import the P12 to get the identity let options: [String: Any] = [ kSecImportExportPassphrase as String: password ] var items: CFArray? let importStatus = SecPKCS12Import(p12Data as CFData, options as CFDictionary, &items) guard importStatus == errSecSuccess, let array = items as? [[String: Any]], let dict = array.first else { throw NSError(domain: NSOSStatusErrorDomain, code: Int(importStatus), userInfo: [NSLocalizedDescriptionKey: "Failed to import P12: \(importStatus)"]) } let identity = dict[kSecImportItemIdentity as String] as! SecIdentity let addQuery: [String: Any] = [ kSecClass as String: kSecClassIdentity, kSecValueRef as String: identity, kSecAttrLabel as String: kSecAttrAccessGroupToken, kSecAttrAccessible as String: kSecAttrAccessibleAfterFirstUnlock, kSecAttrAccessGroup as String: kSecAttrAccessGroupToken ] let status = SecItemAdd(addQuery as CFDictionary, nil) if status != errSecSuccess && status != errSecDuplicateItem { throw NSError(domain: NSOSStatusErrorDomain, code: Int(status), userInfo: [NSLocalizedDescriptionKey: "Failed to add to token group: \(status)"]) } return identity }

Hello, I’m working on a security agent plugin for Mac. The plugin provides a mechanism with custom UI via SFAuthorizationPluginView and a privileged mechanism with the business logic. The plugin needs to support unlocking the device, so I changed the authorize right to invoke my agent: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>evaluate-mechanisms</string> <key>created</key> <real>731355374.33196402</real> <key>mechanisms</key> <array> <string>FooBar:loginUI</string> <string>builtin:reset-password,privileged</string> <string>FooBar:authenticate,privileged</string> <string>builtin:authenticate,privileged</string> </array> <key>modified</key> <real>795624943.31730103</real> <key>shared</key> <true/> <key>tries</key> <integer>10000</integer> <key>version</key> <integer>1</integer> </dict> </plist> I also changed the system.login.screensaver right to use authorize-session-owner: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>class</key> <string>rule</string> <key>comment</key> <string>The owner or any administrator can unlock the screensaver, set rule to "authenticate-session-owner-or-admin" to enable SecurityAgent.</string> <key>created</key> <real>731355374.33196402</real> <key>modified</key> <real>795624943.32567298</real> <key>rule</key> <array> <string>authenticate-session-owner</string> </array> <key>version</key> <integer>1</integer> </dict> </plist> I also set screenUnlockMode to 2, as was suggested in this thread: macOS Sonoma Lock Screen with SFAutorizationPluginView is not hiding the macOS desktop. In the Display Authorization plugin at screensaver unlock thread, Quinn said that authorization plugins are not able to use Touch ID. However, on a MacBook with at touch bar, when I lock the screen, close the lid, and then open it, the touch bar invites me to unlock with Touch ID. If I choose to do so, the screen unlocks and I can interact with the computer, but the plugin UI stays on screen and never goes away, and after about 30 seconds the screen locks back. I can reliably reproduce it on a MacBook Pro with M1 chip running Tahoe 26.1. Is this a known macOS bug? What can I do about it? Ideally, I would like to be able to integrate Touch ID into my plugin, but since that seems to be impossible, the next best thing would be to reliably turn it off completely. Thanks in advance.

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

PLATFORM AND VERSION iOS Development environment: Xcode 26.2, macOS x Run-time configuration: iOS The issue does not seem to be limited to a specific version. DESCRIPTION OF PROBLEM We are reaching out to request in-depth technical assistance regarding an intermittent issue with Sign in with Apple implementation in our application. [Technical Status] We have confirmed that our technical implementation is correct. All necessary code and Xcode Capabilities are properly configured, and the service is working perfectly for the vast majority of our users. However, a small subset of users is consistently encountering "Unknown" Error (Error Code 1000), which prevents them from logging in entirely. [Identified Scenario] Currently, the only reproducible case we have found involves Child Accounts (protected accounts) under Family Sharing, specifically when the user's age is set below the regional requirement for a standalone Apple ID. However, we are receiving reports from other users who do not seem to fall into this category. [Requests for Clarification] To resolve this issue and support our users, we would like to obtain clear answers to the following questions: Root Cause: Why does Error 1000 occur specifically for a small number of users while the service works for most others? Other Scenarios: Are there any known cases or conditions other than the "Child Account" age restriction that trigger this specific error? Account-side Issues: If our code and configurations are verified to be correct, should we conclude that this is an issue specific to the individual's Apple ID/Account status? If so, could you provide a troubleshooting guide or official recommendation that we can share with these users to help them resolve their account-related issues? We are committed to providing a seamless authentication experience and would appreciate your expert insight into these edge cases. Thank you for your support. - (void) quickLogin:(uint)requestId withNonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *appleIDRequest = [[self appleIdProvider] createRequest]; [appleIDRequest setNonce:nonce]; [appleIDRequest setState:state]; ASAuthorizationPasswordRequest *keychainRequest = [[self passwordProvider] createRequest]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[appleIDRequest, keychainRequest]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) loginWithAppleId:(uint)requestId withOptions:(AppleAuthManagerLoginOptions)options nonce:(NSString *)nonce andState:(NSString *)state { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { ASAuthorizationAppleIDRequest *request = [[self appleIdProvider] createRequest]; NSMutableArray *scopes = [NSMutableArray array]; if (options & AppleAuthManagerIncludeName) [scopes addObject:ASAuthorizationScopeFullName]; if (options & AppleAuthManagerIncludeEmail) [scopes addObject:ASAuthorizationScopeEmail]; [request setRequestedScopes:[scopes copy]]; [request setNonce:nonce]; [request setState:state]; ASAuthorizationController *authorizationController = [[ASAuthorizationController alloc] initWithAuthorizationRequests:@[request]]; [self performAuthorizationRequestsForController:authorizationController withRequestId:requestId]; } else { [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsLoginResponseInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif } - (void) getCredentialStateForUser:(NSString *)userId withRequestId:(uint)requestId { #if AUTHENTICATION_SERVICES_AVAILABLE if (@available(iOS 13.0, tvOS 13.0, macOS 10.15, *)) { [[self appleIdProvider] getCredentialStateForUserID:userId completion:^(ASAuthorizationAppleIDProviderCredentialState credentialState, NSError * _Nullable error) { NSNumber *credentialStateNumber = nil; NSDictionary *errorDictionary = nil; if (error) errorDictionary = [AppleAuthSerializer dictionaryForNSError:error]; else credentialStateNumber = @(credentialState); NSDictionary *responseDictionary = [AppleAuthSerializer credentialResponseDictionaryForCredentialState:credentialStateNumber errorDictionary:errorDictionary]; [self sendNativeMessageForDictionary:responseDictionary forRequestId:requestId]; }]; } else { [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; } #else [self sendsCredentialStatusInternalErrorWithCode:-100 andMessage:@"Native AppleAuth is only available from iOS 13.0" forRequestWithId:requestId]; #endif }

I'm currently reviewing the various DCError cases defined in Apple’s DeviceCheck framework (reference: https://developer.apple.com/documentation/devicecheck/dcerror-swift.struct). To better understand how to handle these in production, I’m looking for a clear breakdown of: Which specific DCError values can occur during service.generateKey, service.attestKey, and service.generateAssertion The realworld scenarios or conditions that typically cause each error for each method. If anyone has insight on how these errors arise and what conditions trigger them, I’d appreciate your input.

I downloaded a P12 file (containing a private key) from the company server, and retrieved the private key from this P12 file using a password : private func loadPrivateKeyFromPKCS12(path: String, password: String) throws -> SecKey? { let p12Data: Data do { p12Data = try Data(contentsOf: fileURL) } catch let readError { ... } let options: [CFString: Any] = [ kSecImportExportPassphrase: password as CFString ] var items: CFArray? let status = SecPKCS12Import(p12Data as CFData, options as CFDictionary, &items) guard status == errSecSuccess else { throw exception } var privateKey: SecKey? let idd = identity as! SecIdentity let _ = SecIdentityCopyPrivateKey(idd, &privateKey) return privateKey } However, when I use this private key to call SecKeyCreateSignature for data signing, a dialog box always pops up to ask user to input the Mac admin password. What confuses me is that this private key is clearly stored in the local P12 file, and there should be no access to the keychain involved in this process. Why does the system still require the user's login password for signing? Is it possible to perform silent signing (without the system dialog popping up) in this scenario?

We have successfully deployed our Qt C++ application on Windows and Android using OpenSSL with TLS Pre-Shared Key (PSK) authentication to connect to our servers. However, I understand that apps submitted to the App Store must use SecureTransport as the TLS backend on iOS. My understandiunig is that SecureTransport does not support PSK ciphersuites, which is critical for our security architecture. Questions: Does SecureTransport support TLS PSK authentication, or are there plans to add this feature? If PSK is not supported, what is Apple's recommended alternative for applications that require PSK-based authentication? Is there an approved exception process that would allow me to use OpenSSL for TLS connections on iOS while still complying with App Store guidelines? The application requires PSK for secure communication with our infrastructure, and we need guidance on how to maintain feature parity across all platforms while meeting App Store requirements