4 ms·

I did my first iOS development about a couple of years ago. Question, how in the world do you tolerate the storyboard XML files? One small change in XCode res

I did my first iOS development about a couple of years ago. Question, how in the world do you tolerate the storyboard XML files? One small change in XCode results in so many line changes. PRs are impossible to review with any confidence.

0x0 3y ago
Answer: Don't use storyboards.
ben_w 3y ago
That's a big argument for SwiftUI, which replaces storyboards. 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.
- roopepal 3y ago
  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).
plagiarist 3y ago
Do everything programmatically. Especially because the XML is not (last I checked) compile-time validated against the symbols it is using.

0x0 3y ago

Answer: Don't use storyboards.

ben_w 3y ago

That's a big argument for SwiftUI, which replaces storyboards. 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.

roopepal 3y ago
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).

plagiarist 3y ago

Do everything programmatically. Especially because the XML is not (last I checked) compile-time validated against the symbols it is using.