A Summary of the WWDC25 Group Lab

[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

By default, UITabBarController will only change the view controller for root tabs. Apps can manage how the view controller hierarchy changes within that root tab through system callbacks from UITabBarControllerDelegate. Setting managingNavigationController on UITabGroup will opt-in the specified group to allow UITabBarController to automatically manage its hierarchy for you. See this forum comment which has a deeper explanation on how managingNavigationController works, and how you can customize the stack that is built in. You can also watch Make your UIKit app more flexible from WWDC25 which also explains how this API works with examples.

It is July 2025, we are getting the same 401 forbidden when calling registerMerchant API using the top level Account Holder account. We are blocked in building out labs and prepping production environment until resolved.

Let me know if: • The red sphere is visible • Movement now feels trackable • You want right-stick support for turning (rotation) • Or we need to tweak scale/speed/clipping/etc You’re close — this should lock it in. ME: Yes, I see the red sphere, and It moves forward, backwards, left and right. Still no actual camera movement though. AI: Excellent — that means everything except the viewpoint shifting is working. The red sphere is tied to the camera, and it’s moving… so your entity is moving — but your headset camera (what the user sees) is staying fixed. Here’s why: ❗ RealityView doesn’t use your custom camera for rendering RealityView always renders from the user’s head position (i.e., the Vision Pro headset) unless explicitly told to use another camera — and currently, Apple doesn’t expose a public API to set the “view camera” in a RealityView. ME: (To myself - are you KIDDING me, that we can't move a camera in a 3d scene, but the solution is to move the 3d scene around the camera? ARE YOU KIDDING ME?!) AI:

Thanks for filing that enhancement request @Hunter! In addition to what my colleague pointed out, keep in mind that it's important not to overtune your prompts to a specific version, as the models will indeed be updated over time via OS updates. One strategy that could help is to constrain output using guided generation to yield more consistent results. Furthermore, we suggest in this session from WWDC25 that developers evaluate and test responses over time as they update their prompts and as we update the models. This will ensure quality and safety over time. Best, -J

Those log messages look like log noise. Specifically, the first one, the one referencing CFPrefsPlistSource, is something that I see all the time and isn’t a sign of an actual problem. As to what’s going wrong here, it’s hard to say. Let’s start with a simple test: In both your app and your share extension… Add some code that calls the containerURL(forSecurityApplicationGroupIdentifier:) method, passing in the same app group ID that you’re using as your suite name in UserDefaults. And then logs the resulting URL. Do both programs log the same URL? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I went through the steps to reproduce this today and immediately hit a gotcha that’d slipped my mind. When you use Signing & Capabilities > Keychain Sharing to add a keychain access group, Xcode helpfully adds an App ID prefix. Consider: % plutil -p Test793203/Test793203.entitlements { keychain-access-groups => [ 0 => $(AppIdentifierPrefix)com.example.apple-samplecode.Test793203 1 => $(AppIdentifierPrefix)com.apple.token ] } This is correct normally, but is wrong in the com.apple.token case. The com.apple.token keychain access group is not prefixed. If you manually edit the .entitlements file to remove $(AppIdentifierPrefix) on that line, things should start to work. I’ve been bitten by this before. This time I actually filed a bug against Xcode about it (r. 156066253). Past Quinn™ definitely didn’t do his due diligence )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

It feels like since Beta 3, the model seems to have become overly restrictive. Even simple tasks, like generating a title based on a content from a book I am reading or generating a summary from a longer citation are now blocked by guardrails. It’s becoming nearly unusable for basic use cases. :(