In a previous project I needed to create separate USDZ files for each animation - one animation per USDZ file. I loaded the first USDZ model and kept both the model and animation. For additional animations I loaded the USDZ file, kept the animation, and dumped the model part. I could then apply the animations to the full model I loaded first.

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

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.

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.

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

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.

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!

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.