ahhhh I've just spent ages wondering what's going on with the head anchor transform and I suspected it might be because it's considered sensitive info.. or maybe a bug.. :) anyone heard anything official about it? I'm pretty sure the docs don't mention it

d'oh, I just realised that AnchorEntity(.head) can be used anywhere (shared/immersive/fully immersive) so I get why its transform would be restricted for privacy reasons.. using the ARKit world tracker works fine (since it can only be used in immersive/fully immersive)

just as a followup in case anyone is still wondering.. SCSensitivityAnalyzer does seem to be working as intended now on mac (incl in widgets & the widget simulator), and on device on iOS.. however it doesn't work in the iOS simulator, which may be expected? tho i can't see anything about it in the docs at any rate, the simulator errors i get look like: Error fetching CommSafety configuration from ScreenTime: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.ScreenTimeAgent.communication" UserInfo={NSDebugDescription=connection to service named com.apple.ScreenTimeAgent.communication} and Failed to get contents of directory: /Users/bloop/Library/Developer/CoreSimulator/Devices/7E385B3A-40AF-4CF1-AA9E-723BB46141E7/data/Library/Biome/streams/restricted/SensitiveContentAnalysis.MediaAnalysis/local, error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.biome.access.user was invalidated from this process." UserInfo={NSDebugDescription=The connection to service named com.apple.biome.access.user was invalidated from this process.}

awesome - i've submitted a report here: FB13253394 thanks!

@SwiftNativeDeveloper thank you! I noticed the API mentioned in the release notes, but couldn't find anything in Xcode.. but I had the run destination set to the simulator.. it didn't occur to me it might be device only at this point. interesting!

thanks @J0hn and @gchiste - I'm relieved it isn't just me :) just to make sure i'm understanding :)... I'm not (yet) wanting to use AnchorEntities with physics sim, this is just when using spatial gesture modifiers. are those modifiers using the physics sim under the hood for calculating the tap location (i.e. raycasting as j0hn mentioned)? if i can get the tap location in a coordinate space useable by the anchored entities then i think that'd be fine? the SpatialTapGesture modifier is correctly called when i tap on an anchored entity & reports the correct entity in the event, but I can't figure out how to use the event's location3D to create a new entity that will sit at that tap location under the same AnchorEntity, so in the same coordinate space as the tapped entity. i really want to use the plane detector, but currently only have the simulator to work with. if this is as currently designed then i'll file a request.. just wanted to double check first :) thanks!

ahh thanks @gchiste - i was thinking that was the case. so.. and forgive me because i'm sure i'm missing something straightforward here.. given i want to get the location of a tap on an entity that is a child of an anchor, and create a new entity at that position within the same hierarchy under the anchor... the places where coordinate spaces come into play afaik are: SpatialTapGesture() which can take a coordinateSpace param of either local, global or named value.convert(value.location3D, from: .local, to: .scene) where from can be local, global or named. and to can be scene or an entity and finally the code which creates the entity, sets it's location, and adds it to an entity in the anchor hierarchy tap.position = location3D value.entity.addChild(tap, preservingWorldTransform: true) any idea what the combination of params, coordinate spaces etc i should be using here?

happy new year! :) and exciting news today about the feb 2nd launch!! i just wanted to come back to this as i am stumped.. i'm sure i'm doing something really dumb... this is my test gesture handler.. anchor is an AnchorEntity with a plane target. the grey sphere is a child of the anchor at the anchor's origin, and has a CollisionComponent and an InputTargetComponent. .gesture(SpatialTapGesture().targetedToAnyEntity() .onChanged({ value in }) .onEnded({ value in let material = SimpleMaterial(color: .systemPink, roughness: 0.1, isMetallic: true) let location3D = value.convert(value.location3D, from: .local, to: anchor) // i've tried .scene.. specifying the anchor seems to be slightly closer results. i've also tried .global instead of .local for the from let tap = createSphereEntity(0.01, material: material, interactable: false) anchor.addChild(tap, preservingWorldTransform: false) tap.setPosition(location3D, relativeTo: nil) }) ) i've attached an image of the result i get. as you can see, the "tap" entities that are created are offset from the anchor. i've tried so many combinations of coordinate spaces, preserving world transforms, changing the order of things etc... if the object is not anchored the following code works great for non anchored entities: .gesture(SpatialTapGesture().targetedToAnyEntity() .onChanged({ value in }) .onEnded({ value in let material = SimpleMaterial(color: .systemPink, roughness: 0.1, isMetallic: true) let location3D = value.convert(value.location3D, from: .local, to: .scene) let tap = createSphereEntity(0.01, material: material, interactable: false) value.entity.addChild(tap, preservingWorldTransform: false) tap.setPosition(location3D, relativeTo: nil) }) see the screenshot with the yellow shows the expect results any ideas what i'm doing wrong? :)

d'oh, ok, having thought about it some more i think i see the root of my misunderstanding :) i thought that since i only wanted to work in the anchor's coordinate space it shouldn't be affected by the privacy preserving.. but of course, as it currently stands if that were possible, it'd also be possible to figure out the world space positions of anchors and their children. to be honest, the only reason i want plane AnchorEntities is that they're supported in editor and the ARKit planes api is not.. hoping maybe maybe that will change 🤞

@Patrick Koning sorry, i put my "answer" in a comment above - should've done a proper reply and marked it as answered 😅 yes, i did eventually figure it out - the group id for the mac builds needs to have your team id as a prefix (this is new for sequoia) https://developer.apple.com/documentation/xcode/configuring-app-groups#Create-App-Groups-for-macOS-apps my app was using the Multiplatform project template, and the new group id requirement is not valid for other OS targets... i ended up separating up my app and widget extension targets: macOS and everything else. i can't imagine the stress/pressure folk at apple have been under as part of this release, so this is meant as a sometime future thing.. but it feels like this solution to app groups on macOS could do with a revisit.. losing the ability to have a single target for multiplatform apps with app groups isn't the end of the world, but for me it's nice to keep it all under one target if at all possible.. 😊