During internal testing, we observed the following behavior and would appreciate clarification on whether it is expected and supported in production environments. When generating an elliptic-curve cryptographic key pair using "kSecAttrTokenIDSecureEnclave", and explicitly specifying a "kSecAttrAccessGroup", we found that cryptographic operations (specifically encryption and decryption) could be successfully performed using this key pair from two distinct applications. Both applications had the Keychain Sharing capability enabled and were signed with the same provisioning profile identity. Given the documented security properties of Secure Enclave, backed keys, namely that private key material is protected by hardware and access is strictly constrained by design, we would like to confirm whether the ability for multiple applications (sharing the same keychain access group and signing identity) to perform cryptographic operations with the same Secure Enclave–backed key is expected behavior on iOS. Specifically, we are seeking confirmation on: Whether this behavior is intentional and supported in production. Whether the Secure Enclave enforces access control primarily at the application-identifier (App ID) level rather than the individual app bundle level in this scenario. Whether there are any documented limitations or guarantees regarding cross-application usage of Secure Enclave keys when keychain sharing is configured. Any guidance or references to official documentation clarifying this behavior would be greatly appreciated.

Hello, I am unable to configure Sign in with Apple on my developer account. Whenever I try to: Enable/disable the Sign in with Apple capability in my App ID, or Configure a Service ID for web authentication, the portal does not save my changes. In the browser developer console, I consistently see this error: Request URL: https://developer.apple.com/services-account/v1/bundleIds/XXXXXXXX Request Method: PATCH Status Code: 501 Not Implemented This happens across all browsers (Safari, Chrome, Incognito) and even after clearing cache. It affects my entire account, not just one App ID. I have already tried: Creating a new Service ID → still fails. Creating a new App ID → still fails. Re-enabling the capability → save does not work. Different browsers and devices → same result. Has anyone else experienced this issue, and is there a known fix? Or is this something that Apple Developer Support needs to resolve at the account level?

FB18383742 Setup 🛠️ Xcode 16.4 (16F6) 📱 iPhone 13 mini (iOS 18.0.1) ⌚️ Apple Watch Series 10 (watchOS 11.3.1) Observations As AccessorySetupKit does not request "Core Bluetooth permissions", when a watchOS companion app is installed after having installed the iOS app, the toggle in the watch settings for Privacy & Security > Bluetooth is turned off and disabled After removing the iPhone associated with the Apple Watch, Bluetooth works as expected in the watchOS app Upon reinstalling the iOS app, there's a toggle for Bluetooth in the iOS ASK app's settings and the ASK picker cannot be presented 🤨 From ASK Documentation: AccessorySetupKit is available for iOS and iPadOS. The accessory’s Bluetooth permission doesn’t sync to a companion watchOS app. But this doesn't address not being able to use Core Bluetooth in a watch companion app at all 🥲 Reproducing the bug Install the iOS + watchOS apps Launch iOS app, tap "start scan", observe devices can be discovered (project is set up to find heart rate monitors) Launch watchOS, tap allow on Bluetooth permission pop-up watchOS app crashes 💥 Meanwhile, in the iOS app, there should be a log entry for 💗 CBCentralManager state: poweredOff and the ASK picker is no longer able to discover any devices The state of the device permissions: iOS app has no paired accessories or Bluetooth permission watchOS app's Bluetooth permission shown as turned off & disabled Remove the iOS app Relaunch the watchOS app Notice the CBCentralManager state is unauthorized Remove and reinstall the watchOS app Tap allow on Bluetooth permission pop-up watchOS app does not crash and CBCentralManager state is poweredOn The state of the watch permissions: Bluetooth is turned on & the toggle is not disabled Note that at this time the iOS app is not installed, there is no way to remove Bluetooth permission for the watch app. Reinstall + launch the iOS app Notice a warning in the log: [##### WARNING #####] App has companion watch app that maybe affected if using CoreBluetooth framework. Please read developer documentation for AccessorySetupKit. Notice a log entry for 💗 CBCentralManager state: poweredOn before tapping start scan Tap start scan and observe another log entry: Failed to show picker due to: The operation couldn’t be completed. (ASErrorDomain error 550.) ASErrorDomain 550: The picker can't be used because the app is in the background. Is this the expected error? 🤔 The state of the iOS permissions: The app's settings show a Bluetooth toggle normally associated with Core Bluetooth, but the app never showed a Core Bluetooth pop-up The iOS ASK app now has Core Bluetooth permission 😵‍💫 Following up with Apple This is a known bug that should be fixed in watchOS 26 when Bluetooth permissions for watch apps can be set independently of the iOS app. I've yet to test it with watchOS 26. See repo for the same post with screenshots of the settings and demo code reproducing the bug: https://github.com/superturboryan/AccessorySetupKit-CoreBluetooth-watchOS-Demo

While working with Platform SSO on macOS, I’m trying to better understand how the system handles cases where a user’s local account password becomes unsynchronized with their Identity Provider (IdP) password—for example, when the device is offline during a password change. My assumption is that macOS may store some form of persistent token during the Platform SSO user registration process (such as a certificate or similar credential), and that this token could allow the system to unlock the user’s login keychain even if the local password no longer matches the IdP password. I’m hoping to get clarification on the following: Does macOS actually use a persistent token to unlock the login keychain when the local account password is out of sync with the IdP password? If so, how is that mechanism designed to work? If such a capability exists, is it something developers can leverage to enable a true passwordless authentication experience at the login window and lock screen (i.e., avoiding the need for a local password fallback)? I’m trying to confirm what macOS officially supports so I can understand whether passwordless login is achievable using the persistent-token approach. Thanks in advance for any clarification.

I am implementing Apple Sign-In for a multi-platform application, specifically for the web component using the REST API flow. I am encountering an invalid_request Invalid web redirect url error when attempting to use a newly registered redirect URL. Here are the details: Original Test URL: I initially registered a redirect URL, let's call it [Your Original Test Redirect URL, e.g., https://test.yourdomain.com/auth/callback], for testing purposes. This URL worked correctly. New Service URL: I then registered a second redirect URL, [Your New Service Redirect URL, e.g., https://www.yourdomain.com/auth/callback], intended for my production service. This URL was registered approximately 5 days ago (including the weekend). The Problem: The new service URL ([Your New Service Redirect URL]) is still not working and consistently returns the invalid_request Invalid web redirect url error. Puzzling Behavior: Furthermore, I have since deleted the original test URL ([Your Original Test Redirect URL]) from the Service ID configuration in the Apple Developer portal. However, the deleted test URL still appears to function correctly when I use it. This situation is highly confusing: The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. The Service ID in question is [Your Service ID, e.g., com.yourdomain.service]. Could you please investigate why the new redirect URL ([Your New Service Redirect URL]) is not becoming active and is returning the invalid_request error, and also explain why the deleted URL ([Your Original Test Redirect URL]) remains functional? Any guidance or assistance you can provide to resolve this issue with the new URL would be greatly appreciated. Thank you for your time and support. Sincerely, I have the exact same problem. The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. In addition to the above problem, I also get a response of 'invalid_client' when I newly register a service in configuration. Please check it out as it needs to be resolved quickly.

Hi! We are developing an authentication plugin for macOS that integrates with the system's authentication flow. The plugin is designed to prompt the user for approval via a push notification in our app before allowing access. The plugin is added as the first mechanism in the authenticate rule, followed by the default builtin:authenticate as a fallback. When the system requests authentication (e.g., during screen unlock), our plugin successfully displays the custom UI and sends a push notification to the user's device. However, I've encountered the following issue: If the user does not approve the push notification within ~30 seconds, the system resets the screen lock (expected behavior). If the user approves the push notification within approximately 30 seconds but doesn’t start entering their password before the timeout expires, the system still resets the screen lock before they can enter their password, effectively canceling the session. What I've Tried: Attempted to imitate mouse movement after the push button was clicked to keep the session active. Created a display sleep prevention assertion using IOKit to prevent the screen from turning off. Used the caffeinate command to keep the display and system awake. Tried setting the result as allow for the authorization request and passing an empty password to prevent the display from turning off. I also checked the system logs when this issue occurred and found the following messages: ___loginwindow: -[LWScreenLock (Private) askForPasswordSecAgent] | localUser = >timeout loginwindow: -[LWScreenLock handleUnlockResult:] _block_invoke | ERROR: Unexpected _lockRequestedBy of:7 sleeping screen loginwindow: SleepDisplay | enter powerd: Process (loginwindow) is requesting display idle___ These messages suggest that the loginwindow process encounters a timeout condition, followed by the display entering sleep mode. Despite my attempts to prevent this behavior, the screen lock still resets prematurely. Questions: Is there a documented (or undocumented) system timeout for the entire authentication flow during screen unlock that I cannot override? Are there any strategies for pausing or extending the authentication timeout to allow for complex authentication flows like push notifications? Any guidance or insights would be greatly appreciated. Thank you!

QuickLookAR shares the actual USDZ model instead of the original website URL — critical copyright and data leak issue on iOS 26 Since iOS 26, QuickLookAR (or ARQuickLookPreviewItem) no longer preserves the original web URL when sharing a model. Instead of sending the link to the hosted file, the system directly shares the actual USDZ model file with the recipient. This is a critical regression and a severe breach of intellectual property protection, as it exposes proprietary 3D models that must never be distributed outside of the controlled web environment. In earlier iOS versions (tested up to iOS 18), QuickLookAR correctly handled sharing — the share sheet would send the website link where the model is hosted, not the file itself. Starting with iOS 26, this behavior has changed and completely breaks the intended secure flow for AR experiences. Our project relies on allowing users to view models in AR via QuickLook, without ever transferring the underlying 3D assets. Now, the share operation forces full file sharing, giving end users unrestricted access to the model file, which can be copied, rehosted, or reverse-engineered. This issue critically affects production environments and prevents us from deploying our AR-based solutions. Implement a standard QuickLookAR preview with a USDZ file hosted on your web server (e.g., via ARQuickLookPreviewItem). 2. Open the AR view on iOS 26. 3. Tap the Share icon from QuickLookAR. 4. Send via any messenger (Telegram, WhatsApp, etc.). 5. Observe that the actual .usdz model is sent instead of the original website URL. ⸻ Expected behavior: QuickLookAR should share only the original URL (as in iOS 17–18), not the file itself. This ensures that intellectual property and licensed 3D models remain protected and controlled by the content owner. ⸻ Actual behavior: QuickLookAR shares the entire USDZ file, leaking the model content outside of the intended environment. ⸻ Impact: • Violation of copyright and confidential data policies • Loss of control over proprietary 3D assets • Breaking change for all existing web-based AR integrations • Critical blocker for AR production deployment ⸻ Environment: • iOS 26.0 and 26.1 (tested on iPhone 14, iPhone 15) • Safari + QuickLookAR integration • Works correctly on iOS 17 / iOS 18 ⸻ Notes: This regression appears to have been introduced in the latest iOS 26 system handling of QuickLookAR sharing. Please escalate this issue to the ARKit / QuickLook engineering team as it directly affects compliance, IP protection, and usability of AR features across production applications. Additional Notes / Verification: Please test this behavior yourself using the CheckAR test model on my website: https://admixreality.com/ios26/ • If the login page appears, click “Check AR” and then “View in Your Space”. • On iOS 18 and earlier, sharing correctly sends the website URL. • On iOS 26, sharing sends the actual USDZ model file. This clearly demonstrates the regression and the security/IP issue.

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!

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.

I'm using aws cognito for authentication in my app, and added the "Sign in with apple" identity provider. Not working at all by displaying "Sign Up Not Completed" error. I am using custom domain in cognito.. I tried recreating the Private Key, and also recreating the Service Identifier. Nothing helped. Anyone experiencing anything like this?

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?

I am implementing Apple Sign-In for a multi-platform application, specifically for the web component using the REST API flow. I am encountering an invalid_request Invalid web redirect url error when attempting to use a newly registered redirect URL. Here are the details: Original Test URL: I initially registered a redirect URL, let's call it [Your Original Test Redirect URL, e.g., https://test.yourdomain.com/auth/callback], for testing purposes. This URL worked correctly. New Service URL: I then registered a second redirect URL, [Your New Service Redirect URL, e.g., https://www.yourdomain.com/auth/callback], intended for my production service. This URL was registered approximately 5 days ago (including the weekend). The Problem: The new service URL ([Your New Service Redirect URL]) is still not working and consistently returns the invalid_request Invalid web redirect url error. Puzzling Behavior: Furthermore, I have since deleted the original test URL ([Your Original Test Redirect URL]) from the Service ID configuration in the Apple Developer portal. However, the deleted test URL still appears to function correctly when I use it. This situation is highly confusing: The newly registered URL is not working after 5 days, while the URL I have deleted from the configuration is still operational. The Service ID in question is [Your Service ID, e.g., com.yourdomain.service]. Could you please investigate why the new redirect URL ([Your New Service Redirect URL]) is not becoming active and is returning the invalid_request error, and also explain why the deleted URL ([Your Original Test Redirect URL]) remains functional? Any guidance or assistance you can provide to resolve this issue with the new URL would be greatly appreciated. Thank you for your time and support. Sincerely,

Hi all, I’m building a password manager app for iOS. The app implements an ASCredentialProviderExtension and has the entitlement com.apple.developer.authentication-services.autofill-credential-provider. From a UX perspective, I’d like to help users enable my app under: Settings → General → AutoFill & Passwords What I’ve observed: Calling UIApplication.openSettingsURLString only opens my app’s own Settings page, not the AutoFill list. Some apps (e.g. Google Authenticator) appear to redirect users directly into the AutoFill Passwords & Passkeys screen when you tap “Enable AutoFill.” 1Password goes even further: when you tap “Enable” in 1Password App, it shows a system pop-up, prompts for Face ID, and then enables 1Password as the AutoFill provider without the user ever leaving the app. Questions: Is there a public API or entitlement that allows apps to deep-link users directly to the AutoFill Passwords & Passkeys screen? Is there a supported API to programmatically request that my app be enabled as an AutoFill provider (similar to what 1Password seems to achieve)? If not, what is the recommended approach for guiding users through this flow? Thanks in advance!

I hope this problem could be solved, also in case any other one strugling the same issue could be helpful. We are developing an iOS App which use "sign in with Apple" feature. We found we can not login with this feature, the "sign in with Apple" dialog box always flash an error info "Sign-Up Not Complete". We have double checked configuration of Bundle ID, and xcode capabilities, info.plist, entitlements, etc. We have even changed the developer team, using other bundle ID and demo code to testify this, also got failure of "Sign-Up Not Complete" error. We did even just use Apple official demo code (https://developer.apple.com/documentation/AuthenticationServices/implementing-user-authentication-with-sign-in-with-apple), also got the same failure. Interestingly, we found that using some old Bundle IDs which created before (even we did not use it for App yet), we could get "sign in with Apple" success logged in. Therefore we now can not include "sign in with Apple" feature in our App today, and this is the key feature in our App. Please help. Since there is very little information we could collect, I just put the debug error here: Authorization failed: Error Domain=AKAuthenticationError Code=-7003 "(null)" UserInfo={AKClientBundleID=com.nethawk.flutter.battlebuddy} LaunchServices: store (null) or url (null) was nil: Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Attempt to map database failed: permission was denied. This attempt will not be retried. Failed to initialize client context with error Error Domain=NSOSStatusErrorDomain Code=-54 "process may not map database" UserInfo={NSDebugDescription=process may not map database, _LSLine=72, _LSFunction=_LSServer_GetServerStoreForConnectionWithCompletionHandler} Failed to get application extension record: Error Domain=NSOSStatusErrorDomain Code=-54 "(null)" ASAuthorizationController credential request failed with error: Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1001 "(null)"

Hello, we are using DeviceCheck – App Attest in a production iOS app. The integration has been live for some time and works correctly for most users, but a small subset of users encounter non-deterministic failures that we are unable to reproduce internally. Environment iOS 14+ Real devices only (no simulator) App Attest capability enabled Correct App ID, Team ID and App Attest entitlement Production environment Relevant code let service = DCAppAttestService.shared service.generateKey { keyId, error in // key generation } service.attestKey(keyId, clientDataHash: hash) { attestation, error in // ERROR: com.apple.devicecheck.error 3 / 4 } service.generateAssertion(keyId, clientDataHash: clientDataHash) { assertion, error in // ERROR: com.apple.devicecheck.error 3 / 4 } For some users we intermittently receive: com.apple.devicecheck.error error 3 com.apple.devicecheck.error error 4 Characteristics: appears random affects only some users/devices sometimes resolves after time or reinstall not reproducible on our test devices NSError contains no additional diagnostic info Some questions: What is the official meaning of App Attest errors 3 and 4? Are these errors related to key state, device conditions, throttling, or transient App Attest service issues? Is there any recommended way to debug or gain more insight when this happens in production? Any guidance would be greatly appreciated, as this impacts real users and is difficult to diagnose. Thank you.

iOS18.1.1 macOS15.1.1 xcode16.1 Error Domain=com.apple.AuthenticationServices.AuthorizationError Code=1004 "Unable to verify webcredentials association of ********** with domain ******************. Please try again in a few seconds." Our domain must query with VPN, so I set webcredentials:qa.ejeokvv.com?mode=developer following: "If you use a private web server, which is unreachable from the public internet, while developing your app, enable the alternate mode feature to bypass the CDN and connect directly to your server. To do this, add a query string to your associated domains entitlement, as shown in the following example: :?mode= " but it still not working, even after I set mode=developer. Please help!!!!

Hi! Is it possible to disable the option for users to 'Sign in with Another Device'? I encounter this message during the authentication process and I want to prevent it from appearing. I appreciate your help and look forward to your response.

Hi, After enabling the new Enhanced Security capability in Xcode 26, I’m seeing install failures on devices running < iOS 26. Deployment target: iOS 15.0 Capability: Enhanced Security (added via Signing & Capabilities tab) Building to iOS 18 device error - Unable to Install ...Please ensure sure that your app is signed by a valid provisioning profile. It works fine on iOS 26 devices. I’d like to confirm Apple’s intent here: Is this capability formally supported only on iOS 26 and later, and therefore incompatible with earlier OS versions? Or should older systems ignore the entitlement, meaning this behavior might be a bug?

I have a binary executable which needs to be given Accessibility Permissions so it can inject keypresses and mouse moves. This was always possible up to macOS 15 - when the first keypress arrived the Accessibility Permissions window would open and allow me to add the executable. However this no longer works in macOS 26: the window still opens, I navigate to the executable file and select it but it doesn't appear in the list. No error message appears. I'm guessing that this may be due to some tightening of security in Tahoe but I need to figure out what to change with my executable to allow it to work.

I'm trying to export and re-import a P-256 private key that was originally generated via SecKeyCreateRandomKey(), but I keep running into roadblocks. The key is simply exported via SecItemExport() with format formatWrappedPKCS8, and I did set a password just to be sure. Do note that I must use the file-based keychain, as the data protection keychain requires a restricted entitlement and I'm not going to pay a yearly fee just to securely store some private keys for a personal project. The 7-day limit for unsigned/self-signed binaries isn't feasible either. Here's pretty much everything I could think of trying: Simply using SecItemImport() does import the key, but I cannot set kSecAttrLabel and more importantly: kSecAttrApplicationTag. There just isn't any way to pass these attributes upfront, so it's always imported as Imported Private Key with an empty comment. Keys don't support many attributes to begin with and I need something that's unique to my program but shared across all the relevant key entries, otherwise it's impossible to query for only my program's keys. kSecAttrLabel is already used for something else and is always unique, which really only leaves kSecAttrApplicationTag. I've already accepted that this can be changed via Keychain Access, as this attribute should end up as the entry's comment. At least, that's how it works with SecKeyCreateRandomKey() and SecItemCopyMatching(). I'm trying to get that same behaviour for imports. Running SecItemUpdate() afterwards to set these 2 attributes doesn't work either, as now the kSecAttrApplicationTag is suddenly used for the entry's label instead of the comment. Even setting kSecAttrComment (just to be certain) doesn't change the comment. I think kSecAttrApplicationTag might be a creation-time attribute only, and since SecItemImport() already created a SecKey I will never be able to set this. It likely falls back to updating the label because it needs to target something that is still mutable? Using SecItemImport() with a nil keychain (i.e. create a transient key), then persisting that with SecItemAdd() via kSecValueRef does allow me to set the 2 attributes, but now the ACL is lost. Or more precise: the ACL does seem to exist as any OS prompts do show the label I originally set for the ACL, but in Keychain Access it shows as Allow all applications to access this item. I'm looking to enable Confirm before allowing access and add my own program to the Always allow access by these applications list. Private keys outright being open to all programs is of course not acceptable, and I can indeed access them from other programs without any prompts. Changing the ACL via SecKeychainItemSetAccess() after SecItemAdd() doesn't seem to do anything. It apparently succeeds but nothing changes. I also reopened Keychain Access to make sure it's not a UI "caching" issue. Creating a transient key first, then getting the raw key via SecKeyCopyExternalRepresentation() and passing that to SecItemAdd() via kSecValueData results in The specified attribute does not exist. This error only disappears if I remove almost all of the attributes. I can pass only kSecValueData, kSecClass and kSecAttrApplicationTag, but then I get The specified item already exists in the keychain errors. I found a doc that explains what determines uniqueness, so here are the rest of the attributes I'm using for SecItemAdd(): kSecClass: not mentioned as part of the primary key but still required, otherwise you'll get One or more parameters passed to a function were not valid. kSecAttrLabel: needed for my use case and not part of the primary key either, but as I said this results in The specified attribute does not exist. kSecAttrApplicationLabel: The specified attribute does not exist. As I understand it this should be the SHA1 hash of the public key, passed as Data. Just omitting it would certainly be an option if the other attributes actually worked, but right now I'm passing it to try and construct a truly unique primary key. kSecAttrApplicationTag: The specified item already exists in the keychain. kSecAttrKeySizeInBits: The specified attribute does not exist. kSecAttrEffectiveKeySize: The specified attribute does not exist. kSecAttrKeyClass: The specified attribute does not exist. kSecAttrKeyType: The specified attribute does not exist. It looks like only kSecAttrApplicationTag is accepted, but still ignored for the primary key. Even entering something that is guaranteed to be unique still results in The specified item already exists in the keychain, so I think might actually be targeting literally any key. I decided to create a completely new keychain and import it there (which does succeed), but the key is completely broken. There's no Kind and Usage at the top of Keychain Access and the table view just below it shows symmetric key instead of private. The kSecAttrApplicationTag I'm passing is still being used as the label instead of the comment and there's no ACL. I can't even delete this key because Keychain Access complains that A missing value was detected. It seems like the key doesn't really contain anything unique for its primary key, so it will always match any existing key. Using SecKeyCreateWithData() and then using that key as the kSecValueRef for SecItemAdd() results in A required entitlement isn't present. I also have to add kSecUseDataProtectionKeychain: false to SecItemAdd() (even though that should already be the default) but then I get The specified item is no longer valid. It may have been deleted from the keychain. This occurs even if I decrypt the PKCS8 manually instead of via SecItemImport(), so it's at least not like it's detecting the transient key somehow. No combination of kSecAttrIsPermanent, kSecUseDataProtectionKeychain and kSecUseKeychain on either SecKeyCreateWithData() or SecItemAdd() changes anything. I also tried PKCS12 despite that it always expects an "identity" (key + cert), while I only have (and need) a private key. Exporting as formatPKCS12 and importing it with itemTypeAggregate (or itemTypeUnknown) does import the key, and now it's only missing the kSecAttrApplicationTag as the original label is automatically included in the PKCS12. The outItems parameter contains an empty list though, which sort of makes sense because I'm not importing a full "identity". I can at least target the key by kSecAttrLabel for SecItemUpdate(), but any attempt to update the comment once again changes the label so it's not really any better than before. SecPKCS12Import() doesn't even import anything at all, even though it does return errSecSuccess while also passing kSecImportExportKeychain explicitly. Is there literally no way?