But if you must use them, keep each storyboard small enough it's only going to be used by one dev at a time to avoid conflicts, and then combine trusting the GUI won't make stupid XML plus some automated UI tests to make sure functionality isn't damaged by e.g. a button being deleted.
You can build UIs without storyboards/Interface Builder in UIKit just fine. And writing your UI in code indeed easily solves the whole versioning conflicts issue that storyboards have.
So no, not a big argument for SwiftUI, but instead for writing UIs in code.
SwiftUI vs. UIKit and IB vs. code are two entirely separate discussions.
But yes, I totally agree, if you must use storyboards, keep them as small as possible.
Unless I've missed something, by doing the latter it automatically also does the former?
> You can build UIs without storyboards/Interface Builder in UIKit just fine.
Eh, perhaps the examples I've worked with of that were especially egregious (it's certainly possible given some of the other things very very wrong with that code), but my experience of such a codebase was very much not fine.
UIKit works okay in code. But unless you have experienced people actively laying groundwork, it's IMO more likely to be a mess than SwiftUI. Even the explicitly declarative part, Autolayout, will only be understood by like 10% of the team and the rest are kinda winging it. Using Autolayout outside of Storyboards makes it less declarative, so it is then more conducive to programmer error (like non-idempotent updates).