The signs were there.
Many months ago, I learned about Storyboards. A Storyboard is a relatively new feature in Cocoa Touch development, added in iOS 5.0 back in October 2011. They allow you to see all the screens of your application in a single file. This lets you see how everything connects together. And in fact, you can often connect the screens together using a graphical user interface instead of with code.
They certainly look pretty
On the surface, storyboards look really cool, and after reading about them, I immediately set about rewriting my app to incorporate them.
Almost immediately, I ran into a serious problem that set me back for several months (documented here). The app looked nice, and the code was much simpler, but I didn’t feel like I had the right understanding about what was happening.
When we hired an iOS contractor, I asked excitedly if he was going to use storyboards. No, he replied, they don’t work so well when multiple developers are working on a project. This made sense- the user interface for every screen is stored in a single file. If two developers needed to change two different screens, well, you’d run into editing conflicts on that single file. Fair enough, but not really an issue for my solo development project.
And then I began the process of updating Fort Collins for Kids in iteration 3. The first thing I wanted to do was to replace the editing screen for the Attraction object. Iteration 2 used a tableview, with each row editing a single text field. In iteration 3, I wanted to change that to move away from the grid. Different fields on the Attraction object needed to be edited in a different way. For example, the generalInformation field was going to use a multi-line text box, and the cost field was going to use a picker.
So I deleted the tableview from the screen, and started to drag in elements to start on the new screen. I dragged in a View to serve as a parent. Or tried to- it didn’t stick. I dragged in other view controls. Same result. I tried all kinds of different things. I tried looking for online documentation- and there was precious little to be found. Finally, in a state of semi-desperation, I bought a more recent version of my iOS programming bible, the The Big Nerd Guide. At the end of the storyboard chapter, the authors describe the pros and cons of storyboards.
Storyboards sacrifice flexibility and control for ease of use. When you need to get your hands dirty, which is often, a storyboard is more of a wall than a trampoline. The work required to add advanced functionality to the basic functionality of a storyboard is often more than the work required to put together the advanced and basic functionality in code.
Um… yeah. They conclude with
Overall, storyboards make easy code easier and difficult code more difficult. We won’t be using them in this book, and we do not use them when writing our own applications. It is up to you to decide if a particular application would benefit from storyboarding. Of course, your opinion may change as your project gets more complex. Don’t say we didn’t warn you!
(sigh) This was certainly matching my experience. I thought back to all of the struggles I’ve had building Fort Collins for Kids. They were all related in some way to storyboards. In particular, they were all related to some kind of invisible magic that storyboards took care of for me.
Real programmers would just read the XML
Before I moved into management, at the height of my professional engineering prowess, I wrote code using C++ and Visual Basic 6 (VB6). C++ was infinitely more complicated, and VB6 was quite simple for building simple user interfaces. But when you had to do something more complicated… wow, was VB6 the wrong tool. You never really knew what was going on, since so much was hidden for you. Which is why I draw the parallel between storyboards and VB6.
It didn’t take long to make a decision. The storyboards had to go- even if it meant rewriting the entire editor app. I cringed when I created the new project file, since the name of the app, Editor4, was a reminder of how many times I’ve done this. But the implementation was much faster the 4th time. I was able to directly use all of the model code wholesale, and pieces of the user interface code as well. (And I came up with yet another way to implement commit/rollback, but that will be a different post).
It’s hard to describe how it felt. Writing the code using traditional .XIB files felt refreshing and liberating. I knew exactly what the code was doing when, and that gave me confidence that I never knew I was lacking. Forward!
Das Haus von Ruh 