A Summary of the WWDC25 Group Lab

Thanks a lot Quinn. I've checked the build files, no provisionprofile file in there. Also nothing in between, plain vanilla Unity 2023 project exported to Mac Xcode. The root:wheel thing might be a display thing because of the tooling (susipicious package), but I am not sure. I manually unpacked the package file using the cpio tool. There all files were belonging to me (martin:staff). I checked also the profiles in /Users/martin/Library/Developer/Xcode/UserData/Provisioning Profiles. All of those were root + group readable. I changed all those to 755 but that didn't change anything when rebuilding and re-creating the package. And I need to correct me, 2 files are root-only, the file CodeResources in the _CodeSignature subfolder is also root-only. I am absolutely not sure how to fix it. My first gut-feeling was, it is something the package & signing process of XCode needs to fix, to ensure all files are not only root-only. Any more idea how to solve it? Thank you very much for your help so far. He

Hi @Kamlofsky As my colleague mentioned, the maxTotalThreadsPerThreadgroup property of your MTLComputePipelineState is the way to go for checking the maximum number of threads that can be dispatched per threadgroup. I suggest using that value along with threadExecutionWidth to determine the correct number of threads and thread groups to dispatch, as described in Calculating Threadgroup and Grid Sizes. Alternatively, you can also specify a value for maxTotalThreadsPerThreadgroup yourself by creating a MTLComputePipelineDescriptor and setting its maxTotalThreadsPerThreadgroup property to your desired value. You can then use that descriptor to create a compute pipeline state via the makeComputePipelineState(descriptor:options:reflection:) method. Let me know if you have any further questions!

Also, regarding prefixing, given my container app bundle id is com.XXX.YYY and my ES extension bundle id is com.XXX.YYY.esextension, and my NSEndpointSecurityMachServiceName is {TEAM_ID}.com.XXX.YYY.status, with an app group both in the extension and the container app: com.apple.security.application-groups group.{TEAM_ID}.com.XXX.YYY Is this incorrect? because a group must start with group. and now it is a prefix of the XPC endpoint but it still blocks it with the same error (159).

Also, regarding prefixing, given my container app bundle id is com.XXX.YYY and my ES extension bundle id is com.XXX.YYY.esextension, and my NSEndpointSecurityMachServiceName is {TEAM_ID}.com.XXX.YYY.status, with an app group both in the extension and the container app: com.apple.security.application-groups group.{TEAM_ID}.com.XXX.YYY Is this incorrect?

Hey Quinn, thanks for answering. I will try prefixing the XPC endpoint with an app group ID. In the meanwhile regarding the other options, I think I don't understand them fully. Is disabling sandbox good practice? This app is distributed via MDM so as I understand it will work and solve it, but I don't know if it is the correct usage. Temporary exception works fine, but I think I don't understand temporary-exceptions properly, are apps with temporary exceptions allowed by Apple? I currently can notarize and launch them but should I ask apple for a non temporary mach lookup entitlement? because I see mixed usage of com.apple.security.temporary-exception.mach-lookup.global-name and com.apple.security.exception.mach-lookup.global-name, Are temporary exception allowed in production usage? Thanks, David.

Hi @DTS Engineer, QUOTE (link) Our general advice is to prefer Network framework over BSD Sockets, but UDP broadcasts and multicasts are an exception to that rule. Network framework has very limited UDP broadcast support. And while it’s support for UDP multicasts is less limited, it’s still not sufficient for all UDP applications. In cases where Network framework is not sufficient, BSD Sockets is your only option. UNQUOTE The idea is to know if Network framework is sufficient for us or should we be using BSD sockets API for multicast? Our use case is not very fancy and want to receive and send multicast on all interfaces. The code which we have written above is very simple and works for a IPv4 multicast group address but gives warnings and errors as listed above for IPv6 multicast group address. So, we wanted to know if 'Network Framework' has limited support for IPv6 multicast or it is a bug? Some of the limitations which are already known to us and we might soon file bugs for them as sugge

First up, terminology. When talking about extensions on Apple platforms: The container application is the application in which the extension is embedded. The host application is the app uses the extension. In the case of an ES sysex, the host application is the system itself. It seems like you’re trying to sandbox your container app. That’s pretty rare, because the ES sysex itself can’t be sandboxed and thus ES clients can’t be distributed on the Mac App Store. The simplest option here would be to not sandbox your container app. Beyond that, your description of how your ES sysex is constructed highlights a couple of oddities: I’m not sure what you’re expecting com.apple.security.xpc.server to do, but it’s not a known entitlement and thus won’t do anything useful [1]. NSExtensionPrincipalClass doesn’t make sense for an ES sysex because they don’t use Objective-C. [quote='789330021, justenx, /thread/789330, /profile/justenx'] I tried with the XPC_CONNECTION_MACH_SERVICE_PRIVILEGED flag but it still didn't work.

I’ve submitted a feedback request to Apple: FB18281742, requesting native sectioned grouping support in SwiftData similar to Core Data’s @SectionedFetchRequest.

--- START EtreCheck Summary (Sanitized) --- Model: MacBook Pro (M4, 2024) macOS: 15.5 Sequoia (24F74) iCloud Drive: Stalled hydration on this device only ❗ Symptom: bird shows sustained high CPU Console log reports: Waiting on local metadata index Other Macs (M1 and Intel) sync the same folders normally ✅ Attempted Fixes: killall bird Safe Mode boot Toggle iCloud Drive off/on Signed out and back in to Apple ID Isolated network and user profile Checked permissions and ran First Aid No third-party sync tools or VPN installed. mds_stores and mdworker_shared show intermittent activity. 💡 Request: Is there a known issue with Sequoia 15.5 (24F74) or M4 MacBooks and iCloud metadata sync? Safe way to reset bird metadata cache or hydration queue? Could sudo terminal usage during initial setup have affected local ownership? --- END Summary ---