I don't know if Apple will answer this, but from my experience using a number of devices I suspect Apple uses a combination of Standard wide lens Ultra wide lens LiDAR sensor and merges all this data to understand the world around it and the device's location in that world. The more combination of sensors Apple can leverage on a given device, the more effective the tracking is, so the better the experience is. A device with a single standard wide lens will do (but you do need to move the device side-to-side to help it triangulate depth). Wide + Ultra wide lens is better. Wide + Ultra wide + LiDAR is pretty sweet.

Thanks maxxfrazer. That got me pointed in the right direction. I also found your MultipeerHelper project which has helped me understand a little better how the pieces fit together in a local environment.

Figured it out: the AnchorEntity's anchorIdentifier property holds a UUID that I can use to find the original ARAnchor.

Update: I checked the Entity's initial rotation rotation (simd_quatf) and destination rotation used in move(to:relativeTo:duration:timingFunction:), and then I checked the Entity's rotation after the animation completes. The axis Y component after the animation completed has flipped (and so the angle has changed accordingly) Here is what I get "normally" (or at least how I expected) The Final angle and axis are the same as the destination I gave to the animation function: Initial Angle: 171.89, Vector: 0.00, 1.00, 0.00 Destination Angle: 206.26, Vector: 0.00, 1.00, 0.00 Final Angle: 206.26, Vector: 0.00, 1.00, 0.00 Here is what I get just prior to the unexpected behavior: Initial Angle: 206.26, Vector: 0.00, 1.00, 0.00 Destination Angle: 240.64, Vector: 0.00, 1.00, 0.00 Final Angle: 119.36, Vector: 0.00, -1.00, 0.00 Note the Y component of the axis has flipped and the angle is 119.3 = 360 - 240.64. I had not counted on the Y axis flipping. I guess the answer is not to assume the axes (and angle) after the animation completes are the same as the axes (and angle) supplied as the destination Transform in the move(to:relativeTo:duration:timingFunction:) function.

I have the iPhone 12 Pro Max and my wife has the most recent iPad Pro. I use both for testing AR apps, and I have generally found overall the iPhone 12 Pro Max is a snappier experience. I don't know how much of that is due to the difference in CPUs (my iPhone has an A14 while the iPad Pro has an A12Z) vs. the amount of pixels each has to push to the screen (iPhone 2778‑by‑1284, iPad 2388-by-1668) vs. different LiDAR generations (Apple doesn't specify this). While the iPhone is qualitatively snappier to me, the iPad provides a more immersive experience because of the larger screen. So snappier vs. more immersive. One warning: there have been pretty steady rumors that Apple will release a new iPad Pro very soon. Another warning: I haven't found an elegant way to convert the ARMeshGeometry Apple provides in an ARMeshAnchor (things that live in ARKit land) to a MeshResource for a ModelComponent (things that live in RealityKit land). I am hoping Apple provides a richer API for MeshResource in the next release. Another warning: Turning on occlusion with LiDAR equipped iOS devices is awesome! You won't want to go back to non-LiDAR life afterwards.

Getting a similar error when trying to download Xcode 13 beta 5 for my Mac (M1 running 12.0 Beta (21A5304g)) today (2021-08-13): "https://download.developer.apple.com/Developer_Tools/Xcode_13_beta_5/Xcode_13_beta_5.xip". The error is: "cannot decode raw data" (NSURLErrorDomain:-1015)

I've tested this on the iPadOS 15.0 beta (19A5318f), and it appears to be working. I'm going to mark this as resolved (i.e., once the new OS ships in the fall).

Found a work around. I replaced let newAnchor = AnchorEntity(raycastResult: result) with let newAnchor = AnchorEntity(world: result.worldTransform) and I get expected results in both iOS 14.7 and iPadOS 15. I don't know why I get different behaviors between iOS 14 and iPadOS 15 with the with the old style of getting an AnchorEntity, AnchorEntity(raycastResult: result), but consistent behaviors across iOS 14 and iPadOS 15 with the second approach, AnchorEntity(world: result.worldTransform). I'll leave this marked an unsolved for a day or two hoping someone can suggest why the two initializers create different results on the two OSes.

Thanks guys! If anyone runs across this post in the future, this is the change I made to use reanchor(). I don't know about performance improvements, but for me the code reads cleaner. if let anchorEntity = self.placementAnchorEntity { // Update position of existing AnchorEntity anchorEntity.reanchor(.world(transform: result.worldTransform), preservingWorldTransform: false) return } // First time through, so create placementAnchorEntity and add to scene

BTW, I am running the iOS 15 beta (19A5340a), and I am using RealityKit.

I can't quite tell when you are triggering the animation, but for me, I do not play an animation as soon as the model with an animation is loaded. Instead I wait until my ARSessionDelegate function func session(ARSession, didUpdate: ARFrame) is called. Also, as a side note, in the past only one animation is loaded into the Entity.

One thing you might want to do is print a summary of the contents of a model you just loaded. You can explore the Entity API to see more fields you can print. I like to look at scaling, translation, and rotation values for each entity. For example, from the sample code, add a function after loading the Experience.loadBox() let boxAnchor = try! Experience.loadBox() displayEntityTree(entity: boxAnchor) and then define the function to traverse the tree: func displayEntityTree(entity: Entity, prefix: String = "") { print("\(prefix)type: \(type(of: entity))  name: \(entity.name)") for child in entity.children { displayEntityTree(entity: child, prefix: "\(prefix)*") } } Somewhere in your console output you will probably see something like type: Box  name:  *type: AnchorEntity  name:  **type: Entity  name:  ***type: Entity  name: Steel Box ****type: ModelEntity  name: simpBld_root **type: Entity  name: Ground Plane Later, you could add code to, say, clone the entity names "Steel Box". You might want to look for sample code for raycasting to find a place to put the object. Here is some good documentation to start browsing: https://developer.apple.com/documentation/realitykit/entity https://developer.apple.com/documentation/realitykit If you are really new, I suggest you start with some tutorials on using Xcode, putting buttons on screen, and responding to actions (e.g., someone touching the button). Later you can move into AR. I wouldn't jump into AR cold.

I figured out how to replicate the unexpected behavior and how to solve it. To replicate the bug: I launch the program from Xcode, buy two items in the store, then stop the program via Xcode. Then I launch the program again via Xcode, return to the store view (which shows the two items I purchased earlier with their green checkmarks). I buy a third item, at which point the green checkmarks next to the previously purchased items (from the first run of the program) disappear and are replaced by the prices (indicating I hadn’t bought them). In a nutshell, when I launch the program the second time, the Store's purchasedIdentifiers set is empty. When that set is updated (with a new purchase), the previously purchased items check to see if their product ID is in the set; they aren't; they changed their buttons from green checkmarks to blue buttons with the price. For the curious, the code that initially displays the green checkmark for the previously purchased items sets the variable "isPurchased" in the .onAppear block (see ListCellView), and the code that updates the button (which messes up the previously purchased items in the second run of the program when purchasing a new item) uses the .onChange block. One solution (which might not be elegant) is to replace the line in the .onChange block with the same line in the .onAppear block.

Follow-up: I get the same behavior (enter Apple ID + password, followed by entering password twice more) for first IAP in both TestFlight and when using a sandbox account. A second IAP purchase works as expected (enter your password just once). I took Apple's StoreKit 2 demo app, changed the Bundle ID, created an app on App Store Connect with all the same IAP items in the demo, and purchased items through a sandboxed account. I get the same behavior from Apple's demo code: enter Apple ID + password, followed by entering password twice more. I went ahead and submitted the app for review. I hope the non-TestFlight and non-Sandboxed behavior (i.e., a real user purchase) is better. Fingers crossed!

Follow-up 2: The app was approved, and I tested the In-App Purchase. It worked as expected! :-) So it appears all the extra passwords required (3 altogether for the first purchase) for Sandboxed user and TestFlight testing is just an artifact of the testing process.