Why We Don't Use Storyboards At Instabug

Should you use Interface Builder and storyboards, or write all your UI in code? This topic has been debated A LOT. There are good arguments on both sides, and every team/project needs are different, so I'm not trying to convince you why one approach is better than the other, but rather tell you why we prefer not to use Interface Builder at Instabug, even with Xcode 9 and all the enhancements Interface Builder got over the years.When I refer to using Interface Builder, I mean using either one of the two methods it offers: storyboards or separate Nib files. While both methods are a bit different and each one has some advantages over the other, this post discusses using either of them versus writing everything in code.Merging and Code ReviewsInterface Builder files aren't human-readable, which makes merge conflicts very hard to resolve. It's not impossible to do, but it's not something you do with confidence like resolving a merge conflict in code.Another problem with Interface Builder files not being human-readable is that you cannot review changes done to them when doing code reviews, which means that unwanted or unintentional changes to UI may happens and slip by in code review.ReusabilityInterface Builder makes it a lot harder to create reusable views. Using storyboards rather than standalone Nib files makes it even harder. Doing something as trivial as reusing a UITableViewCell prototype in two different view controllers is simply not possible.Readability and MaintainabilityIf you use Interface Builder and you have to modify a UI or fix a bug in it, you'll have to keep jumping back and forth between code and Interface Builder due to the fact that all the customizations done to a view cannot be done in a single place. This quickly becomes frustrating and confusing. 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.Auto LayoutThis might be different from one person to another, but we find it so much easier to create Auto Layout constraints in code rather than fiddling with the awkward Interface Builder UI for creating them. We love the NSLayoutAnchor APIs and heavily use them in all new UIs we create. We only dropped support for iOS 8 recently, so before that we used the Visual Format Language, which admittedly isn't the most intuitive, but it still made so much more sense to us compared to setting up constraints in Interface Builder.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.Dependency InjectionWe prefer to use dependency injection to pass a view controller's dependencies while initializing it. This is possible to do with storyboards with approach like the one discussed here, or by simply overriding prepare(for:sender) with something like this:override func prepare(for segue: UIStoryboardSegue, sender: Any?) {if let destination = segue.destination as? SecondViewController {destination.dependency = dependency}}While that works, it's complicating something that should be as simple as passing a few parameters to the view controller's init method.ConclusionAgain, every team has different workflows and preferences, so writing all UIs in code might not make sense to everyone. In fact, I do recommend using Interface Builder for any one that's starting to learn iOS development. They are an easier approach to start with, and they let you get something up and running faster.If you'd like to get your feet wet and start building some UIs without using Interface Builder and storyboard, check this tutorial from Aly Yakan, our iOS SDK engineer.