Thanks for the answer 🙂 When using ObservableObject for such purposes, when passing a navigation path from it to NavigationStack, there is such a problem that there are many unnecessary calls to navigationDestination and unnecessary reinitialization of View from the entire path https://feedbackassistant.apple.com/feedback/14536210 Yeah, that's true. Though that only really happens when the navigation state changes, which doesn't happen too often (since the ObservableRouter is just a Router, not a view model holding lots of states), and most of the times, the paths aren't that deep for it to have a huge impact, I think. And with @Observable unnecessary redraws should occur even less. Additionally, due to the presence of EnvironmentObject, most likely some operations occur that lead to a loop of this process. Yep, I'd love to understand what that loop actually looks like. That's really tricky to find out, unfortunately. Also, it is better to move navigationDestination as close to NavigationStack as possible, i.e. it is better to move it from MiddleView to ContentView. An example according to your code: Is that the case? I've never heard that before 🤔Do you have a link where this is stated/explained? That would make me rethink some of the architectural decisions in my app. I assumed the entire purpose of that modifier is to place it anywhere in a NavigationStack, even on sub-pages. The problem with moving everything to ContentView is that you lose all modularity. ContentView would be tightly coupled with MiddleView, which is what I really want to avoid. But if you want to leave it the same, you can use the @State variable for the navigation path, which is synchronized with the path from the Navigator, this will also fix the problem for this particular case, and will reduce the number of unnecessary navigationDestination calls and reinitializations to zero (not on all OS versions), example: I've seen this approach a few times. It does work, yeah, but I don't like it very much, to be honest. It kind of defeats the point of SwiftUI and its state mechanisms. This manual synchronisation is exactly what declarative code is trying to get rid of.

That does seem to work around the bug :thinking_face: I think I might be able to change the code to avoid the crash for now with this. Thanks :smiley:

The errors are gone in Xcode 16 Beta 3, so I also assume it was a bug :)

👍I've filed the feedback: FB13855667

Hey, good news, I guess 😅 The previews have started crashing again. I've filed a feedback with the report and the sysdiagnose. Hope it helps 🙂 Feedback ID: FB13847416

Hey, thanks for the reply :) I just started Xcode Beta back up to try and reproduce the issue but now the Previews all work fine. I couldn't make them crash again. I have no idea what changed, I restarted Xcode multiple times yesterday but it kept crashing. Sorry that I cannot provide you with a potentially helpful diagnostics now. I'm going to install the profile nonetheless and try to generate and send you a report whenever the error occurs again.

Well, that's a bummer 😅 Having a second local database and figuring out when and what to copy to the "real" database seems quite complicated 🤔. I'd have to track all incoming changes from CloudKit, map them to their respective tables and then attempt to copy the inserted data (in the correct order) whenever a batch has been handled. If it fails, I try again with the next batch. If it succeeds, I delete the data from the "CloudKit" local database. But that doesn't even cover outgoing changes, which I would have to handle as well. I'm not sure I can do this without missing a gazillion edge cases 😅. But thanks for your answer :) This at least helps me a bit with the decision whether or not I should continue working on iCloud sync. I'm gonna think about this a bit more. Maybe it's possible to do it. I feel like I'm really close, but the lack of data integrity with CloudKit might just be too much.