Veteran iOS developers know that for the past three + years there have been two major ways to make an iOS app user interface:
- writing everything out in code
- using Interface Builder to compose a main window based app
With iOS 5, Apple has added a third way to compose iOS applications called Storyboards. Storyboards are a new approach that could revolutionize how you create your iOS applications.
How iOS App Architecture Worked Pre-Storyboard
Whether you used Interface Builder or not when composing apps prior to iOS 5 the pattern would be to create each view + view controller combination independently. Then you would use the app delegate’s window out with tab bar controllers and navigation controllers (or some combination) to manually push or otherwise display your various views as needed. With the exception of the first few views, this would happen programmatically as a response to user’s interactions with various controls.
With Storyboards, Apple is consolidating all the UI into one large file and is providing a visual metaphor to glue each view together. All the UI work is done in one place with Interface Builder. View controllers are still an integral part of the workflow, but they are no longer matched with a xib file.
iOS 5 Storyboard Concepts
Over the next few blog posts, I am going to introduce Storyboards in iOS and demo how to produce typical iOS app patterns using Storyboards. Before I get into all that though, we should go over the main Storyboard concepts so we are all on the same page when we get into the nitty-gritty details.
Storyboard
This is the central concept now in developing iOS user interfaces. Storyboards are meant to be a metaphor for something that a designer would use to visualize a series of scenes in a movie or flow in an application. This appears to be an intentional pivot on Apple’s part to include designers in the development process more intimately.
Each app gets one storyboard and you can use the XCode template to set up a storyboard based app or you can add your own storyboard and then set this up as the main interface in the top level project area. Either way, you will have one file to locate all of your user interface.
Storyboards are part of a system that includes scenes, segues and view controllers.
Scene
For iOS apps, a scene is one screenful of content. You are probably used to thinking of this as a view and it still is in the background. Scenes are where you will be composing your views by adding user controllers and other views.
View Controller
Like before, Apple is using the MVC pattern and View Controllers still manage all the behavior of views (now scenes). Any scene which needs custom behavior or content will still need a custom view controller to manage this. Interface builder is used to set the view controller code file to the associated scene by using the identity inspector and setting the custom class name.
Segue
Segues are a visual metaphor that represents the transition from one scene to another, just like in the movies. While before, transitions were sort of hidden in view controller delegate methods with code segues bring these transitions into one visual space.
You will use Interface Builder to add segues between scenes and these replace the code you may have used in delegate methods like didSelectRow:atIndexPath: or in action code associated with a button or other user control.
My Thoughts On Storyboards In XCode
Since I first heard about these in June at WWDC, I’ve been a little bit skeptical. As a developer, I really didn’t see the need to change the process I follow now which works very well for UI. Also, as I suspected many other developers on the Storyboard Vanguard (so to speak) have been finding that the model breaks down a bit in some edge cases.
Fast forward six months and I do see some potential advantages to storyboards. Compared to the previous window based application XCode template, Storyboard based apps do seem a bit more logical in their layouts. Try to explain a window based app (the one with the MainWindow.xib) to a novice and you’ll see what I mean.
Having the entire UI in one place with the seques explicitly showing the relationships between each view presents a more coherent view of app as a whole making everything a little bit more grokable .
Still, I am a little bit skeptical mostly because changes to XCode seem to be happening so fast now (it seems to change everyone 6 months). It’s hard to recommend a particular technique to my audience when Apple engineers themselves don’t seem to have a hard and fast pattern that they’ll stick to. For me, Storyboards are a reminder that as polished as iOS development is becoming we are only three years into this and everything is subject to change.
For now, I am recommending this to people as an alternative to the MainWindow.xib approach along with a completely code driven approach. While the MainWindow.xib app template is still my recommendation this is likely to change later this year depending on the level of support and mindshare that Apple puts into Storyboards.
What do you think about Storyboards in iOS 5? Pros – Cons – Indifference?