I'm trying to setup device attestation. I believe I have everything setup correctly but the final step of signature validation never succeeds. I've added validation on the client side for debugging and it doesn't validate using CryptoKit. After the assertion is created, I try to validate it: assertion = try await DCAppAttestService.shared.generateAssertion(keyId, clientDataHash: clientDataHash) await validateAssertionLocallyForDebugging(keyId: keyId, assertionObject: assertion, clientDataHash: clientDataHash) In the validateAssertionLocallyForDebugging method, I extract all the data from the CBOR assertionObject and then setup the parameters to validate the signature, using the key that was created from the original attestation flow, but it fails every time. I'm getting the public key from the server using a temporary debugging API. let publicKeyData = Data(base64Encoded: publicKeyB64)! let p256PublicKey = try P256.Signing.PublicKey(derRepresentation: publicKeyData) let ecdsaSignature = try P256.Signing.ECDSASignature(derRepresentation: signature) let digestToVerify = SHA256.hash(data: authenticatorData + clientDataHash) print(" - Recreated Digest to Verify: \(Data(digestToVerify).hexDescription)") if p256PublicKey.isValidSignature(ecdsaSignature, for: digestToVerify) { print("[DEBUG] SUCCESS: Local signature validation passed!") } else { print("[DEBUG] FAILED: Local signature validation failed.") } I have checked my .entitlements file and it is set to development. I have checked the keyId and verified the public key. I have verified the public key X,Y, the RP ID Hash, COSE data, and pretty much anything else I could think of. I've also tried using Gemini and Claude to debug this and that just sends me in circles of trying hashed, unhashed, and double hashed clientData. I'm doing this from Xcode on an M3 macbook air to an iPhone 16 Pro Max. Do you have any ideas on why the signature is not validating with everything else appears to be working? Thanks

I am developing a macOS system service (standalone binary running as a LaunchDaemon) that requires the ability to sign data using a private key which will be deployed via MDM. The Setup: Deployment: A .mobileconfig pushes a PKCS12 identity to the System Keychain. Security Requirement: For compliance and security reasons, we cannot set AllowAllAppsAccess to <true/>. The key must remain restricted. The Goal: I need to use the private key from the identity to be able to sign the data The Problem: The Certificate Payload does not support a TrustedApplications or AccessControl array to pre-authorize binary paths. As a result, when the process tries to use the private key for signing (SecKeyCreateSignature), it prompts the user to allow this operation which creates a disruption and is not desired. What i've tried so far: Manually adding my process to the key's ACL in keychain access obviously works and prevents any prompts but this is not an "automatable" solution. Using security tool in a script to attempt to modify the ACL in an automated way, but that also asks user for password and is not seamless. The Question: Is there a documented, MDM-compatible way to inject a specific binary path into the ACL of a private key? If not, is there a better way to achieve the end goal?

Hello Team, We’ve recently started receiving reports from our customer base (Trellix) regarding issues with Full Disk Access (FDA) for Trellix binaries on macOS devices running Tahoe 26.1 (released on November 3, 2025). The issue occurs when users attempt to add Trellix CLI binaries under FDA to grant the required permissions; the binaries fail to appear under the FDA settings, even after selection. Upon further investigation, this appears to be a macOS 26.1–specific issue and not observed in earlier versions. Similar reports have been noted across various forums, indicating that the issue affects multiple binaries, not just Trellix: Some of the discussions on the same issue I see online. https://developer.apple.com/forums/thread/806187 https://developer.apple.com/forums/thread/806156 https://forum.logik.tv/t/macos-26-1-installation-issue-wait-before-updating/13761 https://www.reddit.com/r/MacOS/comments/1os1ph3/cant_add_anything_to_privacy_security_full_disk/ I have also logged FB21009024 for the same. We would like to understand when we can expect this to be fixed, since the issue persists even in 26.2 Beta and also whether the workaround of dragging and dropping the binaries can still be suggested?

I'm working on integrating Passkey functionality into my iOS app (targeting iOS 16.0+), and I'm facing an issue where the system dialog still shows the "Save to another device" option during Passkey registration. I want to hide this option to force users to create Passkeys only on the current device. 1. My Current Registration Implementation Here’s the code I’m using to create a Passkey registration request. I’ve tried to use ASAuthorizationPlatformPublicKeyCredentialProvider (which is supposed to target platform authenticators like Face ID/Touch ID), but the "Save to another device" option still appears: `// Initialize provider for platform authenticators let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(relyingPartyIdentifier: domain) // Create registration request let registrationRequest = provider.createCredentialRegistrationRequest( challenge: challenge, name: username, userID: userId ) // Optional configurations (tried these but no effect on "another device" option) registrationRequest.displayName = "Test Device" registrationRequest.userVerificationPreference = .required registrationRequest.attestationPreference = .none // Set up authorization controller let authController = ASAuthorizationController(authorizationRequests: [registrationRequest]) let delegate = PasskeyRegistrationDelegate(completion: completion) authController.delegate = delegate // Trigger the registration flow authController.performRequests(options: .preferImmediatelyAvailableCredentials)` 2. Observation from Authentication Flow (Working as Expected) During the Passkey authentication flow (not registration), I can successfully hide the "Use another device" option by specifying allowedCredentials in the ASAuthorizationPlatformPublicKeyCredentialAssertionRequest. Here’s a simplified example of that working code: let assertionRequest = provider.createCredentialAssertionRequest(challenge: challenge) assertionRequest.allowedCredentials = allowedCredentials After adding allowedCredentials, the system dialog no longer shows cross-device options—this is exactly the behavior I want for registration. 3. My Questions Is there a similar parameter to allowedCredentials (from authentication) that I can use during registration to hide the "Save to another device" option? Did I miss any configuration in the registration request (e.g., authenticatorAttachment or other properties) that forces the flow to use only the current device’s platform authenticator? Are there any system-level constraints or WebAuthn standards I’m overlooking that cause the "Save to another device" option to persist during registration? Any insights or code examples would be greatly appreciated!

Hello everyone, In my application, i have implemented authentication using ASWebauthenticationSession. However, when redirecting the user to a WKWebView, no cookies are shared, causing the session to be lost and requiring the user to log in again. Is there a way to share cookies between the two? If not, what would be the best approach to set up authentication that ensures SSO when switching to a WebView ? Thank you very much for your help !

Hello, I am currently implementing a biometric authentication registration flow using WebAuthn. I am using ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest, and I would like to know if there is a way to hide the "Save to another device" option that appears during the registration process. Specifically, I want to guide users to save the passkey only locally on their device, without prompting them to save it to iCloud Keychain or another device. If there is a way to hide this option or if there is a recommended approach to achieve this, I would greatly appreciate your guidance. Also, if this is not possible due to iOS version or API limitations, I would be grateful if you could share any best practices for limiting user options in this scenario. If anyone has experienced a similar issue, your advice would be very helpful. Thank you in advance.

WebAuthn Level 3 § 5.1.3 Step 22 Item 4 states the steps a user agent MUST follow when "conditional" mediation is used in conjunction with required user verification: Let userVerification be the effective user verification requirement for credential creation, a Boolean value, as follows. If pkOptions.authenticatorSelection.userVerification is set to required If options.mediation is set to conditional and user verification cannot be collected during the ceremony, throw a ConstraintError DOMException. Let userVerification be true. On my iPhone 15 Pro Max running iOS 18.5, Safari + Passwords does not exhibit this behavior; instead an error is not reported and user verification is not performed (i.e., the UV bit is 0). Per the spec this results in a registration ceremony failure on the server which is made all the more "annoying" since the credential was created in Passwords forcing a user to then delete the credential. : If the Relying Party requires user verification for this registration, verify that the UV bit of the flags in authData is set. In contrast when I use Google Password Manager + Chrome on a Samsung Galaxy S24 running Android 15, user verification is enforced and the UV bit is 1. Either the UV bit should be 1 after enforcing user verification or an error should be thrown since user verification cannot be performed.

I'm trying to use ASWebAuthenticationSession on macOS but there is a weird crash and I have no idea what to do. It looks like there is a main thread check in a framework code that I have no control over. Any help would be appreciated. Thank you in advance. The stack of crashed thread has no symbols, even for supposedly my code in OAuthClient.authenticate. macOS 15.4.1 (24E263) Xcode Version 16.3 (16E140) Thread 11: EXC_BREAKPOINT (code=1, subcode=0x10039bb04) Thread 12 Queue : com.apple.NSXPCConnection.m-user.com.apple.SafariLaunchAgent (serial) #0 0x0000000100b17b04 in _dispatch_assert_queue_fail () #1 0x0000000100b52834 in dispatch_assert_queue$V2.cold.1 () #2 0x0000000100b17a88 in dispatch_assert_queue () #3 0x000000027db5f3e8 in swift_task_isCurrentExecutorWithFlagsImpl () #4 0x00000001022c7754 in closure #1 in closure #1 in OAuthClient.authenticate() () #5 0x00000001022d0c98 in thunk for @escaping @callee_guaranteed (@in_guaranteed URL?, @guaranteed Error?) -&gt; () () #6 0x00000001c7215a34 in __102-[ASWebAuthenticationSession initWithURL:callback:usingEphemeralSession:jitEnabled:completionHandler:]_block_invoke () #7 0x00000001c72163d0 in -[ASWebAuthenticationSession _endSessionWithCallbackURL:error:] () #8 0x00000001c7215fc0 in __43-[ASWebAuthenticationSession _startDryRun:]_block_invoke_2 () #9 0x0000000194e315f4 in __invoking___ () #10 0x0000000194e31484 in -[NSInvocation invoke] () #11 0x00000001960fd644 in __NSXPCCONNECTION_IS_CALLING_OUT_TO_REPLY_BLOCK__ () #12 0x00000001960fbe40 in -[NSXPCConnection _decodeAndInvokeReplyBlockWithEvent:sequence:replyInfo:] () #13 0x00000001960fb798 in __88-[NSXPCConnection _sendInvocation:orArguments:count:methodSignature:selector:withProxy:]_block_invoke_3 () #14 0x0000000194a6ef18 in _xpc_connection_reply_callout () #15 0x0000000194a6ee08 in _xpc_connection_call_reply_async () #16 0x0000000100b3130c in _dispatch_client_callout3_a () #17 0x0000000100b362f8 in _dispatch_mach_msg_async_reply_invoke () #18 0x0000000100b1d3a8 in _dispatch_lane_serial_drain () #19 0x0000000100b1e46c in _dispatch_lane_invoke () #20 0x0000000100b2bfbc in _dispatch_root_queue_drain_deferred_wlh () #21 0x0000000100b2b414 in _dispatch_workloop_worker_thread () #22 0x0000000100c0379c in _pthread_wqthread () My code: @MainActor func authenticate() async throws { let authURL = api.authorizationURL( scopes: scopes, state: state, redirectURI: redirectURI ) let authorizationCodeURL: URL = try await withUnsafeThrowingContinuation { c in let session = ASWebAuthenticationSession(url: authURL, callback: .customScheme(redirectScheme)) { url, error in guard let url = url else { c.resume(throwing: error ?? Error.unknownError("Failed to get authorization code")) return } c.resume(returning: url) } session.presentationContextProvider = presentationContextProvider session.start() } let authorizationCode = try codeFromAuthorizationURL(authorizationCodeURL) (storedAccessToken, storedRefreshToken) = try await getTokens(authorizationCode: authorizationCode) } Here is disassembly of the crashed function. libdispatch.dylib`_dispatch_assert_queue_fail: 0x10067fa8c &lt;+0&gt;: pacibsp 0x10067fa90 &lt;+4&gt;: sub sp, sp, #0x50 0x10067fa94 &lt;+8&gt;: stp x20, x19, [sp, #0x30] 0x10067fa98 &lt;+12&gt;: stp x29, x30, [sp, #0x40] 0x10067fa9c &lt;+16&gt;: add x29, sp, #0x40 0x10067faa0 &lt;+20&gt;: adrp x8, 71 0x10067faa4 &lt;+24&gt;: add x8, x8, #0x951 ; "not " 0x10067faa8 &lt;+28&gt;: adrp x9, 70 0x10067faac &lt;+32&gt;: add x9, x9, #0x16b ; "" 0x10067fab0 &lt;+36&gt;: stur xzr, [x29, #-0x18] 0x10067fab4 &lt;+40&gt;: cmp w1, #0x0 0x10067fab8 &lt;+44&gt;: csel x8, x9, x8, ne 0x10067fabc &lt;+48&gt;: ldr x10, [x0, #0x48] 0x10067fac0 &lt;+52&gt;: cmp x10, #0x0 0x10067fac4 &lt;+56&gt;: csel x9, x9, x10, eq 0x10067fac8 &lt;+60&gt;: stp x9, x0, [sp, #0x10] 0x10067facc &lt;+64&gt;: adrp x9, 71 0x10067fad0 &lt;+68&gt;: add x9, x9, #0x920 ; "BUG IN CLIENT OF LIBDISPATCH: Assertion failed: " 0x10067fad4 &lt;+72&gt;: stp x9, x8, [sp] 0x10067fad8 &lt;+76&gt;: adrp x1, 71 0x10067fadc &lt;+80&gt;: add x1, x1, #0x8eb ; "%sBlock was %sexpected to execute on queue [%s (%p)]" 0x10067fae0 &lt;+84&gt;: sub x0, x29, #0x18 0x10067fae4 &lt;+88&gt;: bl 0x1006c258c ; symbol stub for: asprintf 0x10067fae8 &lt;+92&gt;: ldur x19, [x29, #-0x18] 0x10067faec &lt;+96&gt;: str x19, [sp] 0x10067faf0 &lt;+100&gt;: adrp x0, 71 0x10067faf4 &lt;+104&gt;: add x0, x0, #0x956 ; "%s" 0x10067faf8 &lt;+108&gt;: bl 0x1006b7b64 ; _dispatch_log 0x10067fafc &lt;+112&gt;: adrp x8, 108 0x10067fb00 &lt;+116&gt;: str x19, [x8, #0x2a8] -&gt; 0x10067fb04 &lt;+120&gt;: brk #0x1

The header documentation for the (deprecated) LAContext.evaluatedPolicyDomainState property contains the following: @warning Please note that the value returned by this property can change exceptionally between major OS versions even if the state of biometry has not changed. I noticed that the documentation for the new LAContext.domainState property does not contain a similar warning. I also found this related thread from 2016/17. Is the domainState property not susceptible to changes between major OS versions? Or is this generally not an issue anymore?

We use Jamf Blueprint to deploy the managed app and identity to the iOS device (iOS 26.3 installed). Our managed app can access the identity via let identityProvider = ManagedAppIdentitiesProvider() let identity: SecIdentity do { identity = try await identityProvider.identity(withIdentifier: "myIdentity") } catch { } However, the app extension cannot access the same identity. Our app extension is notification extension that implemented UNNotificationServiceExtension APIs. We use above code in didReceive() function to access identity that always failed. The MDM configuration payload is: "AppConfig": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] }, "ExtensionConfigs": { "Identifier (com.example.myapp.extension)": { "Identities": [ { "Identifier": "myIdentity", "AssetReference": "$PAYLOAD_2" } ] } }, "ManifestURL": "https://example.net/manifest.plist", "InstallBehavior": { "Install": "Required" } } Is there any problem in our MDM configuration? Or the notification extension cannot integrate with ManagedApp FM?

I’m considering storing some sensitive information in the userID field of a passkey, as described in the createCredentialRegistrationRequest method.(link to method). I'm aware of the largeBlob extension introduced in iOS 17+, but it doesn't meet my needs since I want to create a cross-platform passkey that can be used across various devices — and currently, not many devices support the largeBlob extension. According to W3C documentation, the userID field is not considered private information and can be displayed to the user without requiring a verification process. Based on my understanding, it's also not encrypted, which means it might be accessible with physical access to the device. So here are my questions: How do Apple devices (especially iPhones) handle the userID field in their authenticators? Is it possible to access the userID without user verification, as permitted by the W3C specification? Are there any alternative methods to access the userID value stored in a passkey on Apple devices?

Hello, I'm seeking some clarification regarding the use of accessibility and input monitoring APIs in sandboxed apps that are distributed through the App Store. I understand that accessibility permissions are generally restricted for App Store apps. However, I've seen several recently released apps request these permissions directly upon first launch. I'm aware that apps submitted prior to 2012 may have legacy access to certain APIs, but the ones I'm referring to appear to be recent - within the past year. While it's possible these apps were approved despite the restrictions, I want to make sure I'm not overlooking something. I also came across a recent discussion on this topic, and one post in particular stood out: Link I’d really appreciate some clarification on what's officially allowed. Specifically: Are accessibility permissions ever allowed? If so, under what circumstances? Is input monitoring permitted for apps on the App Store? (The referenced post says yes, but since it's from 2022, I just want to confirm) The linked post suggests that event generation might be allowed on the App Store, though the author hadn’t explored that privilege in detail and recommended opening a DTS tech support incident. I’ve done that and have a support case open - would it be possible to take a closer look at this? For context, my app (currently distributed outside the App Store) uses CGEventPost and CGEventCreateMouseEvent to modify mouse behavior. Thank you

Hi everyone, I’m working an Objective-C lib that performs Keychain operations, such as generating cryptographic keys and signing data. The lib will be used by my team in a Java program for macOS via JNI. When working with the traditional file-based Keychain (i.e., without access control flags), everything works smoothly, no issues at all. However, as soon as I try to generate a key using access control flags SecAccessControlCreateWithFlags, the Data Protection Keychain returns error -34018 (errSecMissingEntitlement) during SecKeyCreateRandomKey. This behavior is expected. To address this, I attempted to codesign my native dynamic library (.dylib) with an entitlement plist specifying various combinations of: keychain-access-groups com.apple.security.keychain etc. with: My Apple Development certificate Developer ID Application certificate Apple Distribution certificate None of these combinations made a difference, the error persists. I’d love to clarify: Is it supported to access Data Protection Keychain / Secure Enclave Keys in this type of use case? If so, what exact entitlements does macOS expect when calling SecKeyCreateRandomKey from a native library? I’d really appreciate any guidance or clarification. Thanks in advance! Best regards, Neil

Hello Experts, I am in need of your help with this feedback from the App Reviewer. Issue Description: One or more purpose strings in the app do not sufficiently explain the use of protected resources. Purpose strings must clearly and completely describe the app's use of data and, in most cases, provide an example of how the data will be used. Next Steps: Update the location purpose string to explain how the app will use the requested information and provide a specific example of how the data will be used. See the attached screenshot. Resources: Purpose strings must clearly describe how an app uses the ability, data, or resource. The following are hypothetical examples of unclear purpose strings that would not pass review: "App would like to access your Contacts" "App needs microphone access" Feedback #2 "Regarding 5.1.1, we understand why your app needs access to location. However, the permission request alert does not sufficiently explain this to your users before accessing the location. To resolve this issue, it would be appropriate to revise the location permission request, specify why your app needs access, and provide an example of how your app will use the user's data. To learn more about purpose string requirements, watch a video from App Review with tips for writing clear purpose strings. We look forward to reviewing your app once the appropriate changes have been made." May I know how can I update my purpose string? I appealed on the first feedback by explaining what is the purpose of it but got the Feedback #2. TYIA!!

I’m having an issue with my Credential Provider Extension for passkey registration. On the browser I click on registration, in IOS i can select my App for passkey registration with a continue button. Wenn I click the continue button the prepareInterface(forPasskeyRegistration:) function is called but the MainInterface is not shown —it only appears when I click the continue button a second time. Here’s a simplified version of my prepareInterface method: override func prepareInterface(forPasskeyRegistration registrationRequest: ASCredentialRequest) { guard let request = registrationRequest as? ASPasskeyCredentialRequest, let identity = request.credentialIdentity as? ASPasskeyCredentialIdentity else { extensionContext.cancelRequest(withError: ASExtensionError(.failed)) return } self.identity = identity self.request = request log.info("prepareInterface called successfully") } In viewDidAppear, I trigger FaceID authentication and complete the registration process if register is true. However, the UI only shows after a second “Continue” tap. Has anyone encountered this behavior or have suggestions on how to ensure the UI appears immediately after prepareInterface is called? Could it be a timing or lifecycle issue with the extension context? Thanks for any insights!

I'm trying to confirm the correct URL for Apple Attest development. There seems to be a fraud metric risk section that uses this: https://data-development.appattest.apple.com/v1/attestationData However the key verification seems to use this: https://data-development.appattest.apple.com/v1/attestation Currently I'm attempting to verify the key, so the second one seems likely. However I keep receiving a 404 despite vigorous validation of all fields included in the JSON as well as headers. Can anyone confirm please, which URL I should be sending my AppleAttestationRequest to?

I've contacted Apple support about this topic, and they've directed me to this forum. I regularly perform Pentests of iOS applications. To properly assess the security of iOS apps, I must bypass given security precaution taken by our customers, such as certificate pinning. According to a number of blog articles, this appears to only be viable on jailbroken devices. If a target application requires a modern version of iOS, the security assessment can't be properly performed. As it should be in Apple's best interest, to offer secure applications on the App Store, what's the recommended approach to allow intrusive pentesting of iOS apps?

Hello, I am developing a macOS menu bar window-management utility (similar in functionality to Magnet / Rectangle) that relies on the Accessibility (AXUIElement) API to move and resize windows and on global hotkeys. I am facing a consistent issue when App Sandbox is enabled. Summary: App Sandbox enabled Hardened Runtime enabled Apple Events entitlement enabled NSAccessibilityDescription present in Info.plist AXIsProcessTrustedWithOptions is called with prompt enabled Observed behavior: When App Sandbox is enabled, the Accessibility permission prompt never appears. The app cannot be manually added in System Settings → Privacy & Security → Accessibility. AXIsProcessTrusted always returns false. As a result, window snapping does not work. When App Sandbox is disabled: The Accessibility prompt appears correctly. The app functions as expected. This behavior occurs both: In local builds In TestFlight builds My questions: Is this expected behavior for sandboxed macOS apps that rely on Accessibility APIs? Are window-management utilities expected to ship without App Sandbox enabled? Is there any supported entitlement or configuration that allows a sandboxed app to request Accessibility permission? Thank you for any clarification.

Our business model is to identify Frauds using our advanced AI/ML model. However, in order to do so we need to collect many device information which seems to be ok according to https://developer.apple.com/app-store/user-privacy-and-data-use/ But it's also prohibited to generate a fingerprint, so I need more clarification here. Does it mean I can only use the data to identify that a user if either fraud or not but I cannot generate a fingerprint to identify the device? If so, I can see many SKD in the market that generates Fingerprints like https://fingerprint.com/blog/local-device-fingerprint-ios/ and https://shield.com/?

Please correct the following issues and upload a new binary to App Store Connect. ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/FirebaseCoreDiagnostics.framework/FirebaseCoreDiagnostics”, which includes FirebaseCoreDiagnostics, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/FBLPromises.framework/FBLPromises”, which includes FBLPromises, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. ITMS-91061: Missing privacy manifest - Your app includes “Frameworks/GoogleDataTransport.framework/GoogleDataTransport”, which includes GoogleDataTransport, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. our app is .NET MAUI app so we already addressed this by adding privacyinfo.xcprivacy privacy manifest under platform/ios/resources but still get flagged for this <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>NSPrivacyTracking</key> <false/> <key>NSPrivacyTrackingDomains</key> <array/> <key>NSPrivacyAccessedAPITypes</key> <array> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryFileTimestamp</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>C617.1</string> </array> </dict> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategorySystemBootTime</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>35F9.1</string> </array> </dict> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryDiskSpace</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>E174.1</string> </array> </dict> <dict> <key>NSPrivacyAccessedAPIType</key> <string>NSPrivacyAccessedAPICategoryUserDefaults</string> <key>NSPrivacyAccessedAPITypeReasons</key> <array> <string>CA92.1</string> </array> </dict> </array> <key>NSPrivacyCollectedDataTypes</key> <array/> </dict> </plist>