“A Summary of the WWDC25 Group Lab”

[quote='866975022, nikhil2701, /thread/807854?answerId=866975022#866975022, /profile/nikhil2701'] What options do I have with NetworkConnection in that case? [/quote] Use TLS-PKI. To start you out, lemme point you at two posts: TLS for App Developers TLS For Accessory Developers The first defines key terminology. The second offers some suggestions for how to deploy TLS in local environment. While TLS-PSK is an option in that context, it’s not required. Indeed, most of that post covers options that use TLS-PKI. Regarding the better path and viability handlers, these are conceptually the same as the equivalent constructs in the old APIs, so you can look for information about those old APIs and map that to this API. The better path handler is typically not necessary in a peer-to-peer context. It’s more commonly used to handle the switch between WWAN and Wi-Fi. See Extra-ordinary Networking > Network Interface Techniques > A Better Path. OTOH, a viability handler is a good idea in most cases. I actually hav

Hi Kevin, The data corruption issue has been resolved! Special thanks for asking the key question: So what's IS there? This prompted us to shift our focus from high-level hash verification to inspecting the raw bytes written to the disk. This investigation revealed that the root cause was not related to cache flushing, but rather a hardware limitation regarding single transfer lengths. Here is a summary of our findings and the solution: By using a Python script to verify the data on disk byte-by-byte, we discovered: When macOS coalesced writes into 2MB chunks (as we had previously set maxTransferSize to 128MB), data corruption consistently began exactly at Offset 1MB + 16KB within the command (manifesting as 0x00 or garbage data). The LSI 3108 controller/firmware seems cannot correctly handle a single SCSI command with a data length exceeding 1MB in the DEXT environment. We implemented a two-layer fix: In UserGetDMASpecification, we explicitly set maxTransferSize to 1MB (1,048,576 bytes). This forces

Hi, thanks for your answer! Technically it works this way, but with a few drawbacks (button group displayed outside the sidebar and no animation when toggling the sidebar visibility). I'm doing the toggling like this: Button { self.columnVisibility = self.columnVisibility == NavigationSplitViewVisibility.detailOnly ? NavigationSplitViewVisibility.automatic : NavigationSplitViewVisibility.detailOnly } label: { Image(systemName: sidebar.left) } Is there any way to also enable the sliding animation it does when using the built-in toggle switch? Any other ideas how apple does it in their apps? Thanks! Jan

Hi @jdeats, The /usermigrationinfo endpoint is intended to be used by both developer teams to perform the user migration for Sign in with Apple: the transferring team uses the endpoint to generate transfer IDs the recipient team uses the endpoint to exchange transfer IDs with user credentials, such as the user's relay email address and user ID associated with their developer team Both teams must provide the client ID associated with the user's session in these requests (as well as the /token requests for access tokens, if needed. The value for the client ID could be either the app's bundle ID or the Services ID for the developer team that was granted access to the user's data. The Services ID should have been automatically transferred with the app (unless it was associated with an app ID that was the parent app of an app group), so I'd suggest submitting a bug report via Feedback Assistant so we can resolve this for you. Please follow the steps outlined in the post below and reply here with your Feed

Hi, For native apps, Sign in with Apple uses the bundle ID as its client identifier (ID); for websites or apps on other platforms, the Services ID associated with the primary app ID is used instead. For an individual app, migrating to a Team ID App ID prefix will not cause any issues with your Sign in with Apple implementation. However, if you plan to use app groups for Sign in with Apple, you'll want to ensure that all child apps have the same App ID prefix as the primary app. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

So using the class constructor is pretty much the only reasonable way around this. I'm marking this reply as the correct answer. You can also avoid the crash by setting UIDesignRequiresCompatibility to YES in your Info.plist and use the pre Liquid Glass UI. maybe I'd file a bug but I don't think Apple responded to like 95% of my Catalyst bugs I reported in the past. I must have reported more than a dozen so I'm not going to be filing this one. FYI if you migrate to the group class constructor... if you have to do any per item tweaks you can apparently just dig in the subitems array right after you create the GroupItem (to set different actions on particular subitems etc.) HOPEFULLY they don't release an update that breaks that.

Ya using +groupWithItemIdentifier:images:selectionMode:labels:target:action: avoids the crash. So under this API design am I permitted to do this? NSToolbarItemGroup *readStatusToolbarGroup = [NSToolbarItemGroup groupWithItemIdentifier:itemIdentifier images:@[mailOpenEnvelopeImage, mailBadgedEnvelopeImage] selectionMode:NSToolbarItemGroupSelectionModeSelectOne labels:@[@Read,@Unread] target:nil action:nil]; NSUInteger i = 0; for (NSToolbarItem *aItem in readStatusToolbarGroup.subitems) { if (i == 0) { aItem.action = @selector(markRead:); aItem.toolTip = @Tooltip for this one..; } else if (i == 1) { aItem.action = @selector(markUnread:); aItem.toolTip = @Tooltip for this one...; } i++; } This API design is not very good TBH. I'm not really happy about having to rewrite the code to build four toolbar groups (I already did this work). I'd like to move forward instead of running in place all the time. BTW the appearance of the toolbar groups don't look particularly special when created via the group