- ARC
- Storyboards
- The Ninja Move
- Auto Layout
- Instruments
- Unit Testing
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Storyboards
Xcode has always let us graphically design our user interfaces. Unlike similar tools in other platforms, Interface Builder does not simply generate code. It creates and saves actual objects into a nib file. This is often described as “freeze drying” the interface. When our application runs, it loads the nib file, “thawing” our interface and bringing it to life.
Storyboards takes this basic nib infrastructure, and cranks it up to 11. Now, we’re not just laying out a single scene—we’re also designing the transitions between scenes. This lets us graphically design the basic workflow for our entire application (see Figure 1).
)
The primary benefit from using Storyboards is speed. Once you get used to using the tools, you can build the main skeleton of your app in a fraction of the time it would take to code it by hand. And, I’m talking about a very, very small fraction.
I also find Storyboards (and graphically designed interfaces more generally) to be less prone to bugs. I don’t know about you, but whenever I lay out an interface in code, I never get it right on the first try. It always takes a few iterations to get everything exactly where I want it. With Interface Builder, I can have pixel-perfect placement from the very beginning. It is also easier to make changes. This is particularly important as the interface becomes more complex.
Additionally, there are a few lesser-known (but still important) advantages to using Storyboards. For example, Storyboards provide a number of features that make working with tables (and, in particular, static tables) much, much easier. Storyboards also simplify interactions between view controllers. In particular, segue unwinding lets us replace complex delegate patterns with simple, straightforward method calls.
Best of all, though, by using a Storyboard, we can rapidly create our application’s workflow. Then, by adding a tiny amount of code, we can add mock data to the interface. This gives us an interactive demo of the user interface that we can show to our client and get feedback very early during the development cycle. This lets us find and fix problems and miscommunications before we end up wasting a lot of time going down the wrong path.
Now, Storyboards aren’t without problems. The biggest issue is using Storyboards in a multi-developer team. You should never let more than one developer modify a Storyboard. Multiple developers working on the same Storyboard will inevitably lead to merge conflicts that are almost impossible to resolve.
There are a couple ways around this. First, you can assign one person to be the Storyboard tsar, and no one is allowed to touch the Storyboard without the tsar’s permission. You also do not need to use a single storyboard for the entire application. You can break the application into multiple Storyboards, or have Storyboards load nib files for the leaf views.
For more information on storyboards, please check out my blog post on Advanced Storyboard Techniques.
Storyboards are another place where many experienced developers continue to drag their feet. However, if you really learn how to use them well, they will let you create complex user interfaces with a minimal amount of time and effort.