Sep 19, 2019
For my ally is Storyboard
and powerful ally it is
What’s the single most time-consuming task in UI development?
Adjust it.
Then adjust it again, for all sizes and orientations.
Then adjust it again, for corner cases.
Then adjust it again, because you miss some corner cases.
Then adjust it again, because some values are off-spec.
Then adjust it all over again, because UI changes.
Now do you see the problem?
You have to see it to believe it
How long does it take to build project and navigate to your view?
The whole point of a front-end IDE is so you can see it at design time.
You are working blindly if you write UI codes without preview.
If UI codes are so great, why Apple bothers with XIB, Storyboard, and SwiftUI?
TL;DR
The main problem with SwiftUI is that it only supports iOS13+.
If you can use it, by all means use it.
If not, then use storyboard + xib.
When all else fail, write UI code.
Know your tool
It is true that you cannot resolve XML merge conflicts.
It is true segue prevents you from dependency injection.
It is true large storyboard file is slow and difficult for collaboration.
But did you try to avoid these problems?
Assign projects views so there would be no merge conflicts.
Use storyboard without segue
One view, one developer per storyboard.
And you can have this
let vc = sb() as MyVC
vc.inject(dependency)
router.routeTo(vc)Liar!
Which is more believable?
I can modify storyboard to serve special purpose
or
I can do UI blind
Then you are lost!
Let me pick a google top result
why we don’t use storyboard at insta-bug
Reason #1, Merging and code reviews
Storyboard should be atomic. Even when there’s a conflict of storyboard, you can look at it and determine which branch to take. No need to resolve anything. See? it’s good to be able to see.
Storyboard represents the view of a view controller. It usually works well to use one view controller as one atomic unit.
Code review part is idiotic.
Why does your view need review? You plan on doing crazy shit with it?
Why should I give a shit about you changing background color? You are the sole owner of that view, do whatever you deem necessary. If you do MVC right, what a view looks like is irrelevant to control flow. It’s not like you can validate a view by looking at code anyway.
You can see it just by looking at codes? What is this, Matrix? Get out of my face.
On the contrary, a shit ton of routine UI codes distract reviewer, and one may easily do crazy shit in UI codes. I’ve seen UIView extension presenting view controller. You cannot do that in storyboard, and people won’t mess with your shit in fear of XML conflict.
Reason #2, Reusability
The major problem would be the components defined in storyboard need to be reusable. Storyboard as a whole rarely needs to be reusable. Because in this usage, storyboard represents a view controller, to reuse a storyboard is to reuse a view controller. Usually you would add customization in viewDidLoad.
As for components, you can use XIB with some setup, or plain codes for simpler ones. In practice you don’t need every component to be visually correct in preview, it is a preview after all.
On the other hand, it’s easier said than done writing reusable UI codes. You are assuming all developers are self-disciplined to write highly refactored code. No they most likely write shit. And usually it is the shit-est coder who want to write UI codes the most.
Reason #3, Readability and maintainability
On the other hand, if the UI is created in code, it becomes so much easier to see how and when a view is created and customized.
It is so much harder to see. That’s the whole point of creating a view edtior.
You might as well claim
It is so much easier to see with my eyes closed
A picture is worth a thousand words. A storyboard is worth a document.
You don’t waste time guessing if selectLabel is the label you are looking for. You open storyboard and click the damn label!
Reason #4, Auto layout
Glad you mentioned it. I’ve been using auto-layout on storyboard for 3 years. It still often produced unexpected results.
But I can see the unexpected results in preview and retry immediately.
but we find it so much easier to create Auto Layout constraints in code
There is only one possible case where this statement can be true.
These guys at instabug are literal auto-layout gods.
If you are not a literal auto-layout god, and you attempt creating auto-layout constraints in code, you will try-build-retry-build-retry-build till the end of time.
That is on top of the fact that each component requires 4 constraints, with dependency to each other. Any change could easily cause auto-layout to break and requires you to debug-fix-retry-build-retry-build.
Don’t lecture me about readability and maintainability if you pull this kind of crap.
Since we prefer not to include any third-party dependencies in our code, we cannot use things like SnapKit or PureLayout, but we think they are excellent options for apps.
Yeah, who needs tools when you are literal auto-layout gods.
For those who are beginners to iOS, or struggling with UI codes, don’t take any of these elitist shit. They may have a point 5 years ago, but in 2019 these info are terribly outdated.
Reason #5, Dependency injection
It can be done as shown above. Know your tool.
You must feel the storyboard around you
Here, between you … me … tableView … everywhere!
I went through all common techniques of UI codes, even made a wrapper for PureLayout. I don’t even bother with UI codes now.
Because storyboard wrecked faces.
You don’t use storyboard to do something it is not good for. You use it for what it is best for.
It is best for quick prototyping, while hiding details. Auto-layout constraints are things you don’t want to see, but need to find it quickly when needed. Storyboard gives you exactly that.
Oh did I mention prototype cell?
I saved so much time that I could brute-force UI component without reusability and still had time to spare to fix other people’s UI code.
Looking back I’d call all-UI-code approach insane. You don’t give up your only visual prototyping tool to avoid something as trivial as merge conflict.
There are ways to prevent merge conflict. There’s no replacement for storyboard until SwiftUI.
Conclusion
There are a lot of obsolete info surrounding storyboard. All-UI codes is a trap. You don’t get better by writing tedious codes. You get better by learning your tool and when to do what.
Hope this get to google top results, and help some people.
