A Summary of the WWDC25 Group Lab

You are correct that the profile from step 3 has no entry for key-value storage. However, the profile from step 5 still uses the old team ID. One thing I realized while looking at this is that I'm still a member of the old team. That team's developer subscription is no longer active but I'm still a member. I almost left it when I realized but decided to only follow the steps you suggested. Step 3 (iCloud not enabled) Entitlements => { application-identifier => TEAM_ID.com.ORGANIZATION.APP aps-environment => production beta-reports-active => true com.apple.developer.team-identifier => TEAM_ID com.apple.security.application-groups => [ 0 => group.ORGANIZATION ] get-task-allow => false keychain-access-groups => [ 0 => TEAM_ID.* 1 => com.apple.token ] } Step 5 (iCloud re-enabled) Entitlements => { application-identifier => TEAM_ID.com.ORGANIZATION.APP aps-environment => production beta-reports-active => true com.apple.developer.icloud-container-develo

How are you creating this directory: /System/Volumes/Data/mnt/ The issue here is that the contents that are visible at / are created by basically merging the contents of the ROSV (Read Only System Volume) and the data volume of its volume group. Within that context, I think there are two ways to create something like a common mnt directory: Bypass these issues by placing the directory inside one of the existing standard directories. For example, create /Library/mnt/. If you specifically want the directory to exist at /, then use the /etc/synthetic.conf config file to create a new directory or symbolic link (see man synthetic.conf) for details. ...but what I would NOT do is simply create a new directory at the root of the Data volume and use it through /System/Volumes/ like this: /System/Volumes/Data/mnt/ The BEST case here is that you only get weird UI issues, since mnt won't be visible at / but will be visible in the path above (which is not a standard path). The worst case is that: I am working on

If you are using SubscriptionStoreView with groupID overload, make sure the groupID entered is matching with the one in App Store Connect, not the one from your Xcode StoreKit configuration file. In Xcode testing, you need a StoreKit config file, and make sure to select Edit Scheme -> Options tab and select StoreKit Configuration to the correct configuration file. But this does not affect your App Store version. You might need to handle unfinished transactions. Take a look at sample code from WWDC25 on StoreKit 2.

Paris and I chatted about your issue and we realised that it has a bit more subtlety than we first thought. First up, it’s not clear whether the app that hits this issue is one of your apps, or whether you’re hitting it an app created by a different third-party developer. We can help you in the first case, but in the second case you should talk to that app’s developer. Assuming that you are the one creating this app, the alert you’re seeing is the result of a feature known as app group container protection. There’s a link to the WWDC video that introduced this feature in Trusted Execution Resources. I also have a bunch of info about app groups in general in my App Groups: macOS vs iOS: Working Towards Harmony post. As explained in that last post, you don’t see this alert if all the apps accessing the app group are from the same team. However, there’s no way to avoid it if you’re trying to access an app group associated with some other team. The example you posted s

[quote='872694022, Kopyl, /thread/775029?answerId=872694022#872694022, /profile/Kopyl'] my app has nothing to do with iOS and their app groups. [/quote] OK. But my post, App Groups: macOS vs iOS: Working Towards Harmony, is still relevant regardless. The good news is that the situation has both stabilised and improved since you started this thread, and thus I don’t see any impediments to you solving this nicely. To offer specific advice I need to know more about your specific setup. What is your Team ID? What is the Apple ID of your app? And what app group ID are you trying to use? If you’re not comfortable sharing this info publicly, feel free to redact it. For example, for Apple Configurator that info would be: Team ID 4WXS7A4F54 -> 4________4 Apple ID 1037126344 -> 1________4 App group ID K36BKF7T3D.group.com.apple.configurator -> K________D.g___p.c__.a___e.c__________r IMPORTANT I’m looking for the Apple ID of the app, not your Apple ID (now known as an Apple A

@DTS Engineer my app has nothing to do with iOS and their app groups. The issue started happening out of nowhere without me doing anything. So you're just wrong.

Thanks Quinn. For storing an encrypted key, it looks as though a private keychain access-group might work as well - so maybe a combination of the container and encryption would be sufficient.

Yes, the app builds fine when disabling key-value storage. Dumping the provisioning profile shows this: Entitlements => { application-identifier => TEAM_ID.com.ORGANIZATION.APP aps-environment => development com.apple.developer.icloud-container-development-container-identifiers => [ 0 => iCloud.ORGANIZATION.APP ] com.apple.developer.icloud-container-environment => [ 0 => Production 1 => Development ] com.apple.developer.icloud-container-identifiers => [ 0 => iCloud.ORGANIZATION.APP ] com.apple.developer.icloud-services => * com.apple.developer.team-identifier => TEAM_ID com.apple.developer.ubiquity-container-identifiers => [ 0 => iCloud.ORGANIZATION.APP ] com.apple.developer.ubiquity-kvstore-identifier => OTHER_TEAM_ID.com.ORGANIZATION.APP com.apple.security.application-groups => [ 0 => group.ORGANIZATION ] get-task-allow => true keychain-access-groups => [ 0 => TEAM_ID.* 1 => com.apple.token ] } So it does appear that the old te

OK, so definitely not your project. If you temporarily remove the iCloud key-value storage capability capability, the app builds, right? If so, look in the build log for an entry like this: CodeSign …/Test811382.app (in target 'Test811382' from project 'Test811382') cd …/Test811382 Signing Identity: Apple Development: Quinn Quinn (7XFU7D52S4) Provisioning Profile: iOS Team Provisioning Profile: com.example.apple-samplecode.Test811382 (5db3ba83-07fb-4780-8ca4-f87de64fd20d) Note For info on how to get the build log, see Command [something] failed with a nonzero exit code. The UUID in that entry is the UUID of the provisioning profile that Xcode is using to sign your app. You should find that in ~/Library/Developer/Xcode/UserData/Provisioning Profiles. Now dump the contents of that profile like so: % security cms -D -i 5db3ba83-07fb-4780-8ca4-f87de64fd20d.mobileprovision | plutil -p - { … Entitlements => { application-identifier => SKMME9E2Y8.com.example.apple-samplecode.Test811382 com.apple.developer.iclo

There are two options available to third-party developers here: Sandboxed app containers — These are protected as of macOS 14. App group containers — These are protected as of macOS 15. I have links to the WWDC sessions that introduce these protections in Trusted Execution Resources. Neither of these is as tightly locked down as you’d like, but such is the nature of security trade-offs. And many of the MAC protected directories for Apple products, like ~/Library/Mail, have similar trade-offs, with ways around the protection like Full Disk Access or the Finder. And this is the Mac, so if the user turns off SIP then all bets are off. IMPORTANT If you do anything with app groups on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. [quote='872297022, SpacedCowboy, /thread/812688?answerId=872297022#872297022, /profile/SpacedCowboy'] where do you keep the master encryption key [/quote] My standard answer to that is the data protection keychain. That’s protected by the Mac’s

A local support person from the company says that my subscription plans are ready for submission even though the status for both localization options are Prepare for Submission. He or she says the following is written somewhere although I don't see it. You uploaded all the metadata needed, but you have not yet sent it to Apple for review. He or she says that the Prepare for Submission status for the localization options only suggests that the subscription group isn't submitted for the review and isn't approved. That's a terribly bad design.

Hi Kevin, Thank you for your detailed feedback and for spending time looking at your internal driver implementation. I have followed your suggestions and filed a formal bug report. 1. Bug Report Filed I have filed a bug report via Feedback Assistant. Feedback ID: FB21636775 I have attached the original and symbolicated crash logs, along with reduced code snippets showing our implementation. 2. OSAction Pointer Confirmation I have verified the value of the completion pointer received in UserProcessBundledParallelTasks. As you suspected, the pointer address is identical for all commands within a single bundle. 3. Crash Log Insights The symbolicated crash log confirms that the panic is triggered by an __assert_rtn inside OSMetaClassBase::QueueForObject during the call to completion. Specifically, when we attempted the Unified Path (using legacy ParallelTaskCompletion for bundled commands) as a stability test, it triggered an immediate panic, which confirms your point that we MUST use BundledParallelTaskCompletio