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.

Success! In another thread someone mentioned installing older versions of Autodesk software, and that did the trick for me too. (Note: This is still with Monterey 12.2 not the 12.3 beta where I initially had problems) Here is the previous thread where I found the suggestion to try older versions of Autodesk software. https://developer.apple.com/forums/thread/661927

Looks like the optimal lensPosition changes over time. Could temperature change from device usage and ambient temperature changes affect the optimal lensPosition? If so, it looks like I will have to recalibrate lensPosition on a regular basis.

Figured it out! I needed to plug-in my phone and build for the actual device (as opposed to the simulator) Building for Any iOS Device (arm64) works too.

I figured out one way to do it from Apple's source code. I posted the solution here: https://developer.apple.com/forums/thread/724014