A Summary of the WWDC25 Group Lab

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 ---

[quote='844730022, vishalsehgal, /thread/788532?answerId=844730022#844730022, /profile/vishalsehgal'] No, I am only connected to only a single wifi interface which supports IPv6 multicast. [/quote] That’s pretty much never the case on modern Apple platforms. Here’s what I seen on my Mac (running macOS 15.5) when it’s bound to Wi-Fi: % ifconfig | grep MULTICAST | grep -v POINTOPOINT lo0: flags=8049 mtu 16384 anpi2: flags=8863 mtu 1500 anpi1: flags=8863 mtu 1500 anpi0: flags=8863 mtu 1500 en4: flags=8863 mtu 1500 en5: flags=8863 mtu 1500 en6: flags=8863 mtu 1500 en1: flags=8963 mtu 1500 en2: flags=8963 mtu 1500 en3: flags=8963 mtu 1500 bridge0: flags=8863 mtu 1500 ap1: flags=8863 mtu 1500 en0: flags=8863 mtu 1500 awdl0: flags=8863 mtu 1500 llw0: flags=8863 mtu 1500 vmenet0: flags=8963 mtu 1500 bridge100: flags=8a63 mtu 1500 This is with nothing special (such as VPN and VMs) running. This is why my advice in Broadcasts and Multicasts, Hints and Tips is to always target a specific interface when you send. Anyway,

Hi, and thank you for the quick response. It's greatly appreciated! Unfortunately, this crash does not appear to generate a crash log. However, we're able to reproduce it consistently on two separate Apple Watch devices. When using NSPersistentCloudKitContainer and the device is offline (no Wi-Fi and no Bluetooth), the app crashes when entering the background. If we switch to NSPersistentContainer, no crash occurs under the same conditions. If the device is online, no crash occurs, even when using NSPersistentCloudKitContainer and allowing the app to enter the background. If we keep the app in the foreground (e.g., by continuously tapping the screen), the app also does not crash, even when offline and using NSPersistentCloudKitContainer. So in summary, the crash consistently occurs under the following three conditions: Using NSPersistentCloudKitContainer Device is offline (no Wi-Fi, no Bluetooth) App transitions to the background. We would appreciate any insight, particularly if this might be a known

No, I am only connected to only a single wifi interface which supports IPv6 multicast. For IPv4, it is working fine. I am able to send/receive data using the code mentioned here: [quote='788532021, vishalsehgal, /thread/788532, /profile/vishalsehgal'] import Network import Foundation // Creating a mutlicast group endpoint [/quote] But for IPv6, it is failing with the following errors/warnings: nw_endpoint_flow_failed_with_error [C1 ff02::1.49153 waiting parent-flow (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, ipv6, uses wifi)] already failing, returning nw_socket_connect [C1:1] connectx(7, [srcif=0, srcaddr=::.62838, dstaddr=ff02::1.49153], SAE_ASSOCID_ANY, 0, NULL, 0, NULL, SAE_CONNID_ANY) failed: [48: Address already in use] nw_socket_connect [C1:1] connectx failed (fd 7) [48: Address already in use] nw_socket_connect connectx failed [48: Address already in use] nw_endpoint_flow_failed_with_error [C1 ff02::1.49153 in_progress socket-flow (satisfied (Path is satisfied), int

Same issue here but this just started today as I have been using 26.0 beta since the WWDC25 with out this issue. I had seen it on Xcode 16 when running it on macOS 26 but not with the Xcode Beta.