SwiftUI against SwiftData is too fragile and error prone

The hardest part of SwiftUI programming is to correctly define the layers of references that you need as your app grows features. When you add Swift data to the mix, it hard to get much of anything correct.

I have an application that interacts with the outside world via BLE and LocationManager. I need to preserve used BLE devices and then store their current state in a static Monitor type class structure. This monitor though, needs to have access to some SwiftData elements, and it is not clear from the documentation whether it's preferred to create multiple ModelContainer instances, when they might share a particular types management. This doesn't feel very safe, so it would then make more sense to have a ModelContainer stuck inside of some other static Monitor object that everyone would use to get the single ModelContainer that should be used.

All of the context specific stacking of references in SwiftUI creates huge dependency chains, and it make the build of my application, currently to take 10s of minutes sometimes, when I have changes in flux and the compiler cannot make heads or tails out of broken references.

We really need to find a way to get the compiler fixed so that as a Recursive Decent parser, it has an easier time finding a terminal state instead of crawling up and down the stack of references looking for a place that it can reach a terminal state.

Not using ';' on every statement is a big part of the problem I feel...

Replies

Then, you're using the wrong hammer for the nail in question. There are many SwitfUI sample apps available that you can use as a reference for the architecture employed by Apple, such as MVC and MVVM. The language is designed to be semicolonless unless multiple statements are being packed into one line, which then calls for a semicolon. This sounds like your first go at SwiftUI and SwiftData. My recommendation will be to study the SwiftData Sample applications such as BackyardbirdsbuildingAnAppWithSwiftData, to see how Apple approached the issue.