我配置了 DKIM 和 amazon 的默认 spf。但无法使用 Amazon Send 获取电子邮件，则可以发送配置的单个电子邮件

Hi, I have recently encountered an app with some odd behaviour and wanted to clarify some details about the way sandboxing works with iOS apps installed on a Mac. I am unsure whether this is due to a misunderstanding of system behaviour or whether this is a bug. The app was installed from the Mac App Store, designed for iPad. The developer of the app informed me that in lieu of a sign-in process, the app tries to persistently store a UUID of the user on the device so that when the app is deleted and reinstalled, the user is automatically logged in again. The developer says that two mechanisms are being used: 1) NSUserDefaults (via Flutter shared prefs) and 2) identifierForVendor. In the case of 1), my understanding is that these are managed by cfprefsd. Using the 'defaults domain' command, the domain of the app appears. However, there are no keys or values stored. Using the 'defaults write' and 'defaults read' and 'defaults delete' commands on that bundle identifier works as expected, but since it starts out empty, it cannot be read or deleted. Furthermore, the app's data is supposed to be sandboxed in /Library/Containers. When the app is uninstalled from Launchpad, I have confirmed that the folder is missing. When reinstalled, the app's settings and data are missing, but crucially, the cloud identifier is still persistent and is evident after 'setup'. In the case of 2), the developer documentation states that identifierForVendor changes when all apps from a developer have been removed from a device. The app in question is the only app that was installed from this developer, so logically this identifier should have changed when the app was deleted and reinstalled. I have confirmed that iCloud drive is not being used to store this data as there is no data in iCloud for this app. In any case, when the app is uninstalled and reinstalled, the app automatically logs the user into the "account" it was previously logged into, along with all of that user's data in the cloud. I have a sense that this type of persistent identifier tracking is what sandboxing was meant to address, but I am unsure why I have been unable to remove the UUID tag from my system. Any insight would be greatly appreciated!

Hi, I hope someone is able to help me with this query: Is there a mandatory requirement to display a view before presenting the App Tracking Transparency modal to explain to the user why the app is asking for tracking? I see there are a few apps which do this, but I don't see any mention of this as a mandatory requirement within the app store review guidelines. The modal can be customised with a description detailing why the app is asking for tracking and I believe this may be sufficient to pass an app store review. The guidelines also mention that the app must provide access to information about how and where the data will be used. We have these details in our privacy policy which is accessible from within the app. Is this sufficient or do we need a pre-modal view which contains a direct link the the privacy policy. Any advice on this would be much appreciated.

I'm developing a file access control system. In order to protect the file content copied out, I'm finding a way to deny user copy file content to other files. I know there are data transmission between the copied application and pboard service by XPC. But I don't know how to interrupt the data transmission. Or I can do something to stop the copied data send to the Clipboard. So is there any way to prevent the contents of a file being copied?

Hello everyone, I’ve been working on ways to implement stricter accountability systems for personal use, especially to prevent access to NSFW content in apps like Reddit and Twitter. The main challenge is that iOS sandboxing and privacy policies block apps from monitoring or interacting with other apps on the system. While Apple’s focus on privacy is important, there’s a clear need for an opt-in exception for accountability tools. These tools could be allowed enhanced permissions under stricter oversight to help users maintain accountability and integrity without compromising safety. Here are a few ideas I’ve been thinking about: 1. Vetted Apps with Enhanced Permissions: Allow trusted applications to bypass sandbox restrictions with user consent and close monitoring by Apple. 2. Improved Parental Controls: Add options to send notifications to moderators (like accountability partners) when restrictions are bypassed or disabled. 3. Custom Keyboard or API Access: Provide a framework for limited system-wide text monitoring for specific use cases, again with user consent. If anyone has ideas for how to address this within current policies—or suggestions for advocating for more flexibility—I’d appreciate the input. I’m curious how others have handled similar challenges or if there are better approaches I haven’t considered.

Hi all, I found an issue by chance where, when we copy an .app bundle (a large one), Gatekeeper can choose to try to scan the app before the file copying finishes (without the app having been launched). This of course fails, and then the app can't open because "it's damaged", even though spctl and codesign checks of the completed copied app come out fine. Then Gatekeeper remembers this setting forever, not rescanning the app. I'm wondering if anyone else has seen this happen and if so, if there's a best practice for keeping Gatekeeper's hands off until the copy is done? I imagine copying into a folder not named .app, then renaming it might work, or maybe saving the plist or main binary copy until last, although both require a more complex copy operation. Maybe there's a more elegant way? Thanks!

Hello, I would like to secure the exchanges between my application and my webservices to make sure requests are only made by an authentic application. By searching the internet I discovered that App Attest from Device Check framework exists but it looks like there are some limitation about it : App Attest doesn't work on most App Extensions (like Share extension) We are limited by the requests count made to the App Attest webservice (only when generating the Apple certificate, one time by device / application). The problem is I need this security on my app extension because I have a Share extension sending e-mails. Do you have advice to secure the exchanges between my app and my webservices ?

E aí pessoal, tudo certo? Estou desenvolvendo um app com React Native no front-end e Node.js no back-end, usando o Firebase como banco de dados (e possivelmente para autenticação também, dependendo da solução). Preciso implementar o "Sign in with Apple" e estou com algumas dúvidas em como integrar tudo isso. A ideia é: o usuário clica no botão "Entrar com a Apple" no app (React Native), o backend (Node.js) processa a autenticação com a Apple e, em seguida, armazena as informações necessárias (nome, email, etc.) no Firebase. Se alguém já trabalhou com essa combinação (React Native, Node.js, Firebase e Sign in with Apple) e puder compartilhar alguma experiência, dicas, exemplos de código ou até mesmo um boilerplate, seria de grande ajuda!

Hello, I have a public key of type Curve25519.KeyAgreement.PublicKey that I create from the raw representation using: Curve25519.KeyAgreement.PublicKey(rawRepresentation: Data(base64Encoded: "08sYq4gExgX+UApEwLaASkE+TZjAxG1FPYaT+mj2irk=")!) I'm trying to convert that key to a curve, but I don't see an equivalent function in CryptoKit for the Javascript function pk_to_curve25519. Can someone please help? For completeness, I'm trying to implement the handshake protocol that's a part of secure scuttlebutt. https://ssbc.github.io/scuttlebutt-protocol-guide/

https://developer.apple.com/documentation/apptrackingtransparency/attrackingmanager/authorizationstatus/notdetermined Note: Discussion If you call ATTrackingManager.trackingAuthorizationStatus in macOS, the result is always ATTrackingManager.AuthorizationStatus.notDetermined. So, does macOS support getting ATT?

Hi I am currently developping the "Sign in with apple" feature. We set up everything according to the documentation : https://developer.apple.com/help/account/configure-app-capabilities/configure-private-email-relay-service When trying to send an email from one of the registered communication emails (that is SPF and DKIM Authentication compliant) the emails are still ending up in the spam box. If it can help the received email address (that is hidden) is a gmail. I can not catch what is missing/wrong on our side.

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

Hello, I'm having a problem with taxes calculation for US, the thing is, for some very specific addresses the taxes are coming wrong because we don't have the full address before the authorization with Adyen (our payment provider), for example, when I put the address "1 Infinite Loop, CA, US, 95014" in my wallet, I'm not receiving the value "1 Infinite Loop" (addressLines[0]) in backend until we authorize in Adyen, but I need this field to calculate the taxes and show to the customer before the authorization. My question is, is there any way to have this field before the authorization? If not, you have any idea how other ecommerces that use ApplePay and Adyen handle with this problem? Thanks in advance!

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.

I am in need of assistance with sandboxing the riot games client and game league of legends. I originally played on a vm from linux but after the change to the incredibly intrusive rootkit malware vanguard. I cannot play from a vm or at least it would be difficult, if this route of containerizing it on mac proves to be more difficult (which wouldn't make sense) then I will go back to spoofing the a vm to not look like a vm. This is even more infuriating because I almost exclusively play Team Fight Tactics in which there is zero cheating and cheating would give a player zero advantage. I decided I would try the Mac version of the game but apple does not sandbox applications at all like flatpak and flatseal from linux. The game has access to my entire system and can read and write to my home directory. This is a massive security risk. I originally tried checking the system settings privacy and security section but the application was not listed anywhere nor was it given access on any of the sections listed. I checked both user local and global tcc.dbs and neither had records that gave the game or client any privileges. This was concerning because tcc.db appears to be the only user facing way of managing permissions that you would think would be a bare minimum baseline and yet the game and client have full access to my system and those permissions are listed nowhere and are given no where. Ie. the default is just to let it do as it pleases even though its a game that only thing it needs to render to the screen. MacOS should properly fix this and implement proper sandboxing of applications like flatpak. I then began building a configuration scheme for sandbox-exec seeing as it was the last opportunity to correctly contain the application to only have the permissions it needs. I carefully crafted the config but it fails just as simply allowing all with allow default... (version 1) (allow default) I run the application with the following command: sandbox-exec -f ~/config.sb "/Users/Shared/Riot Games/Riot Client.app/Contents/MacOS/RiotClientServices" Below are some of the errors produced from running the client sandboxed. 00:44:09.819 (SplashScreenManager) Displaying splash screen from default-splash.html for 2000ms 00:44:09.825 app.isPackaged true 00:44:09.842 Loading page from http://127.0.0.1:51563/index.html sandbox initialization failed: Operation not permitted Failed to initialize sandbox.[0102/004409.953876:ERROR:exception_snapshot_mac.cc(139)] exception_thread not found in task [0102/004409.954838:ERROR:process_reader_mac.cc(309)] thread_get_state(4): (os/kern) invalid argument (4) [0102/004409.954852:ERROR:process_reader_mac.cc(309)] thread_get_state(4): (os/kern) invalid argument (4) [0102/004409.955178:WARNING:process_reader_mac.cc(532)] multiple MH_EXECUTE modules (/usr/libexec/rosetta/runtime, /Library/Apple/usr/libexec/oah/libRosettaRuntime) [0102/004409.955364:WARNING:process_reader_mac.cc(532)] multiple MH_EXECUTE modules (/usr/libexec/rosetta/runtime, /Users/Shared/Riot Games/Riot Client.app/Contents/Frameworks/Riot Client.app/Contents/Frameworks/Riot Client Helper (Renderer).app/Contents/MacOS/Riot Client Helper (Renderer)) [0102/004410.111422:ERROR:exception_snapshot_mac.cc(139)] exception_thread not found in task [4607:0102/004415.168524:ERROR:gpu_process_host.cc(991)] GPU process exited unexpectedly: exit_code=6 [4607:0102/004415.187770:ERROR:network_service_instance_impl.cc(521)] Network service crashed, restarting service. 00:44:15.215 Renderer process has unexpectedly crashed or was killed: crashed (6) { reason: 'crashed', exitCode: 6 }

No entry in manifest for file key.pem

If we record the user's Device Model (ie. iPhone 15), what checkbox do we need to select under Data Collection in App Privacy? Device model is not a unique identifier, we do not use it for tracking. We use it to know in aggregate which phone models are using our app the most so we can prioritize our QA to focus on the top devices. Please note: we DO NOT access Device ID, as we DO NOT use it.

Our company developed an app that relies on the collected list to display the phone's label in the list when the user's phone receives an incoming call. However, we have been rejected. The main reason for the rejection is as follows: “ Guideline 1.1.6 - Safety - Objectionable Content The app still allows users to unblock and reveal blocked incoming numbers to identify the individual calling or texting, which is not appropriate. Specifically, your app claims to offer the call blocking functionality, but solely identifies numbers that the user has explicitly blocked themselves. Since users can choose to hide their caller ID in iPhone Settings, apps should not attempt to circumvent this iOS feature to reveal the caller's number. ” But our developers clearly stated that there is no way to bypass these settings, and CallDirectory Extensionde cannot directly "unlock hidden numbers" or bypass the built-in restrictions of IOS. We don't know how to solve this problem next, and hope to get everyone's help.

I don't see any certificates or CAs in the Passwords application, so now what?

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.