I figured out the issue: I was using the same series ID's between the two, even though there were separate. If I make sure they are unique it works.

I'm the same boat. I have a new Mac Studio Ultra but my iOS app's main dependency currently only builds for x86 for simulators. I can't seem to force all the SPM packages it relies on to build x86 simulator versions :( Apple really needs an Xcode setting to tell SPM how to build. It seems CocoaPods can do this https://blog.sudeium.com/2021/06/18/build-for-x86-simulator-on-apple-silicon-macs/

OK, some digging on StackOverflow shows that "On My iPhone" is indeed a separate area called "File Provider Storage". You can add files to this area by dragging over the simulator. I don't think there is any way for a normal app to copy to this folder. So what I wound up doing for my app is to have my own picker for "built-in" files and have a separate command to use the UIDocumentPickerViewController to pick files that are not internal to the app.

Started happening to me too at the same time. DTS told me Apple just turned on throttling and to file a bug report about it. I want to make sure my code is waiting before submitting a bug.

Same issue here. Alas the workaround doesn't work in my case. I am using a @State variable to store the isActive state and I had noticed it being false after I had set it to true during some renders of the body property. It renders the body with it true then all of a sudden it is false. Its almost like SwiftUI created a totally new View. I tried putting the isActive state in my view model (I have an MVVM app) but I was able to watch it getting set to false through no action on my own (I guess when SwiftUI popped the newly pushed on view.) I also noticed my viewModel (passed via @EnviromentObject) was also nil during some of the body property calls.