Binary code is associated with the NSUserTrackingUsageDescription deleted at present, but in the revised App privacy will contain NSUserTrackingUsageDescription, I feel very confused, don't know should shouldn't solve.

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!

Hello, I’m storing some values in the Keychain with the attribute ‘ksecattraccessibleafterfirstunlockthisdeviceonly’ (https://developer.apple.com/documentation/security/ksecattraccessibleafterfirstunlockthisdeviceonly). When I migrate user data between iPhones via iCloud, this behaves as expected and the keys are not preserved. However, when I migrate using a direct connection between two devices, the keys are preserved, which seems to contradict the attribute’s intent. Is this a known behavior, and if so, is there a workaround?

I'm writing an app on macOS that stores passwords in the Keychain and later retrieves them using SecItemCopyMatching(). This works fine 90% of the time. However, occasionally, the call to SecItemCopyMatching() fails with errSecAuthFailed (-25293). When this occurs, simply restarting the app resolves the issue; otherwise, it will consistently fail with errSecAuthFailed. What I suspect is that the Keychain access permission has a time limitation for a process. This issue always seems to arise when I keep my app running for an extended period.

Hi, I'm working on developing my own CryptoTokenKit (CTK) extension to enable codesign with HSM-backed keys. Here's what I’ve done so far: The container app sets up the tokenConfiguration with TKTokenKeychainCertificate and TKTokenKeychainKey. The extension registers successfully and is visible via pluginkit when launching the container app. The virtual smartcard appears when running security list-smartcards. The certificate, key, and identity are all visible using security export-smartcard -i [card]. However, nothing appears in the Keychain. After adding logging and reviewing output in the Console, I’ve observed the following behavior when running codesign: My TKTokenSession is instantiated correctly, using my custom TKToken implementation — so far, so good. However, none of the following TKTokenSession methods are ever called: func tokenSession(_ session: TKTokenSession, beginAuthFor operation: TKTokenOperation, constraint: Any) throws -> TKTokenAuthOperation func tokenSession(_ session: TKTokenSession, supports operation: TKTokenOperation, keyObjectID: TKToken.ObjectID, algorithm: TKTokenKeyAlgorithm) -> Bool func tokenSession(_ session: TKTokenSession, sign dataToSign: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data func tokenSession(_ session: TKTokenSession, decrypt ciphertext: Data, keyObjectID: Any, algorithm: TKTokenKeyAlgorithm) throws -> Data func tokenSession(_ session: TKTokenSession, performKeyExchange otherPartyPublicKeyData: Data, keyObjectID objectID: Any, algorithm: TKTokenKeyAlgorithm, parameters: TKTokenKeyExchangeParameters) throws -> Data The only relevant Console log is: default 11:31:15.453969+0200 PersistentToken [0x154d04850] invalidated because the client process (pid 4899) either cancelled the connection or exited There’s no crash report related to the extension, so my assumption is that ctkd is closing the connection for some unknown reason. Is there any way to debug this further? Thank you for your help.

Hi Apple Team and Community, We encountered a sudden and widespread failure related to the App Attest service on Friday, July 25, starting at around 9:22 AM UTC. After an extended investigation, our network engineers noted that the size of the attestation objects received from the attestKey call grew in size notably starting at that time. As a result, our firewall began blocking the requests from our app made to our servers with the Base64-encoded attestation objects in the payload, as these requests began triggering our firewall's max request length rule. Could Apple engineers please confirm whether there was any change rolled out by Apple at or around that time that would cause the attestation object size to increase? Can anyone else confirm seeing this? Any insights from Apple or others would be appreciated to ensure continued stability. Thanks!

I have a small command-line app I've been using for years to process files. I have it run by an Automator script, so that I can drop files onto it. It stopped working this morning. At first, I could still run the app from the command line, without Automator. But then after I recompiled the app, now I cannot even do that. When I run it, it's saying 'zsh: killed' followed by my app's path. What is that? The app does run if I run it from Xcode. How do I fix this?

We recently deployed Attestation on our application, and for a majority of the 40,000 users it works well. We have about six customers who are failing attestation. In digging through debug logs, we're seeing this error "iOS assertion verification failed. Unauthorized access attempted." We're assuming that the UUID is blocked somehow on Apple side but we're stumped as to why. We had a customer come in and we could look at the phone, and best we can tell it's just a generic phone with no jailbroken or any malicious apps. How can we determine if the UUID is blocked?

In iOS 18, i use CNContactPickerViewController to access to Contacts (i know it is one-time access). After first pick up one contact, the Setting > Apps > my app > Contacts shows Private Access without any option to close it. Is there any way to close it and undisplay it ? I tried to uninstall and reinstall my app, but it didn't work.

Hi Apple team, For our iPhone app (App Store build), a small subset of devices report DCAppAttestService.isSupported == false, preventing App Attest from being enabled. Approx. impact: 0.23% (352/153,791) iOS observed: Broadly 15.x–18.7 (also saw a few anomalous entries ios/26.0, likely client logging noise) Device models: Multiple generations (iPhone8–iPhone17); a few iPad7 entries present although the app targets iPhone Questions In iPhone main app context, what conditions can make isSupported return false on iOS 14+? Are there known device/iOS cases where temporary false can occur (SEP/TrustChain related)? Any recommended remediation (e.g., DFU restore)? Could you share logging guidance (Console.app subsystem/keywords) to investigate such cases? What fallback policy do you recommend when isSupported == false (e.g., SE-backed signature + DeviceCheck + risk rules), and any limitations? We can provide sysdiagnose/Console logs and more case details upon request. Thank you, —

WebAuthn Level 3 § 6.3.2 Step 2 states the authenticator must : Check if at least one of the specified combinations of PublicKeyCredentialType and cryptographic parameters in credTypesAndPubKeyAlgs is supported. If not, return an error code equivalent to "NotSupportedError" and terminate the operation. On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and an ES256 credential is created when an RP passes a non-empty sequence that does not contain {"type":"public-key","alg":-7} (e.g., [{"type":"public-key","alg":-8}]). When I use Chromium 138.0.7204.92 on my laptop running Arch Linux in conjunction with the Passwords app (connected via the "hybrid" protocol), a credential is not created and instead an error is reported per the spec.

Our background monitoring application uses a Unix executable that requests Screen Recording permission via CGRequestScreenCaptureAccess(). This worked correctly in macOS Tahoe 26.0.1, but broke in 26.1. Issue: After calling CGRequestScreenCaptureAccess() in macOS Tahoe 26.1: System dialog appears and opens System Settings Our executable does NOT appear in the Screen Recording list Manually adding via "+" button grants permission internally, but the executable still doesn't show in the UI Users cannot verify or revoke permissions Background: Unix executable runs as a background process (not from Terminal) Uses Accessibility APIs to retrieve window titles Same issue occurs with Full Disk Access permissions Environment: macOS Tahoe 26.1 (worked in 26.0.1) Background process (not launched from Terminal) Questions: Is this a bug or intentional design change in 26.1? What's the recommended approach for background executables to properly register with TCC? Are there specific requirements (Info.plist, etc.) needed? This significantly impacts user experience as they cannot manage permissions through the UI. Any guidance would be greatly appreciated. Thank you

The Core Problem After Users sign out from the App, the app isn’t properly retrieving the user on second sign in. Instead, it’s treating the user as “Unknown” and saving a new entry in CloudKit and locally. Is there a tutorial aside from 'Juice' that is recent and up to date?

I have something with a new individual on my team I've never seen before. They checked out our code repository from git and now anytime they try to open a .json file that is legitimately just a text file, GateKeeper tells them it cannot verify the integrity of this file and offers to have them throw this file away. I've seen this with binaries, and that makes sense. I removed the com.apple.quarantine extended attribute from all executable files in our source tree, but I've never seen GateKeeper prompt on text files. I could remove the extended attribute from all files in our source tree, but I fear the next time he pulls from git he'll get new ones flagged. Is there someway around this? I've never personally seen GateKeeper blocking text files.

Hello, I'm an application developer related to Apple system extensions. I developed an endpoint security system extension that can run normally before the 14.x system. However, after I upgraded to 15.x, I found that when I uninstalled and reinstalled my system extension, although the system extension was installed successfully, a system warning box would pop up when I clicked enable in the Settings, indicating a failure. I conducted the following test. I reinstalled a brand-new MAC 15.x system. When I installed my applications, the system extensions could be installed successfully and enabled normally. However, when I uninstalled and reinstalled, my system extension couldn't be enabled properly and a system warning popped up as well. I tried disabling SIP and enabling System Extension Developers, but it still didn't work. When the system warning box pops up, I can see some error log information through the console application, including an error related to Failed to authorize right 'com.apple.system-extensions.admin' by client '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] for authorization created by '/System/Library/ExtensionKit/Extensions/SettingsSystemExtensionController.appex' [2256] (3,0) (-60005) (engine 179) as shown in the screenshot. The same problem, mentioned in Cannot approve some extensions in MacOS Sequoia , but there is no solution

Hi Team, We are trying to understand deep sleep behaviour, can you please help us clarifying on the below questions: When will we configure Hibernate 25, is it valid for M series MacBooks? Is Hibernate 25 called deep sleep mode? What are the settings I need to do on Mac, to make my Mac go in to deep sleep? When awakening from deep sleep , what would be macOS system behaviour? If we have custom SFAuthorization plug in at system.login.screensaver, what would be the behaviour with deep sleep?

Can you please give me a hand with importing certificates under MacOS? I want to connect to Wi-Fi with 802.1X authentication (EAP-TLS) using a certificate that my homebrew application imported into my data protection keychain, but the imported certificate does not show up and I cannot select the certificate. It also does not show up in the Keychain Access app. One method I have tried is to import it into the data protection keychain by using the SecItemAdd function and setting kSecUseDataProtectionKeychain to true, but it does not work. Is there a better way to do this? ID: for id in identities { let identityParams: [String: Any] = [ kSecValueRef as String: id, kSecReturnPersistentRef as String: true, kSecUseDataProtectionKeychain as String: true ] let addIdentityStatus = SecItemAdd(identityParams as CFDictionary, nil) if addIdentityStatus == errSecSuccess { print("Successfully added the ID.: \(addIdentityStatus)") } else { print("Failed to add the ID.: \(addIdentityStatus)") } } Certificate: for cert in certificates { let certParams: [String: Any] = [ kSecValueRef as String: cert, kSecReturnPersistentRef as String: true, kSecUseDataProtectionKeychain as String: true ] let addCertStatus = SecItemAdd(certParams as CFDictionary, nil) if addCertStatus == errSecSuccess { print("Successfully added the certificate.: (\(addCertStatus))") } else { print("Failed to add the certificate.: (\(addCertStatus))") } } Private key: for privateKey in keys { let keyTag = UUID().uuidString.data(using: .utf8)! let keyParams: [String: Any] = [ kSecAttrApplicationTag as String: keyTag, kSecValueRef as String: privateKey, kSecReturnPersistentRef as String: true, kSecUseDataProtectionKeychain as String: true ] let addKeyStatus = SecItemAdd(keyParams as CFDictionary, nil) if addKeyStatus == errSecSuccess { print("Successfully added the private key.: \(addKeyStatus)") } else { print("Failed to add the private key.: \(addKeyStatus)") } }

I am using the CryptoKit SecureEnclave enum to generate Secure Enclave keys. I've got a couple of questions: What is the lifetime of these keys? When I don't store them somewhere, how does the Secure Enclave know they are gone? Do backups impact these keys? I.e. can I lose access to the key when I restore a backup? Do these keys count to the total storage capacity of the Secure Enclave? If I recall correctly, the Secure Enclave has a limited storage capacity. Do the SecureEnclave key instances count towards this storage capacity? What is the dataRepresentation and how can I use this? I'd like to store the Secure Enclave (preferably not in the Keychain due to its limitations). Is it "okay" to store this elsewhere, for instance in a file or in the UserDefaults? Can the dataRepresentation be used in other apps? If I had the capability of extracting the dataRepresentation as an attacker, could I then rebuild that key in my malicious app, as the key can be rebuilt with the Secure Enclave on the same device, or are there measures in place to prevent this (sandbox, bundle id, etc.)

Having trouble decrypting a string using an encryption key and an IV. var key: String var iv: String func decryptData(_ encryptedText: String) -> String? { if let textData = Data(base64Encoded: iv + encryptedText) { do { let sealedBox = try AES.GCM.SealedBox(combined: textData) let key = SymmetricKey(data: key.data(using: .utf8)!) let decryptedData = try AES.GCM.open(sealedBox, using: key) return String(data: decryptedData, encoding: .utf8) } catch { print("Decryption failed: \(error)") return nil } } return nil } Proper coding choices aside (I'm just trying anything at this point,) the main problem is opening the SealedBox. If I go to an online decryption site, I can paste in my encrypted text, the encryption key, and the IV as plain text and I can encrypt and decrypt just fine. But I can't seem to get the right combo in my Swift code. I don't have a "tag" even though I'm using the combined option. How can I make this work when all I will be receiving is the encrypted text, the encryption key, and the IV. (the encryption key is 256 bits) Try an AES site with a key of 32 digits and an IV of 16 digits and text of your choice. Use the encrypted version of the text and then the key and IV in my code and you'll see the problem. I can make the SealedBox but I can't open it to get the decrypted data. So I'm not combining the right things the right way. Anyone notice the problem?

There’s a critical, actively exploited vulnerability in Apple’s iOS activation servers allowing unauthenticated XML payload injection: https://cyberpress.org/apple-ios-activation-vulnerability/ This flaw targets the core activation process, bypassing normal security checks. Despite the severity, it’s barely discussed in public security channels. Why is this not being addressed or publicly acknowledged? Apple developers and security researchers should urgently review and audit activation flows—this is a direct attack vector on device trust integrity. Any insights or official response appreciated.