On Tahoe and earlier, ScreenCapture permissions can disappear and not return. Customers are having an issue with this disappearing and when our code executes CGRequestScreenCaptureAccess() nothing happens, the prompt does not appear. I can reproduce this by using the "-" button and removing the entry in the settings, then adding it back with the "+" button. CGPreflightScreenCaptureAccess() always returns the correct value but once the entry has been removed, CGRequestScreenCaptureAccess() requires a reboot before it will work again.

Hello, When using ASWebAuthenticationSession with an HTTPS callback URL (Universal Link), I receive the following error: Authorization error: The operation couldn't be completed. Application with identifier jp.xxxx.yyyy.dev is not associated with domain xxxx-example.go.link. Using HTTPS callbacks requires Associated Domains using the webcredentials service type for xxxx-example.go.link. I checked Apple’s official documentation but couldn’t find any clear statement that webcredentials is required when using HTTPS callbacks in ASWebAuthenticationSession. What I’d like to confirm: Is webcredentials officially required when using HTTPS as a callback URL with ASWebAuthenticationSession? If so, is there any official documentation or technical note that states this requirement? Environment iOS 18.6.2 Xcode 16.4 Any clarification or official references would be greatly appreciated. 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.

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"

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

Hello, We are working on integrating app integrity verification into our service application, following Apple's App Attest and DeviceCheck guide. Our server issues a challenge to the client, which then sends the challenge, attestation, and keyId in CBOR format to Apple's App Attest server for verification. However, we are unable to reach both https://attest.apple.com and https://attest.development.apple.com due to network issues. These attempts have been made from both our internal corporate network and mobile hotspot environments. Despite adjusting DNS settings and other configurations, the issue persists. Are there alternative methods or solutions to address this problem? Any recommended network configurations or guidelines to successfully connect to Apple's App Attest servers would be greatly appreciated. Thank you.

I am asking about the apple Sign in implementation. ▫️ problems eas local build or test flight, I get a “Could not complete registration” message. When I check the console, I see the following error message. akd SRP authentication with server failed! Error: Error Domain=com.apple.AppleIDAuthSupport Code=2 UserInfo={NSDescription=<private>, Status=<private>} ▫️ Assumption ・Developed with Expo ・"expo-apple-authentication":"^7.2.4" ・Two apps are developed at the same time, using supabase, firebase, but both have the same error ・On Xcode, on app ids, apple sign in capability is turned on ・Service ids is set to domain, return url ・keys is created ・Internal test of testfligt is set to deliver

I have a user (myself, during development) who originally signed in with Apple successfully. I attempted to revoke access via Settings > Apple ID > Sign-In & Security > Sign in with Apple, but the app appears stuck in the list and cannot be fully removed. Now when attempting to sign in again, the identity token contains the correct sub but email is undefined. According to Apple's documentation, "Apple provides the user's email address in the identity token on all subsequent API responses." I've tried programmatically revoking via the /auth/revoke endpoint (received 200 OK), and I've implemented the server-to-server notification endpoint to handle consent-revoked events, but subsequent sign-in attempts still return no email. The same Apple ID works fine with other apps. Is there a way to fully reset the credential state for a specific app, or is this a known issue with partially-revoked authorizations?

Hi everyone, I’m developing a multiplayer iOS game that uses Multipeer Connectivity for local peer-to-peer networking. I’d like to display user-assigned device names in the UI to help players identify each other during the connection process. In iOS 16 and later, accessing UIDevice.current.name requires the User-Assigned Device Name Entitlement. The documentation states that the entitlement is granted for functionality involving “interaction between multiple devices that the same user operates”. My game is strictly multiplayer, with devices owned by different users, not a single user managing multiple devices. I have a few questions regarding this: Does the requirement for “devices operated by the same user” definitively exclude multiplayer scenarios where devices belong to different players? Can a Multipeer Connectivity-based game qualify for the entitlement in this case? If the entitlement is not applicable, is prompting users to enter custom names the recommended approach for identifying devices in a multiplayer UI? Has anyone successfully obtained this entitlement for a similar multiplayer use case with Multipeer Connectivity? Thanks in advance.

Hello everyone, I'm encountering a persistent 503 Server Temporarily Not Available error when trying to implement "Sign in with Apple" for my web application. I've already performed a full review of my configuration and I'm confident it's set up correctly, which makes this server-side error particularly confusing. Problem Description: Our web application uses Firebase Authentication to handle the "Sign in with Apple" flow. When a user clicks the sign-in button, they are correctly redirected to the appleid.apple.com authorization page. However, instead of seeing the login prompt, the page immediately displays a 503 Server Temporarily Not Available error. This is the redirect URL being generated (with the state parameter truncated for security): https://appleid.apple.com/auth/authorize?response_type=code&client_id=XXXXXX&redirect_uri=https%3A%2F%2FXXXXXX.firebaseapp.com%2F__%2Fauth%2Fhandler&state=AMbdmDk...&scope=email%20name&response_mode=form_post Troubleshooting Steps Performed: Initially, I was receiving an invalid_client error, which prompted me to meticulously verify every part of my setup. I have confirmed the following: App ID Configuration: The "Sign in with Apple" capability is enabled for our primary App ID. Services ID Configuration: We have a Services ID configured specifically for this. The "Sign in with Apple" feature is enabled on this Services ID. The domain is registered and verified under "Domains and Subdomains". Firebase Settings Match Apple Settings: The Services ID from Apple is used as the Client ID in our Firebase configuration. The Team ID is correct. We have generated a private key, and both the Key ID and the .p8 file have been correctly uploaded to Firebase. The key is not revoked in the Apple Developer portal. Since the redirect to Apple is happening with the correct client_id and redirect_uri, and the error is a 5xx server error (not a 4xx client error like invalid_client), I believe our configuration is correct and the issue might be on Apple's end. This has been happening consistently for some time. My Questions: What could be causing a persistent 503 Server Temporarily Not Available error on the /auth/authorize endpoint when all client-side configurations appear to be correct? What is the formal process for opening a technical support ticket (TSI) directly with Apple Developer Support for an issue like this? Thank you for any insights or help you can provide.

We currently have an app that uses Sign in with Apple (SIWA), and we are planning to discontinue the SIWA feature. Specifically, we intend to disable SIWA from the app's Capabilities in the Apple Developer Center. My question is, if we disable SIWA, can we continue to use the private email addresses of users who registered using SIWA? Or will disabling SIWA also invalidate the users' private email addresses? We are considering asking users to change to a different, valid email address in our app. However, if the private email addresses are invalidated, we will not be able to disable SIWA until all users have completed the email address change. If anyone has knowledge about these behaviors, please let us know.

I set up "Sign in with Apple" via REST API according to the documentation. I can log in on my website and everything looks fine for the user. But I receive an email, that my "Sign in with Apple" account has been rejected by my own website. It states, I will have to re-submit my name and email address the next time I log in to this website. I don't see any error messages, no log entries, no HTTP errors anywhere. I also can't find anything in the docs, the emails seem to not be mentioned there, searching for anything with "rejected" in the forum did not yield any helpful result, because they are always about App entries being rejected etc. Did someone experience something similar yet? What's the reason, I'm getting these emails? I get them every time I go through the "Sign in with Apple" flow on my website again.

Migrating APP and users, obtaining the user's transfer_sub, an exception occurred: {"error":"invalid_request"} `POST /auth/usermigrationinfo HTTP/1.1 Host: appleid.apple.com Content-Type: application/x-www-form-urlencoded Authorization: Bearer {access_token} sub={sub}&target={recipient_team_id}&client_id={client_id}&client_secret={client_secret} The specific request is as follows: 15:56:20.858 AppleService - --> POST https://appleid.apple.com/auth/usermigrationinfo 15:56:20.858 AppleService - Content-Type: application/x-www-form-urlencoded 15:56:20.858 AppleService - Content-Length: 395 15:56:20.858 AppleService - Authorization: Bearer a56a8828048af48c0871e73b55d8910aa.0.rzvs.96uUcy1KBqo34Kj8qrPb4w 15:56:20.858 AppleService - 15:56:20.858 AppleService - sub=001315.1535dbadc15b472987acdf634719a06a.0600&target=WLN67KBBV8&client_id=com.hawatalk.live&client_secret=eyJraWQiOiIzODg5U1ZXNDM5IiwiYWxnIjoiRVMyNTYifQ.eyJpc3MiOiJRMzlUU1BHMjk3IiwiaWF0IjoxNzU1MDcxNzc5LCJleHAiOjE3NTUwNzUzNzksImF1ZCI6Imh0dHBzOi8vYXBwbGVpZC5hcHBsZS5jb20iLCJzdWIiOiJjb20uaGF3YXRhbGsubGl2ZSJ9.8i9RYIcepuIiEqOMu1OOAlmmjnB84AJueel21gNapiNa9pr3498Zkj8J5MUIzvvnvsvUJkKQjp_VvnsG_IIrTA 15:56:20.859 AppleService - --> END POST (395-byte body) 15:56:21.675 AppleService - <-- 400 Bad Request https://appleid.apple.com/auth/usermigrationinfo(816ms) 15:56:21.675 AppleService - Server: Apple 15:56:21.675 AppleService - Date: Wed, 13 Aug 2025 07:56:22 GMT 15:56:21.675 AppleService - Content-Type: application/json;charset=UTF-8 15:56:21.675 AppleService - Content-Length: 27 15:56:21.675 AppleService - Connection: keep-alive 15:56:21.675 AppleService - Pragma: no-cache 15:56:21.675 AppleService - Cache-Control: no-store 15:56:21.676 AppleService - 15:56:21.676 AppleService - {"error":"invalid_request"} 15:56:21.676 AppleService - <-- END HTTP (27-byte body) ` Current Team ID: Q39TSPG297 Recipient Team ID: WLN67KBBV8 CLIENT_ID: com.hawatalk.live

Could you tell me about account security and passkeys? Our service is considering implementing passkeys, and these questions are to understand how Apple protects accounts from third parties. ① Apple website states that two-factor authentication is mandatory for newly created Apple Accounts. When did this requirement come into effect? What are the conditions for users who do not have two-factor authentication enabled? ② Apple website mentions that a verification code may be required when signing into an Apple Account from a new device or browser. Is my understanding of the situations where a verification code is requested accurate, as listed below? Are there any other situations? Completely signing out of the Apple Account on that device. Erasing the device. Needing to change the password for security reasons. ③ If a user is already using a passkey on an Apple device, and then upgrades to a new device, will additional authentication, such as entering a PIN code, be required to use the passkey on the new device?

I'm building a macOS app that registers itself for HTTP(S) url handling and would like it to participate in the ASWebAuthenticationSession fow. I did: update the plist to register as a handler for URL shemes (http, https, file) use NSWorkspace setDefaultApplication API to set this app as a default handler for urls in question wrote custom ASWebAuthenticationSessionWebBrowserSessionHandling implementation and set it as SessionManager's sessionHandler I launched this app from Xcode, then I triggered authentication flow from a third-party app. When the sign in flow is initiated, I can see that my app is activeated (willBecomeActive and didBecomeActive callbacks are both called), but there is no call for sessionHandler's begin() method. With some additional debugging I see that my app receives an apple event when the flow is started: {sfri,auth target=SafariLaunchAgent {qntp=90/$627......},aapd=TRUE If I switch system default browser back to Safari and then start the login flow, it correctly displays a sign in web page. What do I miss? PS. I'm on Tahoe 26.2

My app Mocawave is a music player distributed through the Mac App Store. It declares specific audio document types (public.mp3, com.microsoft.waveform-audio, public.mpeg-4-audio, public.aac-audio) in its CFBundleDocumentTypes with a Viewer role. When a user sets Mocawave as the default app for audio files and double-clicks an MP3 downloaded from the internet (which has the com.apple.quarantine extended attribute), macOS displays the alert: "Apple could not verify [filename] is free of malware that may harm your Mac or compromise your privacy." This does not happen when: Opening the same file via NSOpenPanel from within the app Opening the same file with Apple's Music.app or QuickTime Player The app is: Distributed through the Mac App Store Sandboxed (com.apple.security.app-sandbox) Uses com.apple.security.files.user-selected.read-write entitlement The file being opened is a regular audio file (MP3), not an executable. Since the app is sandboxed and distributed through the App Store, I expected it to have sufficient trust to open quarantined data files without triggering Gatekeeper warnings — similar to how Music.app and QuickTime handle them. Questions: Is there a specific entitlement or Info.plist configuration that allows a sandboxed Mac App Store app to open quarantined audio files without this alert? Is this expected behavior for third-party App Store apps, or could this indicate a misconfiguration on my end? Environment: macOS 15 (Sequoia), app built with Swift/SwiftUI, targeting macOS 13+.

We have been sending emails through Sparkpost via Braze inc. to the Apple Private Relay users with "@privaterelay.appleid.com" starting from around June 20th or so. Upon August 9th 06:00 UTC, we have noticed a sudden increase of "Hard Bounce" for nearly 20,000 users using the Apple's private relay email address, rendering the email sending useless for these customers. We have been constantly been able to send them emails, including just before this timeframe (e.g. August 9th 03:00 UTC), so it was a very sudden purge of the user data that has been done without our consent. From a business perspective, this hurts a lot for the un-sendable users since we have no way of contacting them if not for the private address. We are desperate to know what has happened for these customers that has been "hard bounced". We are suspecting that it should be tied to the private email and the users primary email (or user data's) tie in the Apple server being gone, but not sure enough since there is no such documentation nor any way to acknowledge what has happened anywhere. We will provide any information possible for resolving. Thank you.

Apple has repeatedly ignored my reports about a critical privacy issue in Spotlight on macOS 26, and the problem persists in version 26.3 RC. This is not a minor glitch, it is a fundamental breach of user trust and privacy. Several aspects of Spotlight fail to respect user settings: • Hidden apps still exposed: In the Apps section (Cmd+1), Spotlight continues to display apps marked with the hidden flag, even though they should remain invisible. • Clipboard reactivation: The clipboard feature repeatedly turns itself back on after logout or restart, despite being explicitly disabled by the user. • Excluded files revealed: Most concerning, Spotlight exposes files in Suggestions and Recents (Cmd+3) even when those files are explicitly excluded under System Settings > Spotlight > Search Privacy. This behavior directly violates user expectations and system settings. It is not only a major privacy issue but also a security risk, since sensitive files can be surfaced without consent. Apple must address this immediately. Users rely on Spotlight to respect their privacy configurations, and the current behavior undermines both trust and security.

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.

hello, I'm writing to seek clarification on Apple account security, particularly regarding potential risks of compromise, implemented safeguards, and residual risks with corresponding mitigation strategies. We would appreciate your insights on the following specific points: iCloud Keychain Access: Is an Apple ID login strictly required to access iCloud Keychain? We understand that a compromise of iCloud Keychain is unlikely unless a malicious actor successfully takes over the legitimate user's Apple ID. Is this understanding correct? Passkey Theft Methods and Protections: What are the conceivable methods a malicious actor might employ to steal a legitimate user's passkey, and how are these attempts protected against? Impact of Apple ID Compromise on Passkeys: If a malicious actor successfully compromises a legitimate user's Apple ID, is it accurate to assume that the legitimate user's passkeys would then synchronize to the attacker's device, potentially allowing them to log in using their own biometrics? Authorization Flow on Legitimate User's Device: Could you please detail the authorization flow that occurs on the legitimate user's device? We are particularly interested in the types of authentication involved and the conditions under which they are triggered. Detection and Additional Authentication for Unauthorized Login: How are attempts to log in to an Apple ID from an unrecognized device or browser detected, and what additional authentication steps are implemented in such scenarios? Thank you for your time and assistance in addressing these important security questions.