Is there a way (in code or on the OAuth2 server/webpage) to specify the desired window size when using ASWebAuthenticationSession on macOS? I haven't found anything, and we would prefer the window to be narrower. For one of our users, the window is even stretched to the full screen width which looks completely broken…

Hi everyone, I'm working on an app that stores multiple secrets in the Keychain, each protected with .userPresence. My goal is to authenticate the user once via FaceID/TouchID and then read multiple Keychain items without triggering subsequent prompts. I am reusing the same LAContext instance for these operations, and I have set: context.touchIDAuthenticationAllowableReuseDuration = LATouchIDAuthenticationMaximumAllowableReuseDuration However, I'm observing that every single SecItemCopyMatching call triggers a new FaceID/TouchID prompt, even if they happen within seconds of each other using the exact same context. Here is a simplified flow of what I'm doing: Create a LAContext. Set touchIDAuthenticationAllowableReuseDuration to max. Perform a query (SecItemCopyMatching) for Item A, passing [kSecUseAuthenticationContext: context]. Result: System prompts for FaceID. Success. Immediately perform a query (SecItemCopyMatching) for Item B, passing the same [kSecUseAuthenticationContext: context]. Result: System prompts for FaceID again. My question is: Does the .userPresence access control flag inherently force a new user interaction for every Keychain access, regardless of the LAContext reuse duration? Is allowableReuseDuration only applicable for LAContext.evaluatePolicy calls and not for SecItem queries? If so, is there a recommended pattern for "unlocking" a group of Keychain items with a single biometric prompt? Environment: iOS 17+, Swift. Thanks!

I can't find any information about why this is happening, nor can I reproduce the 'successful' state on this device. My team needs to understand this behavior, so any insight would be greatly appreciated! The expected behavior: If I delete both apps and reinstall them, attempting to open the second app from my app should trigger the system confirmation dialog. The specifics: I'm using the MSAL library. It navigates the user to the Microsoft Authenticator app and then returns to my app. However, even after resetting the phone and reinstalling both apps, the dialog never shows up (it just opens the app directly). Does anyone know the logic behind how iOS handles these prompts or why it might be persistent even after a reset? Thanks in advance!

There is a sudden surge of users in our apps with invalidated biometrics. Even though the issue is being handled correctly and the user has another way to login, some of the users forgot their passwords and they can not login. Is there any known issue with Biometrics in iOS 18.3.2 or later? There is a (possible) related discussion here: https://discussions.apple.com/thread/256011565

We are using Apple's PSSO to federate device login to out own IdP. We have developed our own extension app and deployed it using MDM. Things works fine but there are 2 issues that we are trying to get to the root cause - On some devices after restarting we see an error message on the logic screen saying "The registration for this device is invalid and must be repaired" And other error message is "SmartCard configuration is invalid for this account" For the 1st we have figured out that this happens when the registration doesn't happen fully and the key is not tied to the user so when the disk needs to be decrypted at the FileVault screen the issue is raised. For the "SmartCard configuration is invalid for this account" issue also one aspect is invalid registration but there has been other instances as well where the devices were registered completely but then also the the above error was raised. We verified the registration being completed by checking if the SmartCard is visible in the System Report containing the key. Has anyone seen the above issues and any possible resolution around it?

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?) -> () () #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 <+0>: pacibsp 0x10067fa90 <+4>: sub sp, sp, #0x50 0x10067fa94 <+8>: stp x20, x19, [sp, #0x30] 0x10067fa98 <+12>: stp x29, x30, [sp, #0x40] 0x10067fa9c <+16>: add x29, sp, #0x40 0x10067faa0 <+20>: adrp x8, 71 0x10067faa4 <+24>: add x8, x8, #0x951 ; "not " 0x10067faa8 <+28>: adrp x9, 70 0x10067faac <+32>: add x9, x9, #0x16b ; "" 0x10067fab0 <+36>: stur xzr, [x29, #-0x18] 0x10067fab4 <+40>: cmp w1, #0x0 0x10067fab8 <+44>: csel x8, x9, x8, ne 0x10067fabc <+48>: ldr x10, [x0, #0x48] 0x10067fac0 <+52>: cmp x10, #0x0 0x10067fac4 <+56>: csel x9, x9, x10, eq 0x10067fac8 <+60>: stp x9, x0, [sp, #0x10] 0x10067facc <+64>: adrp x9, 71 0x10067fad0 <+68>: add x9, x9, #0x920 ; "BUG IN CLIENT OF LIBDISPATCH: Assertion failed: " 0x10067fad4 <+72>: stp x9, x8, [sp] 0x10067fad8 <+76>: adrp x1, 71 0x10067fadc <+80>: add x1, x1, #0x8eb ; "%sBlock was %sexpected to execute on queue [%s (%p)]" 0x10067fae0 <+84>: sub x0, x29, #0x18 0x10067fae4 <+88>: bl 0x1006c258c ; symbol stub for: asprintf 0x10067fae8 <+92>: ldur x19, [x29, #-0x18] 0x10067faec <+96>: str x19, [sp] 0x10067faf0 <+100>: adrp x0, 71 0x10067faf4 <+104>: add x0, x0, #0x956 ; "%s" 0x10067faf8 <+108>: bl 0x1006b7b64 ; _dispatch_log 0x10067fafc <+112>: adrp x8, 108 0x10067fb00 <+116>: str x19, [x8, #0x2a8] -> 0x10067fb04 <+120>: brk #0x1

I regularly see folks confused by the difference in behaviour of app groups between macOS and iOS. There have been substantial changes in this space recently. While much of this is now covered in the official docs (r. 92322409), I’ve updated this post to go into all the gory details. If you have questions or comments, start a new thread with the details. Put it in the App & System Services > Core OS topic area and tag it with Code Signing and Entitlements. Oh, and if your question is about app group containers, also include Files and Storage. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" App Groups: macOS vs iOS: Working Towards Harmony There are two styles of app group ID: iOS-style app group IDs start with group., for example, group.eskimo1.test. macOS-style app group IDs start with your Team ID, for example, SKMME9E2Y8.eskimo1.test. This difference has been the source of numerous weird problems over the years. Starting in Feb 2025, iOS-style app group IDs are fully supported on macOS for all product types [1]. If you’re writing new code that uses app groups, use an iOS-style app group ID. If you have existing code that uses a macOS-style app group ID, consider how you might transition to the iOS style. IMPORTANT The Feb 2025 changes aren’t tied to an OS release but rather to a Developer website update. For more on this, see Feb 2025 Changes, below. [1] If your product is a standalone executable, like a daemon or agent, wrap it in an app-like structure, as explained in Signing a daemon with a restricted entitlement. iOS-Style App Group IDs An iOS-style app group ID has the following features: It starts with the group. prefix, for example, group.eskimo1.test. You allocate it on the Developer website. This assigns the app group ID to your team. You then claim access to it by listing it in the App Groups entitlement (com.apple.security.application-groups) entitlement. That claim must be authorised by a provisioning profile [1]. The Developer website will only let you include your team’s app group IDs in your profile. For more background on provisioning profiles, see TN3125 Inside Code Signing: Provisioning Profiles. iOS-style app group IDs originated on iOS with iOS 3.0. They’ve always been supported on iOS’s child platforms (iPadOS, tvOS, visionOS, and watchOS). On the Mac: They’ve been supported by Mac Catalyst since that technology was introduced. Likewise for iOS Apps on Mac. Starting in Feb 2025, they’re supported for other Mac products. [1] Strictly speaking macOS does not require that, but if your claim is not authorised by a profile then you might run into other problems. See Entitlements-Validated Flag, below. macOS-Style App Group IDs A macOS-style app group ID has the following features: It should start with your Team ID [1], for example, SKMME9E2Y8.eskimo1.test. It can’t be explicitly allocated on the Developer website. Code that isn’t sandboxed doesn’t need to claim the app group ID in the App Groups entitlement. [2] To use an app group, claim the app group ID in the App Groups entitlement. The App Groups entitlement is not restricted on macOS, meaning that this claim doesn’t need to be authorised by a provisioning profile [3]. However, if you claim an app group ID that’s not authorised in some way, you might run into problems. More on that later in this post. If you submit an app to the Mac App Store, the submission process checks that your app group IDs make sense, that is, they either start with your Team ID (macOS style) or are assigned to your team (iOS style). [1] This is “should” because, historically, macOS has not actually required it. However, that’s now changing, with things like app group container protection. [2] This was true prior to macOS 15. It may still technically be true in macOS 15 and later, but the most important thing, access to the app group container, requires the entitlement because of app group container protection. [3] Technically it’s a validation-required entitlement, something that we’ll come back to in the Entitlements-Validated Flag section. Feb 2025 Changes On 21 Feb 2025 we rolled out a change to the Developer website that completes the support for iOS-style app group IDs on the Mac. Specifically, it’s now possible to create a Mac provisioning profile that authorises the use of an iOS-style app group ID. Note This change doesn’t affect Mac Catalyst or iOS Apps on Mac, which have always been able to use iOS-style app group IDs on the Mac. Prior to this change it was possible to use an iOS-style app group ID on the Mac but that might result in some weird behaviour. Later sections of this post describe some of those problems. Of course, that information is now only of historical interest because, if you’re using an iOS-style app group, you can and should authorise that use with a provisioning profile. We also started seeding Xcode 16.3, which has since been release. This is aware of the Developer website change, and its Signing & Capabilities editor actively encourages you to use iOS-style app groups IDs in all products. Note This Xcode behaviour is the only option for iOS and its child platforms. With Xcode 16.3, it’s now the default for macOS as well. If you have existing project, enable this behaviour using the Register App Groups build setting. Finally, we updated a number of app group documentation pages, including App Groups entitlement and Configuring app groups. Crossing the Streams In some circumstances you might need to have a single app that accesses both an iOS- and a macOS-style app group. For example: You have a macOS app. You want to migrate to an iOS-style app group ID, perhaps because you want to share an app group container with a Mac Catalyst app. But you also need to access existing content in a container identified by a macOS-style app group ID. Historically this caused problems (FB16664827) but, as of Jun 2025, this is fully supported (r. 148552377). When the Developer website generates a Mac provisioning profile for an App ID with the App Groups capability, it automatically adds TEAM_ID.* to the list of app group IDs authorised by that profile (where TEAM_ID is your Team ID). This allows the app to claim access to every iOS-style app group ID associated with the App ID and any macOS-style app group IDs for that team. This helps in two circumstances: It avoids any Mac App Store Connect submission problems, because App Store Connect can see that the app’s profile authorises its use of all the it app group IDs it claims access to. Outside of App Store — for example, when you directly distribute an app using Developer ID signing — you no longer have to rely on macOS granting implicit access to macOS-style app group IDs. Rather, such access is explicitly authorised by your profile. That ensures that your entitlements remain validated, as discussed in the Entitlements-Validated Flag, below. A Historical Interlude These different styles of app group IDs have historical roots: On iOS, third-party apps have always used provisioning profiles, and thus the App Groups entitlement is restricted just like any other entitlement. On macOS, support for app groups was introduced before macOS had general support for provisioning profiles [1], and thus the App Groups entitlement is unrestricted. The unrestricted nature of this entitlement poses two problems. The first is accidental collisions. How do you prevent folks from accidentally using an app group ID that’s in use by some other developer? On iOS this is easy: The Developer website assigns each app group ID to a specific team, which guarantees uniqueness. macOS achieved a similar result by using the Team ID as a prefix. The second problem is malicious reuse. How do you prevent a Mac app from accessing the app group containers of some other team? Again, this isn’t an issue on iOS because the App Groups entitlement is restricted. On macOS the solution was for the Mac App Store to prevent you from publishing an app that used an app group ID that’s used by another team. However, this only works for Mac App Store apps. Directly distributed apps were free to access app group containers of any other app. That was considered acceptable back when the Mac App Store was first introduced. That’s no longer the case, which is why macOS 15 introduced app group container protection. See App Group Container Protection, below. [1] I’m specifically talking about provisioning profiles for directly distributed apps, that is, apps using Developer ID signing. Entitlements-Validated Flag The fact that the App Groups entitlement is unrestricted on macOS is, when you think about it, a little odd. The purpose of entitlements is to gate access to functionality. If an entitlement isn’t restricted, it’s not much of a gate! For most unrestricted entitlements that’s not a problem. Specifically, for both the App Sandbox and Hardened Runtime entitlements, those are things you opt in to, so macOS is happy to accept the entitlement at face value. After all, if you want to cheat you can just not opt in [1]. However, this isn’t the case for the App Groups entitlement, which actually gates access to functionality. Dealing with this requires macOS to walk a fine line between security and compatibility. Part of that solution is the entitlements-validated flag. When a process runs an executable, macOS checks its entitlements. There are two categories: Restricted entitlements must be authorised by a provisioning profile. If your process runs an executable that claims a restricted entitlement that’s not authorised by a profile, the system traps. Unrestricted entitlements don’t have to be authorised by a provisioning profile; they can be used by any code at any time. However, the App Groups entitlement is a special type of unrestricted entitlement called a validation-required entitlement. If a process runs an executable that claims a validation-required entitlement and that claim is not authorised by a profile, the system allows the process to continue running but clears its entitlements-validated flag. Some subsystems gate functionality on the entitlements-validated flag. For example, the data protection keychain uses entitlements as part of its access control model, but refuses to honour those entitlements if the entitlement-validated flag has been cleared. Note If you’re curious about this flag, use the procinfo subcommand of launchctl to view it. For example: % sudo launchctl procinfo `pgrep Test20230126` … code signing info = valid … entitlements validated … If the flag has been cleared, this line will be missing from the code signing info section. Historically this was a serious problem because it prevented you from creating an app that uses both app groups and the data protection keychain [2] (r. 104859788). Fortunately that’s no longer an issue because the Developer website now lets you include the App Groups entitlement in macOS provisioning profiles. [1] From the perspective of macOS checking entitlements at runtime. There are other checks: The App Sandbox is mandatory for Mac App Store apps, but that’s checked when you upload the app to App Store Connect. Directly distributed apps must be notarised to pass Gatekeeper, and the notary service requires that all executables enable the hardened runtime. [2] See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. App Groups and the Keychain The differences described above explain a historical oddity associated with keychain access. The Sharing access to keychain items among a collection of apps article says: Application groups When you collect related apps into an application group using the App Groups entitlement, they share access to a group container, and gain the ability to message each other in certain ways. You can use app group names as keychain access group names, without adding them to the Keychain Access Groups entitlement. On iOS this makes a lot of sense: The App Groups entitlement is a restricted entitlement on iOS. The Developer website assigns each iOS-style app group ID to a specific team, which guarantees uniqueness. The required group. prefix means that these keychain access groups can’t collide with other keychain access groups, which all start with an App ID prefix (there’s also Apple-only keychain access groups that start with other prefixes, like apple). However, this didn’t work on macOS [1] because the App Groups entitlement is unrestricted there. However, with the Feb 2025 changes it should now be possible to use an iOS-style app group ID as a keychain access group on macOS. Note I say “should” because I’ve not actually tried it (-: Keep in mind that standard keychain access groups are protected the same way on all platforms, using the restricted Keychain Access Groups entitlement (keychain-access-groups). [1] Except for Mac Catalyst apps and iOS Apps on Mac. Not Entirely Unsatisfied When you launch a Mac app that uses app groups you might see this log entry: type: error time: 10:41:35.858009+0000 process: taskgated-helper subsystem: com.apple.ManagedClient category: ProvisioningProfiles message: com.example.apple-samplecode.Test92322409: Unsatisfied entitlements: com.apple.security.application-groups Note The exact format of that log entry, and the circumstances under which it’s generated, varies by platform. On macOS 13.0.1 I was able to generate it by running a sandboxed app that claims a macOS-style app group ID in the App Groups entitlement and also claims some other restricted entitlement. This looks kinda worrying and can be the source of problems. It means that the App Groups entitlement claims an entitlement that’s not authorised by a provisioning profile. On iOS this would trap, but on macOS the system allows the process to continue running. It does, however, clear the entitlements-validate flag. See Entitlements-Validated Flag for an in-depth discussion of this. The easiest way to avoid this problem is to authorise your app group ID claims with a provisioning profile. If there’s some reason you can’t do that, watch out for potential problems with: The data protection keychain — See the discussion of that in the Entitlements-Validated Flag and App Groups and the Keychain sections, both above. App group container protection — See App Group Container Protection, below. App Group Container Protection macOS 15 introduced app group container protection. To access an app group container without user intervention: Claim access to the app group by listing its ID in the App Groups entitlement. Locate the container by calling the containerURL(forSecurityApplicationGroupIdentifier:) method. Ensure that at least one of the following criteria are met: Your app is deployed via the Mac App Store (A). Or via TestFlight when running on macOS 15.1 or later (B). Or the app group ID starts with your app’s Team ID (C). Or your app’s claim to the app group is authorised by a provisioning profile embedded in the app (D) [1]. If your app doesn’t follow these rules, the system prompts the user to approve its access to the container. If granted, that consent applies only for the duration of that app instance. For more on this, see: The System Integrity Protection section of the macOS Sequoia 15 Release Notes The System Integrity Protection section of the macOS Sequoia 15.1 Release Notes WWDC 2024 Session 10123 What’s new in privacy, starting at 12:23 The above criteria mean that you rarely run into the app group authorisation prompt. If you encounter a case where that happens, feel free to start a thread here on DevForums. See the top of this post for info on the topic and tags to use. Note Prior to the Feb 2025 change, things generally worked out fine when you app was deployed but you might’ve run into problems during development. That’s no longer the case. [1] This is what allows Mac Catalyst and iOS Apps on Mac to work. Revision History 2025-08-12 Added a reference to the Register App Groups build setting. 2025-07-28 Updated the Crossing the Streams section for the Jun 2025 change. Made other minor editorial changes. 2025-04-16 Rewrote the document now that iOS-style app group IDs are fully supported on the Mac. Changed the title from App Groups: macOS vs iOS: Fight! to App Groups: macOS vs iOS: Working Towards Harmony 2025-02-25 Fixed the Xcode version number mentioned in yesterday’s update. 2025-02-24 Added a quick update about the iOS-style app group IDs on macOS issue. 2024-11-05 Further clarified app group container protection. Reworked some other sections to account for this new reality. 2024-10-29 Clarified the points in App Group Container Protection. 2024-10-23 Fleshed out the discussion of app group container protection on macOS 15. 2024-09-04 Added information about app group container protection on macOS 15. 2023-01-31 Renamed the Not Entirely Unsatisfactory section to Not Entirely Unsatisfied. Updated it to describe the real impact of that log message. 2022-12-12 First posted.

Developers of our e-shop are preparing to enable Apple Sign In for account login. Apple ID verification is conducted via the domain appleid.apple.com, and the responses should be coming back from the following two Apple IP addresses: IPv4 Address: 17.32.194.6 IPv4 Address: 17.32.194.37 Question is whether these addresses are correct and if they remain unchanged over time. Alternatively, it is existing an official list of IP addresses that may be used for Apple Sign In verification response? This is necessary to ensure precise network communication settings and protection by F5 security solution. Thanks a lot for answers.

Hi, I’m currently implementing App Attest attestation validation on the development server. However, I’m receiving a 403 Forbidden response when I POST a CBOR-encoded payload to the following endpoint: curl -X POST -H "Content-Type: application/cbor" --data-binary @payload.cbor 'https://data-development.appattest.apple.com' Here’s how I’m generating the CBOR payload in Java: Map<String, Object> payload = new HashMap<>(); payload.put("attestation", attestationBytes); // byte[] from DCAppAttestService payload.put("clientDataHash", clientDataHash); // SHA-256 hash of the challenge (byte[]) payload.put("keyId", keyIdBytes); // Base64-decoded keyId (byte[]) payload.put("appId", TEAM_ID + "." + BUNDLE_ID); // e.g., "ABCDE12345.com.example.app" ObjectMapper cborMapper = new ObjectMapper(new CBORFactory()); byte[] cborBody = cborMapper.writeValueAsBytes(payload); I’m unsure whether the endpoint is rejecting the payload format or if the endpoint itself is incorrect for this stage. I’d appreciate clarification on the following: 1. Is https://data-development.appattest.apple.com the correct endpoint for key attestation in a development environment? 2. Should this endpoint accept CBOR-encoded payloads, or is it only for JSON-based assertion validation? 3. Is there a current official Apple documentation that lists: • the correct URLs for key attestation and assertion validation (production and development), • or any server-side example code (e.g., Java, Python) for handling attestation/validation on the backend? So far, I couldn’t find an official document that explicitly describes the expected HTTP endpoints for these operations. If there’s a newer guide or updated API reference, I’d appreciate a link. Thanks in advance for your help.

My application is supporting hybrid transport on FIDO2 webAuthn specs to create credential and assertion. And it support legacy passkeys which only mean to save to 1 device and not eligible to backup. However In my case, if i set the Backup Eligibility and Backup State flag to false, it fails on the completion of the registrationRequest to save the passkey credential within credential extension, the status is false instead of true. self.extension.completeRegistrationRequest(using: passkeyRegistrationCredential) The attestation and assertion flow only works when both flags set to true. Can advice why its must have to set both to true in this case?

I am working on a SDK which helps identify the device authenticity. I am in need of something which can confirm the firmware/Hardware/OS is signed by Apple and is authentic. There will be no tempering to device?

General: Forums topic: Privacy & Security Apple Platform Security support document Developer > Security Enabling enhanced security for your app documentation article Creating enhanced security helper extensions documentation article Security Audit Thoughts forums post Cryptography: Forums tags: Security, Apple CryptoKit Security framework documentation Apple CryptoKit framework documentation Common Crypto man pages — For the full list of pages, run: % man -k 3cc For more information about man pages, see Reading UNIX Manual Pages. On Cryptographic Key Formats forums post SecItem attributes for keys forums post CryptoCompatibility sample code Keychain: Forums tags: Security Security > Keychain Items documentation TN3137 On Mac keychain APIs and implementations SecItem Fundamentals forums post SecItem Pitfalls and Best Practices forums post Investigating hard-to-reproduce keychain problems forums post App ID Prefix Change and Keychain Access forums post Smart cards and other secure tokens: Forums tag: CryptoTokenKit CryptoTokenKit framework documentation Mac-specific resources: Forums tags: Security Foundation, Security Interface Security Foundation framework documentation Security Interface framework documentation BSD Privilege Escalation on macOS Related: Networking Resources — This covers high-level network security, including HTTPS and TLS. Network Extension Resources — This covers low-level network security, including VPN and content filters. Code Signing Resources Notarisation Resources Trusted Execution Resources — This includes Gatekeeper. App Sandbox Resources Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hello Apple Team We are integrating App Attest with our backend and seeing a 400 Bad Request response when calling the attestation endpoint. The issue is that the response does not include an X-Request-ID or JSON error payload with id and code, which makes it hard to diagnose. Instead, it only returns a receipt blob. Request Details URL: https://data-development.appattest.apple.com/v1/attestationData Request Headers: Authorization: eyJraWQiOiI0RjVLSzRGV1JaIiwidHlwIjoiSldUIiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJOOVNVR1pNNjdRIiwiZXhwIjoxNzU3MDUxNTYwLCJpYXQiOjE3NTcwNDc5NjB9.MEQCIF236MqPCl6Vexg7RcPUMK8XQeACXogldnpuiNnGQnzgAiBQqASdbJ64g58xfWGpbzY3iohvxBSO5U5ZE3l87JjfmQ Content-Type: application/octet-stream Request Body: (Binary data, logged as [B@59fd7d35) Response Status: 400 Bad Request Response Headers: Date: Fri, 05 Sep 2025 04:52:40 GMT x-b3-traceid: 4c42e18094022424 x-b3-spanid: 4c42e18094022424 Response Body (truncated): "receipt": h'308006092A864886F70D01070... Problem The response does not include X-Request-ID. The response does not include JSON with id or code. Only a receipt blob is returned. Questions Can the x-b3-traceid be used by Apple to trace this failed request internally? Is it expected for some failures to return only a receipt blob without X-Request-ID? How should we interpret this error so we can handle it properly in production? Thanks in advance for your guidance.

Hi team, if I log into my app on Safari and try to enroll/challenge MFA security key option, I will be able to see this pop-up that gives me the option to pick either passkeys or external security keys However, my team member who's using the same version of safari, can only see the external security key option Why is this?

I added a feature to my app that retrieves only app settings (no personal data) from my API hosted on Cloudflare Workers. The app does not send, collect, track, or share any user data, and I do not store or process any personal information. Technical details such as IP address, user agent, and device information may be automatically transmitted as part of the internet protocol when the request is made, but my app does not log or use them. Cloudflare may collect this information. Question: Does this count as “data collection” for App Store Connect purposes, or can I select “No Data Collected”?

I am developing a background program that is included in the app as an extension. I would like to include logic to check the teamID and code signature validity of the program I created to ensure that it has not been tampered with. Is this possible?

Can someone please guide me on the entire process of integrating ads in an IOS application using google's admob sdk? Not related to code but things related to Apple's privacy policy. Which options do need to select or specify in my app profile's privacy policy (identifier) section?

Greetings, We are struggling to implement device binding according to your documentation. We are generation a nonce value in backend like this: public static String generateNonce(int byteLength) { byte[] randomBytes = new byte[byteLength]; new SecureRandom().nextBytes(randomBytes); return Base64.getUrlEncoder().withoutPadding().encodeToString(randomBytes); } And our mobile client implement the attestation flow like this: @implementation AppAttestModule - (NSData *)sha256FromString:(NSString *)input { const char *str = [input UTF8String]; unsigned char result[CC_SHA256_DIGEST_LENGTH]; CC_SHA256(str, (CC_LONG)strlen(str), result); return [NSData dataWithBytes:result length:CC_SHA256_DIGEST_LENGTH]; } RCT_EXPORT_MODULE(); RCT_EXPORT_METHOD(generateAttestation:(NSString *)nonce resolver:(RCTPromiseResolveBlock)resolve rejecter:(RCTPromiseRejectBlock)reject) { if (@available(iOS 14.0, *)) { DCAppAttestService *service = [DCAppAttestService sharedService]; if (![service isSupported]) { reject(@"not_supported", @"App Attest is not supported on this device.", nil); return; } NSData *nonceData = [self sha256FromString:nonce]; NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults]; NSString *savedKeyId = [defaults stringForKey:@"AppAttestKeyId"]; NSString *savedAttestation = [defaults stringForKey:@"AppAttestAttestationData"]; void (^resolveWithValues)(NSString *keyId, NSData *assertion, NSString *attestationB64) = ^(NSString *keyId, NSData *assertion, NSString *attestationB64) { NSString *assertionB64 = [assertion base64EncodedStringWithOptions:0]; resolve(@{ @"nonce": nonce, @"signature": assertionB64, @"deviceType": @"IOS", @"attestationData": attestationB64 ?: @"", @"keyId": keyId }); }; void (^handleAssertion)(NSString *keyId, NSString *attestationB64) = ^(NSString *keyId, NSString *attestationB64) { [service generateAssertion:keyId clientDataHash:nonceData completionHandler:^(NSData *assertion, NSError *assertError) { if (!assertion) { reject(@"assertion_error", @"Failed to generate assertion", assertError); return; } resolveWithValues(keyId, assertion, attestationB64); }]; }; if (savedKeyId && savedAttestation) { handleAssertion(savedKeyId, savedAttestation); } else { [service generateKeyWithCompletionHandler:^(NSString *keyId, NSError *keyError) { if (!keyId) { reject(@"keygen_error", @"Failed to generate key", keyError); return; } [service attestKey:keyId clientDataHash:nonceData completionHandler:^(NSData *attestation, NSError *attestError) { if (!attestation) { reject(@"attestation_error", @"Failed to generate attestation", attestError); return; } NSString *attestationB64 = [attestation base64EncodedStringWithOptions:0]; [defaults setObject:keyId forKey:@"AppAttestKeyId"]; [defaults setObject:attestationB64 forKey:@"AppAttestAttestationData"]; [defaults synchronize]; handleAssertion(keyId, attestationB64); }]; }]; } } else { reject(@"ios_version", @"App Attest requires iOS 14+", nil); } } @end For validation we are extracting the nonce from the certificate like this: private static byte[] extractNonceFromAttestationCert(X509Certificate certificate) throws IOException { byte[] extensionValue = certificate.getExtensionValue("1.2.840.113635.100.8.2"); if (Objects.isNull(extensionValue)) { throw new IllegalArgumentException("Apple App Attest nonce extension not found in certificate."); } ASN1Primitive extensionPrimitive = ASN1Primitive.fromByteArray(extensionValue); ASN1OctetString outerOctet = ASN1OctetString.getInstance(extensionPrimitive); ASN1Sequence sequence = (ASN1Sequence) ASN1Primitive.fromByteArray(outerOctet.getOctets()); ASN1TaggedObject taggedObject = (ASN1TaggedObject) sequence.getObjectAt(0); ASN1OctetString nonceOctet = ASN1OctetString.getInstance(taggedObject.getObject()); return nonceOctet.getOctets(); } And for the verification we are using this method: private OptionalMethodResult<Void> verifyNonce(X509Certificate certificate, String expectedNonce, byte[] authData) { byte[] expectedNonceHash; try { byte[] nonceBytes = MessageDigest.getInstance("SHA-256").digest(expectedNonce.getBytes()); byte[] combined = ByteBuffer.allocate(authData.length + nonceBytes.length).put(authData).put(nonceBytes).array(); expectedNonceHash = MessageDigest.getInstance("SHA-256").digest(combined); } catch (NoSuchAlgorithmException e) { log.error("Error while validations iOS attestation: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } byte[] actualNonceFromCert; try { actualNonceFromCert = extractNonceFromAttestationCert(certificate); } catch (Exception e) { log.error("Error while extracting nonce from certificate: {}", e.getMessage(), e); return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } if (!Arrays.equals(expectedNonceHash, actualNonceFromCert)) { return OptionalMethodResult.ofError(deviceBindError.getChallengeNotMatchedError()); } return OptionalMethodResult.empty(); } But the values did not matched. What are we doing wrong here? Thanks.

Using personal physical iPhone for simulations. Can't get Keychain to read or store AppleID name/email. I want to avoid hard reseting physical phone. Logs confirm Keychain is working, but userIdentifier and savedEmail are not being stored correctly. 🔄 Initializing UserManager... ✅ Saved testKeychain to Keychain: Test Value ✅ Retrieved testKeychain from Keychain: Test Value 🔍 Keychain Test - Retrieved Value: Test Value ⚠️ Keychain Retrieve Warning: No stored value found for userIdentifier ⚠️ Keychain Retrieve Warning: No stored value found for savedEmail 🔍 Debug - Retrieved from Keychain: userIdentifier=nil, savedEmail=nil ⚠️ No stored userIdentifier in Keychain. User needs to sign in. 📦 Converting User to CKRecord: Unknown, No Email ✅ User saved locally: Unknown, No Email ✅ User saved to CloudKit: Unknown, No Email Below UserManager.swift if someone can help troubleshoot. Or step by step tutorial to configure a project and build a User Login &amp; User Account creation for Apple Only app. import Foundation import CloudKit import AuthenticationServices import SwiftData @MainActor class UserManager: ObservableObject { @Published var user: User? @Published var isLoggedIn = false @Published var errorMessage: String? private let database = CKContainer.default().publicCloudDatabase init() { print("🔄 Initializing UserManager...") // 🔍 Keychain Debug Test let testKey = "testKeychain" KeychainHelper.shared.save("Test Value", forKey: testKey) let retrievedValue = KeychainHelper.shared.retrieve(forKey: testKey) print("🔍 Keychain Test - Retrieved Value: \(retrievedValue ?? "nil")") fetchUser() // Continue normal initialization } // ✅ Sign in &amp; Save User func handleSignIn(_ authResults: ASAuthorization) { guard let appleIDCredential = authResults.credential as? ASAuthorizationAppleIDCredential else { errorMessage = "Error retrieving Apple credentials" print("❌ ASAuthorization Error: Invalid credentials received") return } let userIdentifier = appleIDCredential.user let fullName = appleIDCredential.fullName?.givenName ?? retrieveSavedName() var email = appleIDCredential.email ?? retrieveSavedEmail() print("🔍 Apple Sign-In Data: userIdentifier=\(userIdentifier), fullName=\(fullName), email=\(email)") // 🔄 If Apple doesn't return an email, check if it exists in Keychain if appleIDCredential.email == nil { print("⚠️ Apple Sign-In didn't return an email. Retrieving saved email from Keychain.") } // ✅ Store userIdentifier &amp; email in Keychain KeychainHelper.shared.save(userIdentifier, forKey: "userIdentifier") KeychainHelper.shared.save(email, forKey: "savedEmail") let newUser = User(fullName: fullName, email: email, userIdentifier: userIdentifier) saveUserToCloudKit(newUser) } func saveUserToCloudKit(_ user: User) { let record = user.toRecord() Task { do { try await database.save(record) DispatchQueue.main.async { self.user = user self.isLoggedIn = true self.saveUserLocally(user) print("✅ User saved to CloudKit: \(user.fullName), \(user.email)") } } catch { DispatchQueue.main.async { self.errorMessage = "Error saving user: \(error.localizedDescription)" print("❌ CloudKit Save Error: \(error.localizedDescription)") } } } } // ✅ Fetch User from CloudKit func fetchUser() { let userIdentifier = KeychainHelper.shared.retrieve(forKey: "userIdentifier") let savedEmail = KeychainHelper.shared.retrieve(forKey: "savedEmail") print("🔍 Debug - Retrieved from Keychain: userIdentifier=\(userIdentifier ?? "nil"), savedEmail=\(savedEmail ?? "nil")") guard let userIdentifier = userIdentifier else { print("⚠️ No stored userIdentifier in Keychain. User needs to sign in.") return } let predicate = NSPredicate(format: "userIdentifier == %@", userIdentifier) let query = CKQuery(recordType: "User", predicate: predicate) Task { [weak self] in guard let self = self else { return } do { let results = try await self.database.records(matching: query, resultsLimit: 1).matchResults if let (_, result) = results.first { switch result { case .success(let record): DispatchQueue.main.async { let fetchedUser = User(record: record) self.user = User( fullName: fetchedUser.fullName, email: savedEmail ?? fetchedUser.email, userIdentifier: userIdentifier ) self.isLoggedIn = true self.saveUserLocally(self.user!) print("✅ User loaded from CloudKit: \(fetchedUser.fullName), \(fetchedUser.email)") } case .failure(let error): DispatchQueue.main.async { print("❌ Error fetching user from CloudKit: \(error.localizedDescription)") } } } } catch { DispatchQueue.main.async { print("❌ CloudKit fetch error: \(error.localizedDescription)") } } } } // ✅ Save User Locally private func saveUserLocally(_ user: User) { if let encoded = try? JSONEncoder().encode(user) { UserDefaults.standard.set(encoded, forKey: "savedUser") UserDefaults.standard.set(user.fullName, forKey: "savedFullName") UserDefaults.standard.set(user.email, forKey: "savedEmail") print("✅ User saved locally: \(user.fullName), \(user.email)") } else { print("❌ Local Save Error: Failed to encode user data") } } // ✅ Retrieve Previously Saved Name private func retrieveSavedName() -&gt; String { return UserDefaults.standard.string(forKey: "savedFullName") ?? "Unknown" } // ✅ Retrieve Previously Saved Email private func retrieveSavedEmail() -&gt; String { return KeychainHelper.shared.retrieve(forKey: "savedEmail") ?? UserDefaults.standard.string(forKey: "savedEmail") ?? "No Email" } // ✅ Sign Out func signOut() { isLoggedIn = false user = nil UserDefaults.standard.removeObject(forKey: "savedUser") print("🚪 Signed Out") } }

With the new ios 26 update, certain numbers will be filtered into other inboxes within imessage. What numbers are classified as "known", and will not be moved into these filters. Do they need to be a contact in your phone, or if a business texts you how will that be filtered?