If the post for part 1 talked about language choice, there is another aspect of iOS development that is also a big choice but a lot less obvious: Graphical User Interface (GUI).

XCode and iOS development are tightly coupled together as with most proprietary development platforms (think Visual Studio). When it comes to the user interface, there are two choices:

1) Use what the IDE gives you to try to make your life better

2) Use the GUI APIs to code everything manually

This isn’t much different than using Java and Swing or SWT or other graphical user interfaces (GUI). You either get a nice GUI to build your GUI and you’re restricted by how clear such GUI can be or you have to write A LOT of code to specify the GUI’s complex behavior.

When it comes to iOS, it’s even more complicated since Apple gives a lot of attention to the GUI of their apps. There are tons of hidden specifications about icon sizes, launch image sizes, resizing rules, handling multiple screen sized devices and much more. XCode tries to provide useful error messages regarding the GUI but rarely succeeds doing so. A few of the ones that drove me the most crazy:

1) Icon sizes for iPhone applications: the Xcode UI is nice to show you versions of the iPhone you’re trying to match but won’t help you figure out which dimensions correspond to which version. It’ll also just simply not succeed to compile or deploy if an icon for a given version is not available even when you’re deploying to a version that has an available icon.

2) Launch screens: those are not really being used anymore but they were a while back. So if you don’t add one for some older versions of iPhone, you’re main application screen won’t use the whole physical screen. No errors. No warnings. The screen just has a couple of black bands on top and bottom.

3) Constraints: iOS tries to have some flexible layouts to help developers handle similar yet different screen sizes. There are many many ways to specify those constraints. Some of them conflict with each other. Others are not constrained enough to have a single solution. Generally speaking, all components of a given screen have to be properly constrained. If one is wrong, they all can get funky. Error reporting in this case is, at best, wishful thinking. It’ll show a constraint issue but it won’t help identify the component and the solution is often very hard to find.

On the other hand, XCode's GUI Storyboard metaphor is great to communicate with visual designers and non-technical folks. The flow is obvious and it provides a quick glance into how much work still needs to be done on a given screen. It’s also pretty easy to get something going very fast. It won’t be perfect and it won’t work on all devices but if you just want a quick test to get some feedback, it can take as little as 5 minutes to put a screen together that actually looks like the full-featured one would.

I can easily imagine how insane maintaining those Storyboards in a distributed team that is still in the forming stage of an application. It also probably becomes quickly unmanageable as the application grows. On the other hand, fully manually developed code tends to suffer from similar issues.

In the end, the reality is that GUI is complicated and it takes a lot of work to build and maintain a decent one. Being on the IDE’s hand for that maintenance seems too risk so I would recommend starting with the storyboard until you understand your GUI better and once it feels a little more stable, transition it all to be code driven.