A Summary of the WWDC25 Group Lab

Thank you for your reply. I think my previous message might have caused some confusion. What I meant is that I want my existing app, which is already available on the App Store, to connect to the local Docker socket. I am not trying to connect to a socket that belongs to one of my own apps. The Docker socket is a system resource and not part of any of my apps, and as far as I understand, I cannot assign it to an app group

[quote='844266022, Typ0genius, /thread/788364?answerId=844266022#844266022, /profile/Typ0genius'] I’m planning to add functionality to connect to the local socket in one of my existing apps. [/quote] Cool. There is a path forward for this, although it may require you to update your existing app. The following should work: Allocate an app group for this task. Sign both apps to claim access to that app group. Have the server create its listener socket in the app group container. And the client connect to that socket in the app group container. Of course, if your existing app has created the listener socket in some other location, you’ll have to update it to change that (or add an additional listener socket, if you need to maintain compatibility with existing clients). App groups are tricky on the Mac; for the full backstory, read App Groups: macOS vs iOS: Working Towards Harmony. Either flavour of app group ID should work for this; you just need acc

@lijiaxu Adding to what Greg said, I recommend reviewing the section Prepare assets for gameplay for our WWDC25 sample Petite Asteroids. This article describes the process of loading complex geometry and using it to generate a collision mesh. Thank you for your question!

Posting this here as a summary for the three people left writing native macOS apps using AppKit, who might stumble here from a search. macOS 26 has brought us the yearly facelift that – as tradition – brings no break-through features or discernible improvement to usability (quite the opposite, this time around). This year’s diktat from Marketing has also brought a regression that affects how AppKit reconstructs and displays UIs in XIB/NIB files. (Haven't checked if this exists on UIKit too.) If you had carefully laid out your controls to be aligned without the assistance of auto-layout, reopening these files with Xcode 26 will show all controls to be misaligned. This same problem is sadly visible at runtime too. AppKit has removed the crucial distinction between frame rectangles and alignment rectangles. You would be spared from this problem only if your controls were participating in auto-layout by having at least one constraint, or by calling -[NSView setTranslatesAutoresizingMaskIntoConstraints:YE

I went to a WWDC25 SwiftUI Lab regarding this issue. The suggested known workaround was to wrap the 2nd property change in a DispatchQueue.main.async call so that it happens on the next turn of the run loop. You can see my change here: https://github.com/bolsinga/site/pull/1024

I’m not sure why you’re having problems with this. Lemme walk you through how I tested this today. You can review my steps to see if there’s anything obviously different. And if there isn’t, you can run through the steps yourself to see if you can repeat my experience. If so, you can then compare your primary daemon to your test daemon to see what’s different. So, here’s what I did: Using Xcode 16.4 on macOS 15.5, I created a new project from the macOS > App template. I set it up as a daemon per the advice in Signing a daemon with a restricted entitlement. Note that the details will differ a bit but the final result will be the same. Specifically, here’s my final structure: % find Test791996.app Test791996.app Test791996.app/Contents Test791996.app/Contents/_CodeSignature Test791996.app/Contents/_CodeSignature/CodeResources Test791996.app/Contents/MacOS Test791996.app/Contents/MacOS/Test791996 Test791996.app/Contents/embedded.provisionprofile Test791996.app/Contents/Info.plist Test791996.app/Contents/PkgIn

[quote='793977021, neil218, /thread/793977, /profile/neil218'] I attempted to codesign my native dynamic library (.dylib) with an entitlement [/quote] That won’t work. Entitlements are only relevant to a main executable. If you sign library code with an entitlement it is, at best, ignored. Creating distribution-signed code for macOS has general guidelines for signing Mac code and it specifically calls this out. Expanding on this a little, when a process runs an executable, the system checks the entitlements claimed by that executable. If all the entitlements are authorised by the executable’s profile [1], the process starts running that program and gains those entitlements. If not, the system kills the process [2]. So, to get this to work you have to change how you sign your app as a whole. This can be tricky. I usually recommend that Java developers start Java by way of a native trampoline. See the info and links in the TCC and Main Executables section of On File System Permissions. However, that trampoline