@DTS Engineer Thank you. That makes sense. After thinking about this more, I realized that I may not need to completely drop SpatialTrackingSession for every tracking capability. In my case, the important conflict seems to be related to SpatialTrackingSession.Configuration(tracking: [.world]). I did some additional testing, and it appears that if I do not enable .world in SpatialTrackingSession, I can still use other SpatialTrackingSession capabilities such as .hand and .accessory, while using my own ARKitSession with WorldTrackingProvider for persistent WorldAnchors. The main reason I was using SpatialTrackingSession with .world was that it conveniently lets the system manage environment scanning and collision simulation for virtual object placement. If this could coexist with ARKitSession + WorldTrackingProvider, I think it would make development much more convenient. If I move persistent world anchors entirely to ARKitSession + WorldTrackingProvider, then I may need to implement the environment scanning and collision part separately through ARKit. For context, I am developing a feature that scans the user’s environment, exports the spatial data so it can be used in Blender for character animation, and then imports the result back to Vision Pro for AR animation playback. Some virtual object placement in the app relies on environment collision, while placing the animated character back into the AR scene requires persistent world anchors through WorldTrackingProvider.

@DTS Engineer Thank you for the clarification. The FB number mentioned in the previous forum thread was FB16424173. That report was filed by the original poster of that thread, not by me. My newly filed report is FB23420195. I have also updated my Feedback Assistant report and attached a focused minimal Xcode project that demonstrates the issue, instead of only providing a standalone Swift file. Regarding your explanation, yes, that matches my concern as well. If SpatialTrackingSession internally manages its own underlying ARKitSession, then running it together with an explicit ARKitSession + WorldTrackingProvider may cause both sessions to compete for the same world-tracking resources. The main question I have is: if SpatialTrackingSession and ARKitSessionwith WorldTrackingProvider are not intended to be used together for persistent world tracking, is there any recommended way to add and manage persistent WorldAnchor s while keeping SpatialTrackingSession enabled? In my real project, I rely heavily on APIs and features that require SpatialTrackingSession, so I would like to understand if there is a more appropriate way to handle this use case.