“A Summary of the WWDC25 Group Lab”

[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