Hello, These questions are in regard to transferring Sign in With Apple users as part of an app transfer to another developer team. We’ve already read and absorbed the following documents from Apple, but we still have questions that aren’t covered in these documents, due to the unique nature of our use case. Transferring Your Apps and Users to Another Team Bringing New Apps and Users Into Your Team Resolving Sign in with Apple Response Errors Background: We have a suite of three apps that we are tranferring to another developer team. Each app supports Sign In With Apple. Our accounts/users are shared among all three apps. We have all three apps currently grouped together for SIWA. We’re aware that we will need to un-group them before doing the SIWA user transfer. Questions: The API for generating and exchanging transferIDs for users (endpoint /auth/usermigrationinfo) requires a parameter client_id which is described in the docs as "The identifier (App ID or Services ID) for the transferring app." Since we are transferring a set of three apps which share users, we aren’t sure which AppID to use, or whether it matters? We’re assuming we only need to transfer the users once in total (not once-per-app), is this correct? Does it matter which of the three apps’ AppID we use for this? To give more specific context to this question, here’s a more detailed example: For simplicity’s sake, let’s say we have 10 user accounts total, and any of them could sign into any of our three apps. Users 1-7 have signed into all three apps previously User8 has only signed into AppA User9 has only signed into AppB User10 has only signed into AppC Ideally we want to transfer all 10 users all at once. Does it matter which AppID we use for client_id? For example, if we use AppA as the client_id, will we still be able to transfer all 10 users (including User9 and User10)? We’ve tested this on the sender team side, and we’re able to successfully create transferIDs for all 10 users using AppA as client_id. But we’re not sure if this will still work on the recipient side, that we’ll be able to exchange the transferID for all 10 users. . To add another wrinkle, there is a possibility that we won’t be able to transfer one of our three apps (due to one of Apple’s limitations for app transfer). In that case we’ll have to create a new app on the recipient team and shut down the old one on the sender team. But the other two apps in the suite would still be transferred normally. We’d still want all 10 users to be transferred, as the intention is still that all our users can sign into any of their existing accounts in any of the three apps. Would this scenario change the answer to question 1? For example, say we aren’t able to transfer AppC over to the new development team, but instead had to create a new app, AppCNew on the new development team. But we still are able to transfer AppA and AppB. Would we still be able to transfer all 10 users using AppA as the client_id? Including User10 who only ever signed in to AppC (which isn’t being transferred)? We'd really appreciate any answers or guidance that anyone can provide. Thank you, Adam

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

Hi there, I'm currently working on a compatibility feature for Apple that allows the user to manage their keys and certificates from within our internal API. For this I need to retrieve all the items contained within keychains. I am looking at the documentation for SecItem API but so far I have not really found an obvious way to link these items together. My best guess so far is to perform two queries, grabbing all SecKeys from the keychains, pairing them up with public keys through SecKeyCopyPublicKey, then downloading all CertItems and pairing them with public keys with SecCertificateCopyKey, and then join the two using public keys. This sounds however somewhat involved and I was wondering if there was a better way of going about the process?

Hi, I have a certificate, how can I display the certificate content in my Mac app just like Keychain Access app does. Can I popup the certificate content dialog just like Keychain Access app?

For testing purposes we have code that calls SecTrustEvaluateAsyncWithError() with a trust object containing a hardcoded leaf certificate and the corresponding intermediate certificate required to form a valid chain. Because the leaf certificate has since expired we pass a date in the past via SecTrustSetVerifyDate() at wich the certificate was still valid, but trust evaluation fails: Error Domain=NSOSStatusErrorDomain Code=-67825 "“<redacted>” certificate is not standards compliant" UserInfo={NSLocalizedDescription=“<redacted>” certificate is not standards compliant, NSUnderlyingError=0x600000c282a0 {Error Domain=NSOSStatusErrorDomain Code=-67825 "Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;" UserInfo={NSLocalizedDescription=Certificate 0 “<redacted>” has errors: Certificate Transparency validation required for this use;}}} I know that App Transport Security enforces Certificate Transparency by default, but is there a way around that here?

I'm building a tool for admins in the enterprise context. The app needs to do some things as root, such as executing a script. I was hoping to implement a workflow where the user clicks a button, then will be shown the authentication prompt, enter the credentials and then execute the desired action. However, I couldn't find a way to implement this. AuthorizationExecuteWithPrivileges looked promising, but that's deprecated since 10.7. I've now tried to use a launch daemon that's contained in the app bundle with XPC, but that seems overly complicated and has several downsides (daemon with global machservice and the approval of a launch daemon suggests to the user that something's always running in the background). Also I'd like to stream the output of the executed scripts in real time back to the UI which seems very complicated to implement in this fashion. Is there a better way to enable an app to perform authorized privilege escalation for certain actions? What about privileged helper tools? I couldn't find any documentation about them. I know privilege escalation is not allowed in the App Store, but that's not relevant for us.

We are interested in using a hardware-bound key in a launch daemon. In a previous post, Quinn explicitly told me this is not possible to use an SE keypair outside of the system context and my reading of the Apple documentation also supports that. That said, we have gotten the following key-creation and persistence flow to work, so we have some questions as to how this fits in with the above. (1) In a launch daemon (running thus as root), we do: let key = SecureEnclave.P256.Signing.PrivateKey() (2) We then use key.dataRepresentation to store a reference to the key in the system keychain as a kSecClassGenericPassword. (3) When we want to use the key, we fetch the data representation from system keychain and we "rehydrate" the key using: SecureEnclave.P256.Signing.PrivateKey(dataRepresentation: data) (4) We then use the output of the above to sign whatever we want. My questions: in the above flow, are we actually getting a hardware-bound key from the Secure Enclave or is this working because it's actually defaulting to a non-hardware-backed key? if it is an SE key, is it that the Apple documentation stating that you can only use the SE with the Data Protection Keychain in the user context is outdated (or wrong)? does the above work, but is not an approach sanctioned by Apple? Any feedback on this would be greatly appreciated.

弹出保存密码到iCloud钥匙串弹窗后立即退到后台再回到前台，搜索框无法弹出键盘

I am developing an Authorisation Plugin which talks to Launch daemons over XPC. Above is working neat, now I have to decide on how to get it installed on a machine. Installation requires. Plugin Installation Launch Daemon Installation Both require Moving binary and text (.plist) file into privileged system managed directory. Firing install/load commands as root (sudo). I have referred this post BSD Privilege Escalation on macOS, but I am still not clear how to approach this. Q: My requirement is: I can use .pkg builder and install via script, however I have some initialisation task that needs to be performed. User will enter some details talk to a remote server and get some keys, all goes well restarts the system and my authorisation plugin will welcome him and get him started. If I cannot perform initialisation I will have to do it post restart on login screen which I want to avoid if possible. I tried unconventional way of using AppleScript from a SwiftUI application to run privileged commands, I am fine if it prompts for admin credentials, but it did not work. I don't want that I do something and when approving it from Apple it gets rejected. Basically, how can I provide some GUI to do initialisation during installation or may be an app which helps in this. Q: Please also guide if I am doing elevated actions, how will it affect app distribution mechanism. In Read Me for EvenBetterAuthorizationSample I read it does. Thanks.

We are facing an issue with Keychain sharing across our apps after our Team ID was updated. Below are the steps we have already tried and the current observations: Steps we have performed so far: After our Team ID changed, we opened and re-saved all the provisioning profiles. We created a Keychain Access Group: xxxx.net.soti.mobicontrol (net.soti.mobicontrol is one bundle id of one of the app) and added it to the entitlements of all related apps. We are saving and reading certificates using this access group only. Below is a sample code snippet we are using for the query: [genericPasswordQuery setObject:(id)kSecClassGenericPassword forKey:(id)kSecClass]; [genericPasswordQuery setObject:identifier forKey:(id)kSecAttrGeneric]; [genericPasswordQuery setObject:accessGroup forKey:(id)kSecAttrAccessGroup]; [genericPasswordQuery setObject:(id)kSecMatchLimitOne forKey:(id)kSecMatchLimit]; [genericPasswordQuery setObject:(id)kCFBooleanTrue forKey:(id)kSecReturnAttributes]; Issues we are facing: Keychain items are not being shared consistently across apps. We receive different errors at different times: Sometimes errSecDuplicateItem (-25299), even when there is no item in the Keychain. Sometimes it works in a debug build but fails in Ad Hoc / TestFlight builds. The behavior is inconsistent and unpredictable. Expectation / Clarification Needed from Apple: Are we missing any additional configuration steps after the Team ID update? Is there a known issue with Keychain Access Groups not working correctly in certain build types (Debug vs AdHoc/TestFlight)? Guidance on why we are intermittently getting -25299 and how to properly reset/re-add items in the Keychain. Any additional entitlement / provisioning profile configuration that we should double-check. Request you to please raise a support ticket with Apple Developer Technical Support including the above details, so that we can get guidance on the correct setup and resolve this issue.

Problem Description: In our App, When we launch the web login part using ASWebAuthentication + Universal Links with callback scheme as "https", we are not receiving callback. Note: We are using "SwiftUIWebAuthentication" Swift Package Manager to display page in ASWebAuth. But when we use custom url scheme instead of Universal link, app able to receive call back every time. We use ".onOpenURL" to receive universal link callback scheme.

Hi, When calling generateAssertion on DCAppAttestService.shared, it gives invalidKey error when there was an update for an offloaded app. The offloading and reinstall always works fine if it is the same version on app store that was offloaded from device, but if there is an update and the app tries to reuse the keyID from previous installation for generateAssertion, attestation service rejects the key with error code 3 (invalid key) for a significant portion of our user. In our internal testing it failed for more than a third of the update attempts. STEPS TO REPRODUCE: install v1 from app store generate key using DCAppAttestService.shared.generateKey Attest this key using DCAppAttestService.shared.attestKey Send the attestation objection to our server and verify with apple servers Generate assertions for network calls to backend using DCAppAttestService.shared.generateAssertion with keyID from step 2 Device offloads the app (manually triggered by user, or automatically by iOS) A new version v2 is published to App Store Use tries to open the app Latest version is download from the App Store App tries to use the keyID from step 2 to generate assertions DCAppAttestService throws invalidKey error (Error Domain=com.apple.devicecheck.error Code=3) Step 7 is critical here, if there is no new version of the app, the reinstalled v1 can reuse the key from step 2 without any issues Is this behaviour expected? Is there any way we can make sure the key is preserved between offloaded app updates? Thanks

Hi everyone, I’d like to clarify something regarding the behavior of Team IDs after an app transfer between Apple Developer accounts. I have an app update that enforces a force update for all users. My plan is to release this update under the current developer account, and then proceed with transferring the app to a different developer account shortly afterward. My concern is: once the transfer is complete, will users who download the same app version (released before the transfer) be logged out due to a change in Team ID? Specifically, does the transferred app continue to use the original Team ID (used to sign the last submitted build), or does the Team ID change immediately upon transfer — affecting Keychain access? Any insights or confirmation on this would be greatly appreciated. Thanks!

Hello, I am currently working on iOS application development using Swift, targeting iOS 17 and above, and need to implement mTLS for network connections. In the registration API flow, the app generates a private key and CSR on the device, sends the CSR to the server (via the registration API), and receives back the signed client certificate (CRT) along with the intermediate/CA certificate. These certificates are then imported on the device. The challenge I am facing is pairing the received CRT with the previously generated private key in order to create a SecIdentity. Could you please suggest the correct approach to generate a SecIdentity in this scenario? If there are any sample code snippets, WWDC videos, or documentation references available, I would greatly appreciate it if you could share them. Thank you for your guidance.

Hi, when creating a CryptoTokenKit extension according to https://developer.apple.com/documentation/cryptotokenkit/authenticating-users-with-a-cryptographic-token, it is neccessary to register it under the securityagent in order to make the CTK usable before login. i.e. we want to run sudo -u _securityagent /Applications/HostApp.app/Contents/MacOS/HostApp However, even with the empty application the command fails with illegal hardware instruction sudo -u _securityagent /Applications/HostApp.app/Contents/MacOS/HostApp I see that it always crashes when the HostApp is sandboxed, but it does not work even without sandboxing (i am sharing the error report message below). i actually noticed that when the HostApp is sandboxed and I run the above command, the extension starts to be usable even before login, even though i see the HostApp crash. The same does not happen without the sandbox So I am curious how to in fact properly register the CTK extension under security agent? Also am not sure how to unregister it from the _securityagent thank you for your help Version: 1.0 (1) Code Type: X86-64 (Native) Parent Process: Exited process [9395] Responsible: Terminal [399] User ID: 92 Date/Time: 2025-03-21 18:54:03.0684 +0100 OS Version: macOS 15.3.2 (24D81) Report Version: 12 Bridge OS Version: 9.3 (22P3060) Anonymous UUID: 41F9918C-5BCA-01C7-59C2-3E8CFC3F8653 Sleep/Wake UUID: 8AB66C75-3C32-41D4-9BD4-887B0FB468FE Time Awake Since Boot: 4300 seconds Time Since Wake: 1369 seconds System Integrity Protection: enabled Crashed Thread: 0 Dispatch queue: WMClientWindowManager Exception Type: EXC_BAD_INSTRUCTION (SIGILL) Exception Codes: 0x0000000000000001, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4 Terminating Process: exc handler [9396] Application Specific Signatures: API Misuse Thread 0 Crashed:: Dispatch queue: WMClientWindowManager 0 libxpc.dylib 0x7ff80667b2bd _xpc_api_misuse + 113 1 libxpc.dylib 0x7ff80665f0e4 xpc_connection_set_target_uid + 187 2 WindowManagement 0x7ffd0b946693 -[WMClientWindowManager _createXPCConnection] + 1011 3 WindowManagement 0x7ffd0b947361 -[WMClientWindowManager _xpcConnection] + 65 4 WindowManagement 0x7ffd0b9447c9 __31-[WMClientWindowManager stages]_block_invoke + 41 5 libdispatch.dylib 0x7ff8067af7e2 _dispatch_client_callout + 8 6 libdispatch.dylib 0x7ff8067bca2c _dispatch_lane_barrier_sync_invoke_and_complete + 60 7 WindowManagement 0x7ffd0b9446fc -[WMClientWindowManager stages] + 268 8 AppKit 0x7ff80b1fd0b7 __54-[NSWMWindowCoordinator initializeStageFramesIfNeeded]_block_invoke + 30 9 libdispatch.dylib 0x7ff8067af7e2 _dispatch_client_callout + 8 10 libdispatch.dylib 0x7ff8067b0aa2 _dispatch_once_callout + 20 11 AppKit 0x7ff80b1fd060 -[NSWMWindowCoordinator initializeStageFramesIfNeeded] + 296 12 AppKit 0x7ff80a3b3701 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 888 13 AppKit 0x7ff80a3b2f77 -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1222 14 AppKit 0x7ff80a3b2aa9 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 42 15 SwiftUI 0x7ff917f321e0 0x7ff91776f000 + 8139232 16 SwiftUI 0x7ff917a8e2f2 0x7ff91776f000 + 3273458 17 SwiftUI 0x7ff917bccfba 0x7ff91776f000 + 4579258 18 SwiftUI 0x7ff917f2ca8e 0x7ff91776f000 + 8116878 19 SwiftUI 0x7ff917f24a65 0x7ff91776f000 + 8084069 20 SwiftUI 0x7ff917f21540 0x7ff91776f000 + 8070464 21 SwiftUI 0x7ff91849e9f1 0x7ff91776f000 + 13826545 22 SwiftUICore 0x7ffb13103ea5 0x7ffb12c81000 + 4730533 23 SwiftUICore 0x7ffb13102e0f 0x7ffb12c81000 + 4726287 24 SwiftUI 0x7ff91849e903 0x7ff91776f000 + 13826307 25 SwiftUI 0x7ff91849bc1c 0x7ff91776f000 + 13814812 26 AppKit 0x7ff80a54f191 -[NSApplication _doOpenUntitled] + 422 27 AppKit 0x7ff80a4efc59 __58-[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:]_block_invoke + 237 28 AppKit 0x7ff80a963818 __102-[NSApplication _reopenWindowsAsNecessaryIncludingRestorableState:withFullFidelity:completionHandler:]_block_invoke + 101 29 AppKit 0x7ff80a4ef6fa __97-[NSDocumentController(NSInternal) _autoreopenDocumentsIgnoringExpendable:withCompletionHandler:]_block_invoke_3 + 148 30 AppKit 0x7ff80a4eee8f -[NSDocumentController(NSInternal) _autoreopenDocumentsIgnoringExpendable:withCompletionHandler:] + 635 31 AppKit 0x7ff80a96373d -[NSApplication _reopenWindowsAsNecessaryIncludingRestorableState:withFullFidelity:completionHandler:] + 269 32 AppKit 0x7ff80a3a6259 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 529 33 AppKit 0x7ff80a3a5eb9 -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 679 34 Foundation 0x7ff807a4b471 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 307 35 Foundation 0x7ff807a4b285 _NSAppleEventManagerGenericHandler + 80 36 AE 0x7ff80e0e4e95 0x7ff80e0da000 + 44693 37 AE 0x7ff80e0e4723 0x7ff80e0da000 + 42787 38 AE 0x7ff80e0de028 aeProcessAppleEvent + 409 39 HIToolbox 0x7ff81217b836 AEProcessAppleEvent + 55 40 AppKit 0x7ff80a39ee6a _DPSNextEvent + 1725 41 AppKit 0x7ff80adf38b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1290 42 AppKit 0x7ff80a38faa9 -[NSApplication run] + 610 43 AppKit 0x7ff80a362d34 NSApplicationMain + 823 44 SwiftUI 0x7ff9177a7da1 0x7ff91776f000 + 232865 45 SwiftUI 0x7ff917af0d40 0x7ff91776f000 + 3677504 46 SwiftUI 0x7ff917d8fef8 0x7ff91776f000 + 6426360 47 Crescendo CryptoTokenKit 0x10b1baf6e static HostApp.$main() + 30 48 Crescendo CryptoTokenKit 0x10b1bd2f9 main + 9 (HostApp.swift:24) 49 dyld 0x7ff8065c82cd start + 1805

In some crashlog files, there are additional pieces of information related to codesigning. I can understand what most of themcorresponds to (ID, TeamID, Flags, Validation Category). But there is one I have some doubt about: Trust Level. As far as I can tell (or at least what Google and other search engines say), this is an unsigned 32 bit integer that defines the trust level with -1 being untrusted, 0, being basically an Apple executable and other potential bigger values corresponding to App Store binaries, Developer ID signature, etc. Yet, I'm not able to find a corresponding detailed documentation about this on Apple's developer website. I also had a look at the LightweightCodeRequirements "include" file and there does not seem to be such a field available. [Q] Is there any official documentation listing the different values for this trust level value and providing a clear description of what it corresponds to?

Attempting to DECRYPT a cipher message using the Apple API SecKeyCreateDecryptedData(privateKey, .rsaEncryptionOAEPSHA256, encryptedMessage). Decryption ALWAYS fails for every algorithm. SecKeyCreateDecryptedDataWithParameters Error: `Domain=NSOSStatusErrorDomain Code=-50 "algid:encrypt:RSA:OAEP:SHA256: algorithm not supported by the key &lt;SecKeyRef:('com.yubico.Authenticator.TokenExtension:5621CDF8560D4C412030886584EC4C9E394CC376DD9738B0CCBB51924FC26EB6') 0x3007fd150&gt;" UserInfo={numberOfErrorsDeep=0, NSDescription=algid:encrypt:RSA:OAEP:SHA256: algorithm not supported by the key &lt;SecKeyRef:('com.yubico.Authenticator.TokenExtension:5621CDF8560D4C412030886584EC4C9E394CC376DD9738B0CCBB51924FC26EB6') 0x3007fd150&gt;}` Decryption failed: SecKeyCreateDecryptedData returned nil. Error: One or more parameters passed to a function were not valid. When checking with SecKeyIsAlgorithmSupported(privateKey, .decrypt, &lt;ANYalgorithm&gt;) all algorithms fail. Btw - The privateKey does support decryption when retrieving the attributes. Important to know: The private key is a reference to an external private key placed in the iOS Keychain via a 3rd party CryptoTokenKit Extension app. When I perform, the SecKeyCreateSignature(...) and pass in the SAME privateKey reference, the OS automatically calls the 3rd party app to perform a successful signing with the private key that reside on a YubiKey. Here's my code for obtaining the private key reference from an Identity: func getKeyPairFromIdentity() -&gt; (privateKey: SecKey, publicKey: SecKey)? { let query = NSDictionary( dictionary: [ kSecClass as String: kSecClassIdentity, kSecAttrTokenID as String: self.tokenID!, kSecReturnRef as String: kCFBooleanTrue as Any ] ) var identityRef: CFTypeRef? let status = SecItemCopyMatching(query, &amp;identityRef) if status == errSecSuccess, let identity = identityRef { var privateKeyRef: SecKey? let keyStatus = SecIdentityCopyPrivateKey(identity as! SecIdentity, &amp;privateKeyRef) if keyStatus == errSecSuccess, let privateKey = privateKeyRef { let publicKey = SecKeyCopyPublicKey(privateKey) if let publicKey = publicKey { print("Private and public keys extracted successfully.") return (privateKey, publicKey) } else { print("Failed to extract public key from private key.") return nil } } else { print("SecIdentityCopyPrivateKey: Private key not found error: \(keyStatus)") return nil } } else { print("SecIdentity not found or error: \(status)") return nil } }

Hi everyone, I’ve been working on storing keys and passwords in the macOS Keychain using the Keychain Services API. Specifically, I’m leveraging SecAccessControlCreateWithFlags to bind items to access control flags, and overall, it’s been working smoothly. I have a question regarding the .applicationPassword flag of SecAccessControlCreateWithFlags. While it successfully prompts the user to input a password, there are no apparent password rules, even a simple “1” is accepted. My questions are: Is there a way to enforce strong password requirements when using the .applicationPassword flag? If enforcing strong passwords isn’t possible, is there an alternative approach to provide a predefined strong password during the creation process, bypassing the need for user input? With SecAccessControlCreateWithFlags, I noticed the item isn’t stored in the traditional file-based Keychain but in an iOS-style Keychain, is there a way to store it in a file-based Keychain while marking it as unexportable? I appreciate any insights or suggestions. Thank you! Neil

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

Hi, my app is receiving all keyboard events through Input Monitoring preference. It completely stopped to work on macOS 15 Sequoia and I have no idea why. Where can I read what has been changed in Input Monitoring? Thanks!