The iPhone SDK makes it fairly simple to build powerful applications that can be deployed to millions of phones.
Actually writing the code for the application isn’t the hard part most of the time, especially if you aren’t straying too far off of the default widget library. Where I found myself having the most issues was with how to properly design an application within the parameters of 320x480 pixels.
In terms of data-driven apps, there are three methods of designing your application: drill-down navigation with UINavigationController, using a tab bar and UITabBarController or a hybrid of the two.
If I had to pinpoint my biggest mistake in the development of FitnessTrack 1.0, it was the quick decision to use a UITabBarController as the foundation of the user interface instead single navigation stack.
When I made the decision, my thinking was that the application had four separate features, so it only made sense to separate them using the tab bar. What I found as I got further into the development of the application was that the bottom tab bar was incredibly limiting for where to place extra controls. With a tab bar, there are 2-3 spots along the UINavigationBar: leftBarButtonItem, rightBarButtonItem and titleView. If the pop navigation button takes up the left side and an edit button is on the right side, you’re pretty limited.
The other issue I was running into was how to properly save the state of the application. The application has four possible places to save application state, but is that the proper thing to do? If you look at Apple’s iPod app as an example, they only save the state of the recently selected tab and default everything else back to the root view controller. Joe Hewitt’s Facebook app saves the state of every tab, no matter what is visible. I opted to mimic the iPod application, but I can’t help but question whether it is the right solution. I think one could argue for or against both options. In the end, the issue would be moot if I had just not used the UITabBar.
Despite my frustrations with the control, I am seeing it pop up in more and more applications. The UITabBar is appealing to developers because it offers a quick way to jump between different sections of an application with fewer taps than a traditional navigation stack. In some cases, this works well. Tweetie, the popular Twitter client, is great because with three taps I can see my personal timeline, mentions and direct messages. Same with the Phone app. I can tap quickly to get to my Favorites, Voicemail or Recent/Missed calls.
In many other cases, the tab bar is a UI hindrance more than anything. AppStore, on the other hand, uses a tab bar where it’d be far better served using a single navigation stack. I believe Apple’s reasoning for using the tab bar on the AppStore (and iTunes.app) was wanting to put Featured applications front and center when the application first launches. I can understand that, but having separate tabs for Categories, Top 25 and Search feels wrong. Each of these three tabs perform the same basic operation: filtering data based on a specific criteria. Search is the process of filtering the store based on user-defined criteria. Categories and the Top 25 are also methods of filtering the store based on specific criteria as well.
Given use cases with AppStore, you can be viewing 4 different applications at once: one on different tabs. That’s extremely disjointed and potentially confusing. The application would be better suited by affixing the search bar at the top of a primary view and having a table that lists each section (Featured, What’s Hot, Top 25) and the subsequent app categories. This would allow the user to drill down in the store in a similar manner as the desktop version or search instantly without having to jump to a different tab.
The apps that inspire this sort of thinking are my most frequently used ones: Messages, Things, Birdfeed and Mail. Each one of them has an exceptional drill-down user experience that I think should be the gold standard for future iPhone apps. They are good looking, powerful and the user interface doesn’t get in the way.
Rather than taking the easy way and slapping a tab bar at the bottom of your UI, put the extra effort into the design process to see if it is possible to do the application using a single navigation stack. In most cases, I think the answer is yes. It may be a bit more work up front, but as your application matures (if it matures), you’ll find that the extra usable space along the bottom of your view will be much appreciated.
