Storyboards/Nibs vs. Doing Everything With Code in iOS

When you start working on a new app, one major decision that needs to be made is whether you want to do all of the interface work graphically (through xibs/storyboards) or programatically. Each method has pros and cons. Hopefully this post will help you make the best choice for your project!

Why Storyboards are Actually Really Cool…

With my experience, I have found that the best time to use interface tools to build your app is when you are quickly prototyping something by yourself. If you are at a hackathon, or playing around with a new app idea, doing all the interface work in storyboards is actually quite ideal. You can very quickly iterate and pump out a half decent functioning app in very little time. Additionally, if you are just beginning iOS, it is incredibly helpful to have the ability to visualize how code is linked up to a functioning interface. Even though I usually don’t use interface builder in projects now, it greatly helped my understanding of iOS development by allowing me to visually link snippets of code to the graphics I would see on the screen. This is really cool, and makes concepts that can be hard to comprehend very intuitive. 

Why Storyboards Aren’t Always that Great…

So, even though Interface Builder and Storyboards are a really cool technology and are fantastic when learning and prototyping things on iOS, as you begin dealing with source control and collaborating with other developers, you will rapidly run into issues. For example, lets say I am on a team of developers, and by accident two developers fix the same bug or add or overwrite something on the same view using storyboards. This will cause a merge conflict (assuming you are doing source control with git). Now, since the actual interface “code” generated by Interface Builder is non-readable xml, it can be nearly impossibly to fix even the smallest merge conflict in a massive storyboard file. This could lead to massive amounts of work being lost or corrupted. This is a very bad thing. 

Next, since storyboards are essentially a level of abstraction on Cocoa, it can be much harder to do customization of UI. For example, if I wanted to recreate the now popular interface flow of sliding the main view controller to the right to access the side menu view controller, I would have to get a reference to the two view controllers and navigation controller stack.  If I built the app doing everything programmatically, this would be fairly straightforward and also be pretty clean code. With Storyboards however, just to get a reference to a single view controller I would have to do something like this:

MyViewController *controller = (MyViewController*)[mainStoryboard
instantiateViewControllerWithIdentifier: @”<Controller ID>”];

This is kind of gross and unnecessarily long code. Also, with this additional abstraction, it could be much harder to track down small bugs and other flaws. 

Finally, if you are working on a very large project over the course of a few months, if you have everything involving the interface in one place organized by the name of the view it is way easier to track down what happens where, and know where to add or remove code. If you have parts of interface “code” in a storyboard and part of what is driving the interface living in a .m file, it can become very confusing as to what actually controls what. 




Developing for iOS by yourself vs. on a team.

When developing for iOS on a team of several other iOS devs, the way you approach and architect the overall project should be different from the way you would personally build an app. Neither approach is “better code” but each method simply allows for time to be saved in each situation. 

When developing an app on your own, it may be beneficial to use storyboards and .xib files in your project. The reason you want to avoid using these graphical files in a team setting is mostly version control. Since these graphical files automatically create large XML files that then compile into interface code, merge conflicts often occur when several people touch the same interface files. When you are working by yourself, since you will likely be the only person working on the file at one given point in time, merge conflicts should not occur. Additionally, writing all code for the interface may give more flexibility and allows for more customization of interface elements. 

When creating the overall flow of the app and figuring out a good code organization pattern, be sure to make code as modular as possible in a team setting. Although this is always a good practice even when working on your own private project, it is essential when on a team. Over this past summer, while working at Path, I quickly learned the benefit of modular code. One of the other iOS engineers on the team and I were working on the same view, and we needed the ability to easily delegate tasks on the feature we were working on. Since we were not using Interface Builder, and making sure to use modular code, he worked on one aspect of the feature as a subview, while I built the rest of it. Since we were not sure how exactly we wanted to implement the UI, by creating a View Controller that looked for the same properties on a subview, we could easily test and swap out different implementations. This saved us a massive amount of time and allowed us to effectively accomplish tasks.