4 ms·

SwiftUI does not replace storyboards. It replaces UIKit(/AppKit). You can build UIs without storyboards/Interface Builder in UIKit just fine. And writing your

SwiftUI does not replace storyboards. It replaces UIKit(/AppKit). 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.

ben_w 3y ago
> SwiftUI does not replace storyboards. It replaces UIKit(/AppKit). 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.
- watchblob 3y ago
  I have worked with lots of codebases using UIKit constraints in code. These were non-trivial apps (200k lines of code). You can create wrappers of your own to simplify things or use libraries like Snapkit. It works and there's no need to use Storyboards.
  - ben_w 3y ago
    The bad codebase I'm thinking of was 120 kloc. But I'll take your word for it being possible to do better than that example, one example is merely an anecdote.
- plagiarist 3y ago
  I think they want to make the distinction that SwiftUI is not necessarily to replace Storyboards, although it will replace them. 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).

ben_w 3y ago

> SwiftUI does not replace storyboards. It replaces UIKit(/AppKit). 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.

watchblob 3y ago
I have worked with lots of codebases using UIKit constraints in code. These were non-trivial apps (200k lines of code). You can create wrappers of your own to simplify things or use libraries like Snapkit. It works and there's no need to use Storyboards.
- ben_w 3y ago
  The bad codebase I'm thinking of was 120 kloc. But I'll take your word for it being possible to do better than that example, one example is merely an anecdote.
plagiarist 3y ago
I think they want to make the distinction that SwiftUI is not necessarily to replace Storyboards, although it will replace them. 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).