To Storyboard or not to Storyboard…

Pepsi or Coke? Soup or Salad? Chips Ahoy or Oreos? When it comes to developing an app, programmers face a far less delicious but equally decisive conundrum: Storyboard or code? At my most recent Girls Develop It Swift class, I asked my instructor her feelings on Storyboard. She gushed about it and said much of the time she tries to write as little code as possible. The next day, I asked a developer for a large media company her feelings on Storyboard and she promptly replied that she never uses it. Ever. So what’s a budding developer supposed to do? Well there is no question that there are pro’s and con’s to both and that both skills are important to have, but how does one choose between using Storyboard and not for a particular project.

As You Like It

A lot of the time, the use of Storyboards/XIBs versus making views programmatically is a matter of personal preference. I personally learned how to create views in Storyboard first so I feel most comfortable creating apps with Storyboard, but in my most recent project, I made almost all of my views in code (except for a few custom views I was reusing throughout the project) and found that I enjoyed the level of understanding I felt I had over my project as well as the amount of control writing views in code gave me.

m4rnf5

Regardless, there are some pro’s and con’s that should be considered when starting a new project.

XIBs

All’s Well that Ends Well:

The biggest and most obvious advantage to using XIBs is being able to put together a UI quickly. This capability is great for mock-ups with a designer or playing around with views when you’re not sure what you want your app to look like. It is quick, efficient, and takes minimal effort. Laying out elements and correcting misalignment  on a XIB is much easier to do than doing so with code. XIBs are most beneficial when creating small apps with a minimal number of screens because of its straight-forward implementation and ease of use.

Comedy of Errors:

Quite recently, I found out that XIBs can resent in some ugly merge conflicts and also that they are not the easiest components to debug. Additionally, XIBs are not terribly supportive of highly dynamic views. In my most recent project, I used them as skeletons for my custom table view cells, but the customization was mostly done in code because simple embellishments like round corners are not possible to make in XIBs. I also read that XIBs can decrease the performance of your app versus creating views in code because the XIB needs to be read, analyzed, and parsed from the disk. Thus, an app with many XIBs would be rather sloth-like at run time.

Storyboards

All’s Well that Ends Well:

Other than being near and dear to my heart because they are the first way I learned how to make things appear on a screen, Storyboards are great for creating quick, simple views with not too many screens and uncomplicated navigation. You can create an entire app in Storyboard in a short amount of time or do an entire mock-up of the flow of an app without having to write a line of code! It’s a beautiful thing.

storyboard_meme

Comedy of Errors:

Merge. Conflicts. Galore. If you’ve ever tried to merge storyboards, you’ll know how awful it can be. All you have to do is look at your Storyboard funny and it will throw a merge conflict at you when you try to merge your branch to your master project. Additionally, resolving these conflicts is a bit of a black art and much of the time, I have ended up just scrapping my Storyboard in favor of my Storyboard or vice versa to avoid the headache of parsing through lines and lines of XML. If you are working on a team and your team wants to use Storyboards, insist on separate Storyboards. Sometimes not sharing is caring! Another issue with Storyboards is that they are prone to bugs. I recently had to remove my DerivedData folder to stop XCode from crashing immediately after starting. It was awful. So while Storyboard can be a time-saver in the beginning, it might end up being a big headache in the end.

Views in Code

All’s Well that Ends Well:

The biggest advantage of doing views in code is that merge conflicts are much easier to resolve. Debugging is also made easier because you’re able to scan lines of code instead of diving into Interface Builder. Additionally, writing views in code performs faster than loading XIBs so if you have a large project with many views, this can make a major difference during runtime.

Comedy of Errors:

Visualizing the UI of your project becomes particularly difficult when you are writing all your views in code. Additionally, if you do not have a clear picture of what you want your UI to look like or you have an indecisive designer, playing with the layouts and styling of your elements can be very time consuming. Integrating into a project team that writes all their views in code may also prove itself trickier because figuring out the app flow and navigation is not as straight forward as it would be with Storyboard or XIBs.

 Much Ado About Nothing

With the pros and cons of each option pretty equally weighted, as mentioned previously, much of the decision about how you are going to create your UI is based on the situation and circumstance. If UI development is necessary, storyboarding will make the process go by much quicker than making views in code. Though, code reuse is more difficult when elements are storyboarded because the UI elements are connected to a view controller with hidden code. Should code reuse be a priority, creating UI elements in storyboard would make that process easier. Source code integration is also made easier when UI is done programmatically because it avoids pesky merge conflicts from arising.

So, in summary, if you were looking to this article to answer your question of whether to storyboard or not to storyboard, I don’t think I succeeded in doing so. But I hope I was able to assist in laying out the various considerations that should be made when creating UI. Happy developing!

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s