@Bill3D and @dylanabsil, as I updated above, I opened FB14697134 for this issue. Apple initially replied that I should update 3rd parties (without explaining which ones) and then looking at my logs said that this happened because something I did in my code and they closed the feedback. But I showed that I had everything updated and that they got the timing wrong in my logs and they re-opened the feedback. But it's been open like this for quite some time without any update. In another feedback I opened for another issue I got an update that a potential fix was identified for a future update; I didn't get anything like that for this feedback so right now it doesn't look very promising. I therefore suggest that you both also open a feedback on this issue so that Apple engineers will understand that there is a demand for this to be fixed. If you'll look at my feedback you'll see that it says: "Recent Similar Reports: Less than 10". So let's make sure they understand that we need a fix. Also, @Bill3D, your issue is with RealityKit and mine was with ARKit so that means the issue is wider than what I originally reported so you should mention that as well. Let's hope for the best. Thanks.

How did you finally get this issue resolved? I got the same exact rejection. Thanks.

Thanks! I reproduced the issue and filed FB14697134 In the meantime I realized that having app going to background then back to the foreground causes Game Center to re-login on its own so probably the ARSCNView gets to work properly and then Game Center kicks in and that's why it's working in this case. To test this out, I moved the whole GameKit user authentication code from VC1 to VC3 and that way it also works fine (but I obviously don't want the Game Center graphics in the middle of my gameplay). So this issue only happens if the access point is activated before the ARSCNView is activated.

Looks like this issue has been resolved in Xcode 16.0 beta 2 (at least that's what I'm using now). I can run agvtool bump -all and it won't break anything and next build will run just fine. However, I was only able to run it as a script as a build post-action. If I put it as a build pre-action or as a build phase, the build will just cancel.

Probably my initial understanding that using a pivot and compensating by moving the node "the user will never be in the correct "real" position inside the node" was wrong and in fact the user will be in the correct position. In fact, I can use the simdConvertPosition( to: ) function to get the equivalent position in the node's or real world coordinates. So what I asked above is probably impossible. Resetting the pivot will move everything accordingly - it won't keep what was moved with a previous pivot in place. So I went back to continually using the pivot and compensating for the node's movement.

I found the solution. Actually, the problem I had was not even described as I didn't think it was relevant. I built the node 2 meters in front of the origin while the center of my node was still at the origin. So when I changed the rotation or eulerAngles, it rotated around the origin so my node moved in a large curve and in fact also changed its position as a result. The solution was to use a pivot. Instead of changing the position and rotation of the node itself, I created a translation matrix and a rotation matrix which was at the point of the camera (where the user is standing) and I then multiplied both matrices. This would in effect freeze the node showing exactly what the user was seeing before it was frozen as the position is the same and the rotation is exactly around the user's standing position.

Hi, I'm still struggling with this issue. Following what was replied above in #2, I'm currently not using an anchor because I don't necessarily need to find a flat surface. Rather, my node is placed at a certain position relative to where we start at (0,0,0). I have the following code which I'm still stuck with. When I add the node to the camera (pointOfView, last line of the code below), it does freeze in place, but I can't get it to freeze in the same position and orientation as it was before it was frozen. @IBAction func pauseButtonClicked(_ sender: UIButton) { let currentPosition = sceneView.pointOfView?.position let currentEulerAngles = sceneView.pointOfView?.eulerAngles var internalNodeTraversal = lastNodeRootPosition - currentPosition! // for now, lastNodeRootPosition is (0,0,0) internalNodeTraversal.y = lastNodeRootPosition.y + 20 // just so it’s positioned a little higher in front of the camera myNode?.removeFromParentNode() // remove the node from the Real World view. Looks like this line has no effect and just adding the node as a child to the camera (pointOfView) is enough, but it feels more right to do this anyway. myNode?.position = internalNodeTraversal // the whole node is moved respectively in the opposite direction from the root to where I’m standing to reposition the camera in my current position inside the node // myNode?.eulerAngles = (currentEulerAngles! * -1) — this code put the whole node in weird positions so I removed it myNode?.eulerAngles.y = currentEulerAngles!.y * -1 // opposite orientation of the node so the camera will be oriented in the same direction myNode?.eulerAngles.x = 0.3 // just tilting it up a little bit to have a better view, more similar to the view as before it was locked to the camera // I don’t think I need to change the eulerAngles.z myNode!.convertPosition(internalNodeTraversal, to: sceneView.pointOfView) // I’m not sure I wrote this correctly. Also, this line doesn’t seem tp change anything sceneView.pointOfView?.addChildNode(myNode!) // attaching the node to the camera so it will remain stuck while the user moves around until the button is released } So I first calculate where in the node I'm currently standing and then I change the position of the node in the opposite direction so that the camera will now be in that position. That seems to be correct. Now I need to change the orientation of the node so that it will point in the right direction and here things get funky. I've been trying so many things for days now. I use the eulerAngles for the orientation. If I set the whole vector multiplied by -1, it would show weird orientations. I ended up only using the eulerAngles.y which is the left/right orientation and I hardcoded the x orientation (up/down). Ultimately what I have in the code above is the closest that I was able to get. If I'm pointing straight, the freeze will be correct. If I turn just a little bit, the freeze will be pretty close as well. Almost the same as what the user saw before the freeze. But the more I turn, the more the frozen image is off and more slanted. At some point (say I turn 50 or 60 degrees to the side) the whole node is off the camera and cannot be seen. Somehow I have a feeling that there must be an easier and more correct way to achieve the above. In the reply above you wrote to "transform the anchor's position (in world coordinates) to camera coordinates". For that reason I added the "convertPosition" function in my code, but a) I'm not sure I used it correctly and b) it doesn't seem to change anything in my code if I have that line or not. Is that what you meant I should be doing at all? What am I doing wrong? Any help would be very much appreciated. Thanks!

Thanks a lot for this answer! I will need to learn this more in depth to understand how to transform these coordinates and how to anchor to the camera. What about rotation? Will I also need to retain the rotation so that the user will continue to point in the same direction relative to the scene? And for step 3, does that mean that I simply move the anchor again to the starting position relative to the current real position? Thanks! That's very helpful.