Award-Winning App Developers

iPhone Design Award-Winning Projects, by Chris Dannen, profiles developers who have received the prestigious Apple Design Award for iPhone app excellence. This book explains what makes these apps truly standout, including explanations of great user interface design and implementation, as well as the code under the hood that makes these the most responsive, intuitive, useful, and just plain fun apps running on the iPhone.

Interview with Facebook App Developer Joe Hewitt

Excerpt from iPhone Design Award-Winning Projects

Special Apress Offer

Apress offers a complete package of books on developing for the iPhone and Mac OS X. Apress is happy to offer all iPhone Life readers a special 25% off discount on the price of any one eBook purchased on apress.com. Simply enter the coupon code "IPHONELIFE" upon checkout. Offer expires October 31, 2010.

Joe Hewitt, who developed Facebook for iPhone, has open source roots—he worked on the Netscape and Mozilla Firefox projects— so it stands to reason that he has opened up much of his work to the masses. In this interview, Joe discusses Facebook for iPhone's unique home screen and its evolution from a Web app to a full-featured "phone" of its own.

How did you become sole iPhone developer at Facebook?

When I started at Facebook, I built iphone.facebook.com, which is now touch.facebook.com. After [creating these mobile Web sites], I asked to do an iPhone app. Pretty much my whole two years at Facebook has been doing iPhone things.

Why does touch.facebook.com look so much different than the iPhone app?

The touch Web site is now geared, not only for iPhone, but Android, Palm, and so on, so we're limited in how much we want to make it modeled after the iPhone conventions. I think the two will diverge more, if anything.

Why isn't a static nav bar used at the bottom of the Facebook screen?

The first version of the app did have the tab bar at the bottom, but I took it out because I feel like Facebook is a platform in and of itself. Each of the tabs almost contained the functionality of a separate app. For example, Facebook has its own chat, phone book, mail, photos, and applications. In addition, we have a lot of new apps coming down the pipeline and I had to look forward. I felt like the home screen model lends itself better to the idea of Facebook being an independent platform. It will let the app grow and become full-featured—it gives us room to add more apps within our app.

Facebook's unique grid-like home screen, modeled after the iPhone's own.

What was the thinking behind the grid interface?

I haven't really seen other apps that do this, and I wouldn't really recommend that anyone else do it. Facebook is kind of unique in its breadth and the amount of stuff people do on it. I really hesitated to build in the grid for a while, but as I kept moving things around and trying to make it all fit into the tab bar, I just felt like this was the best solution. I was expecting more people to complain about it, but it seems to have worked out pretty well.

You also use the top nav in an interesting way in this new version. Is the redesign a consequence of implementing the grid?

The grid came first; the feed filters you're referring to were in the previous version, in a horizontally-scrolling tab-bar at the top. It just didn't seem that people were using it enough to justify having a full-time piece of screen allocated to it, so I thought the new design was just more appropriate for how infrequently [feeds are] used.

What are the compromises involved in using the grid?

Economy [of taps] is always a motivating factor, but the grid adds an extra tap [because you need to press the grid button] versus the full-time tab bar. That was a compromise I felt was necessary. There's always that balance between screen clutter—adding tabs— and the number of taps.

What went into creating Facebook's view controllers?

I did a lot of custom stuff. The app is built on an open source framework I created called Three20, and it uses its own view controllers, all of which I had to write. I had to try to reinvent the Apple photo browsing app and the Apple Mail composing tool, among other stuff.

Three20 also has a style system meant to emulate CSS. If you want to draw any graphics, Apple normally requires you to use Quartz and other heavy-handed frameworks. I wanted a simpler way of doing that so I created one in Three20, and a lot of people have picked it up and added things to it for their own purposes.

Another custom thing is in the friends list. When I first started working on the app, I thought it would be cool to have phone numbers be really handy. The first two versions didn't really convey that information well; you could get the numbers by clicking on a profile and clicking over to the info tab, but I thought it'd be better to surface the numbers using an icon in the list.

Is there a point where the Facebook app gets too big?

On the 3GS, I don't feel like I'm pushing that limit yet, but the previous devices were sluggish for sure. The 3GS gives us a lot of room to grow. When you're looking at photos on the 3G, we definitely see a lot more out-of-memory crashes [than on the 3GS]. The JPEGs that you download are not exactly scaled to the screen of the iPhone, so you're downloading images that are a little bigger than they need to be— so holding them in memory and juggling them can cause the device to freak out sometimes. I've spent a lot time optimizing it.

Tap on the phone icon in the Facebook friends list to display phone numbers.

When the app gets memory warnings from the OS, how does it deal with them?

Well, there's a lot of data that's cached. For instance, when you load the news feed, you're getting each individual update, but also the names and pictures of the user that posted the update. We cache all that so you don't have to keep loading it if you go to another part of the app. That way if you go to view a message from someone who you have in memory from a newsfeed update, their information is already there. If there's a low memory warning, all that stuff gets flushed and has to be downloaded again.

Otherwise, it all stays cached?

Everything in the app works that way. If you load events, notes, or requests, it's all cached. When you go back to the app, it displays the cached version. And it does, it tries to load the latest version. If it's a week old—or some number of days, I forget the exact number—the app will just display a "loading" message and clear the old stuff.

Before that system was in place, you were constantly looking at the little "loading" spinner wherever you went to the app. I think it feels nicer to see something right away that you can interact with while the new stuff is coming in.

We actually didn't even have events until this third version. That kind of stuff definitely could be surfaced in a lot of other places, which would also feel nice. I've been thinking about putting your upcoming events on the top of news feed, so you don't have to go to the Events app.

Why couldn't Facebook for iPhone have kept growing in its old layout?

Well, tabs are very effective as long as you only have one level of tabs. A lot of apps— including the previous Facebook app— have two levels of tabs, which I think becomes troubling. I see that a lot— developers trying to cram a lot onto this little screen— and that second row of tabs becomes tempting when you have two levels of hierarchy to navigate. But having one level of tabs is a better way to navigate.

But how different can you make your UI without alienating people?

I hear it both ways, and I do emulate Apple quite a bit. For example, our message inbox is a lot like Mail. But where I feel it doesn't fit, I just do things a little differently. I'm not crazy about the way Apple does push notifications. Once you get more than one app sending you notifications, including SMS, it becomes very awkward. I have a Palm Pre to play around with, and the way they handle notifications is just perfect. Any app can send something to that little bar on the bottom, and they all balance really well. I think that apple has a lot of work to do. We're working on push notifications for our app now [for messages, but not chat], but if it worked the way it does on the Pre, I'd be a lot happier. On the iPhone, you actually have to hit OK to dismiss it, which sucks. On the Pre, you're not forced to attend to it at all.

As the app grows, how will you handle preferences?

Our app does use the Settings app for preferences right now, but we only have three toggles, and they're not that important. We're going to have a few more, and I've been planning to switch over to putting all our settings inside the app. Otherwise people just don't find them.

What's going to be most enticing about future versions of the Facebook app?

I think exploring the idea of sharing your location is very exciting. It's a huge untapped opportunity and a challenging one for us. People are constantly asking us why we haven't done it yet? The thing is, it's a really difficult thing to get right and can easily become a semi-useless feature if not done carefully. We could build the technical stuff very easily, but it's tougher to make it so that people actually want to use it and would habitually do so. There are a ton of services out there that do that right now, but how many have really picked up steam? Foursquare tries to motivate people by making a game out of it, but I'm not sure we want to do that. I think part of it is just people's expectations; if everyone decided to use it, they would start to expect to be able to go on Facebook to find out where their friends are. You wouldn't have to update your status to say, "I'm at the bar," because it would just implicitly include that information. If we can ever get there, to have people using it by default, then it'll be useful. But getting people to do it when no one else is doing it isn't easy.

Are the mobile versions of Facebook diverging from desktop Facebook?

If anything's going to change, it's that Facebook mobile will become the most frequently used version of Facebook. The desktop version will only be used for certain tasks— writing long messages or uploading a ton of photos. But as we see our traffic numbers swinging toward mobile, it changes how we decide what features to add and what to promote. There have been some features that started on the mobile side and came over [to the Web], and the iPhone app definitely has started to be the model for all our mobile apps and Web sites.

Are there interesting ways you use Apple's frameworks?

I've found Apple's actual tools to be under-serving my needs. I had to write my own photo-browser and my own message-compose. It would be nice if they could include something so commonly needed. They have a framework for picking a photo from your collection, but only from the albums on the phone—you can't insert your own photos into that UI. It's a very generic thing. A lot of apps use that finger-flicking display of images. That's the most popular part of the Three20 framework. I would not be surprised if a future iPhone OS has that baked in.

Why did you choose to make Three20 open source?

The Facebook app was just so big that I ended up writing a lot of code that was worth sharing, so I thought it would be useful to open-source it. I'm an employee of Facebook, so I'm not out there trying to make money on the market. It was work I was being paid to do, and Facebook has a good policy toward open source— they try to let their engineers open source anything that's not too uniquely valuable to the company. I've had a history of doing open source before, with Mozilla, so I try to make things open whenever I can. People do appreciate that, and it makes me feel good that my work is affecting more than one app on the store.