I've found that if you instantiate a UITab object with an identifier, you cannot later pass another UITab instance with the same identifier to UITabBarController.tabs. That will cause the exception you mentioned. If you need to set the tabs property more than once, for every identifier, check if you already have a UITab with that identifier and reuse it, otherwise create a new instance. It's quite strange, that this is really necessary.

@DTS Engineer thank you for these suggestions. I've added the full crash report from Crashlytics to this post. After enabling the launch argument you suggested, I managed to reproduce the crash in the debugger once, so that's some progress. After enabling Swift 6 and complete concurrency checking, I got some build errors in the class owning the ModelActor. Wherever I accessed the ModelActor, I got this error: Sending 'self.localStorage.some' risks causing data races. As mentioned in my original post, the ModelActor conforms to a protocol because I am using another type of storage in iOS 16 which doesn't support SwiftData. This protocol didn't require that conforming types were Actors, leading me to suspect that the class owning the ModelActor didn't treat it as an actor, because it only know about the protocol. Adding the Actor requirement to the protocol, removed the build errors in the owning class. Now, I have to ship this change to confirm that it actually fixes it, since I cannot reliably reproduce the crash, but it seems like a good candidate for a fix, wouldn't you say? Thank you for your help! stacktrace.txt

Update: I managed to reproduce the crash and solve it (I think). I had a scenario where the ModelActor in some cases would leak and stay transient after the user logged out. If another user logged in afterwards and another instance of the ModelActor would be created, this crash would occur. After I fixed the leak, the app seemingly no longer crashes. It's still a bit of a mystery to me, why it would crash though. The ModelActors are initialized with their own user-specific database, so they are completely distinct. My theory is that the leaked database could reference some resources that no longer existed after the user logged out and that caused the crash.