A Summary of the WWDC25 Group Lab

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. :(

Sorry for the late answer, this ... Life™ thing came in between... I have a couple of new diagnostic tests for you. The first is a simplification of my original test: In step 2... Did that, result is: -rw-r----- 1 martin staff 2200 16 Jul 21:52 CodeResources Assuming it does, I have the new test that I actually want you to run. Create a new user account in System Settings > Users & Groups, switch to that account Log out of your main account... Did that too, result is this time different! The CodeResources FOLDER has 755, but the Coderesources FILE inside that folder has this, like the above test. So the folder's rights now are fine, file still wrong. :) -rw-r----- 1 martin staff 2200 16 Jul 21:52 CodeResources Best Martin

[quote='793203021, Deej620, /thread/793203, /profile/Deej620'] it seems that the explicit declaration of com.apple.token should not even be required in the entitlements. [/quote] It’s easy to get confused here. Claiming access to the com.apple.token keychain access group is required on iOS but not on macOS. macOS apps get implicit access to that [1]. [quote='793203021, Deej620, /thread/793203, /profile/Deej620'] The only difference is that I'm trying to use a PIV smart card to achieve authentication to a server [/quote] That different might be significant later on, but it’s irrelevant here because you’re not getting past copy-matching stage. [quote='793203021, Deej620, /thread/793203, /profile/Deej620'] I'm getting a -34018 missing entitlement error. [/quote] The -34018 error, errSecMissingEntitlement, is a strong indication that there’s a problem with your claim to com.apple.token. However, you’ve done all the standard debugging stuff, so I’m not sure why this is failing for you. Just to be clear, y

.... AND MORE FUNNY ... I removed the Sandbox entitlement and the Xcode artificial stupidity still want to insert the entitlements !!! ProcessProductPackaging /Users/xxxxx/EoF/DRFXBuilder/DRFXBuilder_sandbox.entitlements /Users/xxxxx/EoF/DRFXBuilder/build/xcode/DRFXBuilder.build/Release/DRFXBuilder.build/DRFXBuilder.app-Simulated.xcent (in target 'DRFXBuilder' from project 'DRFXBuilder') cd /Users/xxxxx/EoF/DRFXBuilder/build/xcode Entitlements: { } builtin-productPackagingUtility /Users/xxxxx/EoF/DRFXBuilder/DRFXBuilder_sandbox.entitlements -entitlements -format xml -o /Users/xxxxx/EoF/DRFXBuilder/build/xcode/DRFXBuilder.build/Release/DRFXBuilder.build/DRFXBuilder.app-Simulated.xcent ProcessProductPackagingDER /Users/xxxxx/EoF/DRFXBuilder/build/xcode/DRFXBuilder.build/Release/DRFXBuilder.build/DRFXBuilder.app-Simulated.xcent /Users/xxxxx/EoF/DRFXBuilder/build/xcode/DRFXBuilder.build/Release/DRFXBuilder.build/DRFXBuilder.app-Simulated.xcent.der (in target 'DRFXBuilder' from project 'DRFXBuilder') cd /Users/xxx

I removed the permissions for a temporary file during the build process. My entitlements file doesn't contain any of the entitlements mentioned. Why does the code sign tool or Xcode's built-in ProductPackagingUtility have to change my decisions? Is this artificial stupidity? ProcessProductPackaging /Users/xxxxx/EoF/DRFXBuilder/DRFXBuilder_sandbox.entitlements /Users/xxxxx/EoF/DRFXBuilder/build/xcode/DRFXBuilder.build/Release/DRFXBuilder.build/DRFXBuilder.app.xcent (in target 'DRFXBuilder' from project 'DRFXBuilder') cd /Users/xxxxx/EoF/DRFXBuilder/build/xcode Entitlements: { com.apple.application-identifier = IDIDIDIDI.org.eof.tools.DRFXBuilder; com.apple.developer.team-identifier = IDIDIDID; com.apple.security.app-sandbox = 1; com.apple.security.application-groups = ( group.org.eof.apps ); com.apple.security.assets.movies.read-write = 1; <<<<- NOT MY DECISION com.apple.security.assets.music.read-write = 1; <<<<- NOT MY DECISION com.apple.security.assets.pictures.read-write =

The code was exactly the same as I am using for all the tips I created (I have about 20 tips scattered across about 8 different views). All of these tips were originally setup as popover tips and I was using TipGroups to control the sequencing. All worked exactly as expected in the simulator but when I ran it on my physical device I started seeing the anomalies. Below is indicative of how I was invoking them all. One thing I did notice about the 2 tips that were displaying as sheets was that they were for buttons at the bottom of the view. Right above them was a list subview that was clearly taking up all the available screen real estate so it was as though the framework didn't think there was enough room to display them as popovers and resorted to using a sheet. There were some other anomalies attaching popovers to sliders. Either they didn't display properly or could not be dismissed. But NONE of this was a problem in the simulator! Everything worked just fine. In frustration I resorted to using TipView for