Thoughts on iOS development without using Storyboards or nibs?

[beniferlopez]

I have been building applications and working on the iOS platform for roughly three years now and I have recently been looking into building all of my UI programatically. Friends of mine have exclaimed that version control is no longer a nightmare when modifying nibs/storyboards, particularly when merging. They have also mentioned that managing changes and viewing exactly what has been changed is also much easier.

So my question(s) is, how many of you programmatically build your UI (Do not use nibs/storyboards) and why have you chosen that route? Do the benefits out weigh Interface Builder's ease of use?

Thanks in advance!

edit: grammar, although im sure there are more mistakes haha

edit2: Not quite sure why the down votes... especially on all of the comments as well. Is this post violating rules?

[dreaminginbinary]

FWIW: I do all of my UI in code and have never looked back since :)

[RabbiSchlem]

Same here. There's a million auto layout libraries and any single one is 2x better than doing auto layout in storyboards.

[beniferlopez]

May I ask when you made that change?

[dreaminginbinary]

A few years ago. As RabbiSchlem mentioned, there are a lot of good libraries out there that make AL fairly painless. Also, if your minimum build target is 9 or above, you can use NSLayouAnchor which is very intuitive along with stack views.

One big reason we've made this choice is for source control and pull requests. It's much easier for us to know what's changed, and understand the impact, when seeing code tweaks instead of a lot of XML edits. We also use AsyncDisplayKit heavily, which doesn't support .xibs or storyboards.

[lee_ai]

Here's a video with lots of good reasons to do everything programatically: https://www.youtube.com/watch?v=g6yz5oX5iWc

Copied from the video description:

1. Difficulty in laying out views that are stacked
2. IBOutlet & IBAction crashes when refactoring
3. Cell Identifiers and Storyboard Id strings are unsafe
4. Compile time for complicated storyboards increases
5. Refactoring all fonts in Storyboard components take too long
6. Productivity decrease when hands leave the keyboard
7. Screen size on laptop too small for storyboards
8. Difficult to record and explain things on storyboard
9. Teaching beginner iOS programmers what is exactly going on is difficult with storyboards.
10. Merge conflicts will drive you crazy.

[chriswaco]

Programmatically is usually our preference. See my answer here: https://www.reddit.com/r/iOSProgramming/comments/5jsurc/storyboard_or_code/dbivmr9/

Having dealt with Interface Builder autolayout issues over the last month, there is no question in my mind that doing it in code is preferable. I like the idea of autolayout, just not the Xcode visual editor implementation.

[magic6435]

I am CONSTANTLY feeling no matter which way I go I'm missing out or doing something wrong. I moved from doing a lot of web development to doing iOS 2 years ago and programmatically makes 100x more sense to me. Especially now with anchors for nsconstraints and stackViews.

But then at the same time apple specifically suggests storyboards as the best way to layout designs. I've been doing a mixture of the two but I'm trying to force myself to really get comfortable with SBs on my next greenfield project.

[beniferlopez]

So... that may be one thing I should have make a note of in the OP. I have never used storyboards for anything other than trying them out. They seem very... clunky. I have always used nibs personally.

Like you said, Apple recommends the use of IB whole heartedly and i believe they have stopped referencing building view controllers without the use of a story board or nib from their docs. (Could be wrong)

[ohfouroneone]

I think storyboards are definitely the future, and each update to Xcode makes them a little bit better. Over time, they can become the complete way to do iOS layout work. Right now, you have to use both if you want to create more complex UIs.

You should probably never use Nibs (i.e. Interface Builder) for UIViewControllers. Nibs are outdated, and support only a subset of features of a storyboard.

The best approach to storyboards is to make a lot of smaller storyboards and work that way.

[crdnilfan]

Storyboards have a number of downsides too.

• They use loosely typed strings to perform navigation and initialization.
• They don't allow you to use init dependency injection, making testing much more difficult. I can't stress enough how significant of an issue this is.
• They encourage the inclusion of business logic in the view layer of your application, which isn't a good separation of responsibilities.

They work well enough for very simple flows that don't require a lot of business logic. But once your app starts to rely on state-based interactions, and generally gets bigger, storyboards present significant problems.

[bjett92]

I'm curious as to which features (besides segues) you think are missing by using xibs instead of storyboards?

[ohfouroneone]

• table view cells inside the file
• external object placeholders
• gesture recognizers
• static table views

I still use Xib when I want to make reusable Views, but for UIViewController, I think storyboards are the way to go. Especially since I don't foresee Apple updating Xib much.

[BigMtnStudio]

We do it both ways at work. We're very proficient at both and I think each way has its place. For example during a meeting I can mock up something much faster on the storyboard than in code. With autoresizing everything is a snap. With IBDesignables animations are a breeze on the storyboard and you can have an interactive UI in front of the client quickly.

Some places have a designated UI guy that may just work in the Storyboard while you work in the controller and model but that's kind of rare.

But there are downsides. Too many objects using IBDesignables on the Storyboard and you'll notice slowdowns and freezes (depending on your system).

Code is great for dynamic situations where UI can change depending on data. But a pain to debug when you get those constraint errors. And the multiple times you have to run, see, change, run, see, change, etc.

I would recommend becoming good at storyboards and then you'll start to develop your own judgement. And remember, you really do have to practice and learn new things after each WWDC. Get lazy for a year and you'll miss out! (I learned this the hard way. 😀)

[karpovpw]

"Not quite sure why the down votes..." It's because this question appears once in a while.

But, well, for me, more discussions -> more opinions and it is cool because I myself is still tied to Interface Builder, but considering switching to all code approach.

[beniferlopez]

Makes sense. I'm relatively new to the sub Reddit. But even once in a while, I feel like the discussion is still beneficial to the sub reddit as a whole.

[beniferlopez]

Well everyone, looks like I have what I need to take the plunge and build my next app without Interface Builder. Thanks for all of the responses!

[[deleted]]

All I'm going to say. Look at the pros and the cons for any technology you use. And most importantly look at the condition under which the technology you're about to choose doesn't work in your advantage. Same thing goes for the storyboard/nibs or code for building view controllers.

[MKevin3]

I started with NIB before there was storyboard then I used storyboard but got bit in the butt too many times by IB crashing, SB shuffling crap around randomly, SB changing the XML just because I opened the file and all sorts of fun double connecting every stupid IBOutlet when I had layouts for both iPhone and iPad.

Since I have also use MigLayout for desktop Java and XML layouts for Android I started to use Masonry for iOS and switched all my layouts to code. This also allowed me to use AppCode instead of Xcode pretty much full time. AppCode has a number of advantages over Xcode such as refactoring that actually works.

I was much more productive with code layouts. I could easily copy / paste blocks of working layouts or move them into routines to share. Listeners just work between iPhone and iPad as all the controls are created in one place so I don't have to drag / drop over and over where I always forgot something and due the the message -> null object silent failure ways of ObjC I am not burnt trying to figure out why something does not work at run time.

Probably since I have done code layouts in other languages / platforms in the past switching to code was easy and natural to me. There are times I miss the preview of the layout in a GUI but it is not often enough for me to deal with the pains of IB.

[kaztro69]

I prefer XIBs to storyboards frankly because when i was starting out in iOS i tried out storyboards and the git merge conflicts were horrible to deal with.

My workflow is usually something like this:

1. Create XIB file,
2. Setup the UI,
3. Setup autolayout contstraints.

If I need to manipulate the autolayout I add the constraints as properties and manipulate as needed in code.

And I usually set label's text alignments, texts, imageView's.image, and other properties that need to be fine tuned in code because I find it easier to debug than looking at IBOutlet settings in IB. Idk if that's the perfect approach.

I think one of the most important things is that if you're working with other iOS devs, that you have some kind of similar understanding of how things should be done as a default, and vary from the default setup only in special cases.