Yesterday, after waiting in line for an hour so, I scampered out of the Apple Store with my head down, furiously tapping my way around the screen of my new iPhone 3G S, not really watching where I was going. With each buttery smooth flick of my finger, I felt lighter and lighter. Two years of anxiety melted away as the realization set in: I get to code for a real computer now, not a cell phone.

Let's face it - until now, the iPhone had been a big tease. It was hard to believe that this was a serious computing device when it could not perform even the most basic tasks without constantly stuttering and freezing. As an iPhone developer who cares deeply about user experience, this caused me a lot of grief. I have worked very hard to make my app perform smoothly, but there just wasn't enough power and memory on the device. In particular, loading, unloading, and displaying of images and data tended to lock up the device quite often. My only consolation was that Apple's own apps were no better than mine - Maps, Mail, Photos, and Safari were all prone to being painfully slow.

When I say "slow," I am not talking about launch times or load times. It's nice when an app launches fast, but what really matters is that it is responsive. When I move my finger on the screen, I expect the UI to respond to each fine-grained motion immediately. That is what creates the illusion that you are interacting with physical objects, and not a computer. Having spent two years of chasing that dream, I had begun to wonder if Apple was ever going to make it possible.

After playing with the built-in apps for a few minutes, I was thrilled by the speed of the 3G S, but the real moment came when I installed the new Facebook app (still in development) onto the device. I am, of course, acutely aware of every speed bump in the app -- every table that didn't scroll fluidly enough, every animation that dropped frames, and every place the app would freeze while loading images. On the iPhone 3G S, every single one of these pain points are healed. Fast, smooth, and perfect every time. I have yet to see the app freeze once. I have yet to see a table that showed any hesitation to scroll. I have yet to see a single frame dropped. If my apps ever give my users any friction ever again, I will have no one to blame but myself. Apple has done their job masterfully and the iPhone 3G S now has every right to call itself a computer.

Of course, it will be quite a while before the majority of iPhone users have a 3G S or better, so I'm not free to stop worrying about performance just yet. However, what matters is that I can now feel good about the future. The next time I am wrestling with a performance issue on the iPhone 3G or earlier, I won't fret that it is my Sisyphusian fate as a mobile developer to struggle to achieve good performance. It is now just a matter of time.

Developing an app and developing a generic library are very different goals. A lot of the code I wanted to release was not generic enough, used hacks that worked just well enough for my app, and was coupled with a Facebook-specific data model. So, one by one I've been redesigning and refactoring each of the components I wanted to open source, adding them to a new Xcode static library project, and then reintegrating them with the Facebook app. I just finished doing that a few days ago, and now I'm ready to start sharing the results.

The name of the new project is Three20, after the 320-pixel-wide screen of the iPhone. The code is all hosted on github for your cloning pleasure. There is an excellent sample app called TTCatalog which lets you play with all of the various UI components. Documentation? Well... there are instructions for how to add Three20 to your project, but I am still working on comprehensive documentation for each of the classes. For now, the sample app and the code itself are your documentation.

So, what kind of iPhone UI goodness does Three20 provide?

Photo Viewer

TTPhotoViewController emulates Apple's Photos app with all of its flick'n'pinch delight. You can supply your own "photo sources", which work similarly to the data sources used by UITableView. Unlike Apple's Photos app, it isn't limited to photos stored locally. Your photos can be loaded from the network, and long lists of photos can be loaded incrementally. This version also supports zooming (unlike the version in the current Facebook app).

This has probably been the single biggest timesink in the whole Facebook for iPhone project for me, so if I can help anyone else save that time I will sleep better.

Message composer

TTMessageController emulates the message composer in Apple's Mail app. You can customize it to send any kind of message you want. Include your own set of message fields, or use the standard "To:" and "Subject:". Recipient names can be autocompleted from a data source that you provide.

Web image views

TTImageView makes it as easy to display an image as it is in HTML. Just supply the URL of the image, and TTImageView loads it and displays it efficiently. TTImageView also works with the HTTP cache described below to avoid hitting the network when possible.

Internet-aware table view controllers

TTTableViewController and TTTableViewDataSource help you to build tables which load their content from the Internet. Rather than just assuming you have all the data ready to go, like UITableView does by default, TTTableViewController lets you communicate when your data is loading, and when there is an error or nothing to display. It also helps you to add a "More" button to load the next page of data, and optionally supports reloading the data by shaking the device.

Better text fields

TTTextEditor is a UITextView which can grow in height automatically as you type. I use this for entering messages in Facebook Chat, and it behaves similarly to the editor in Apple's SMS app.

TTPickerTextField is a type-ahead UITextField. As you type it searches a data source, and it adds bubbles into the flow of text when you choose a type-ahead option. I use this in TTMessageController for selecting the names of message recipients.

HTTP disk cache

TTURLRequest is a replacement for NSURLRequest which supports a disk cache (NSURLRequest can only cache in RAM). It has some other nice features too. HTTP posts are as easy as supplying a dictionary of parameters. The TTURL loading system can also be suspended and resumed at any time, which is a great performance helper. Network threads often fight with the UI thread, so you can suspend the network any time your app is graphically intensive.

URL-based Navigation

TTNavigationCenter is for those grizzled old web developers like myself who want to organize their app by "pages" which can be displayed by visiting a URL.

Your view controllers can simply register URL patterns that they handle, and when those URLs are visited the controllers will be created and displayed. You can also register generic actions that are called when a URL is visited.

TTNavigationCenter also persists and restores the full path of navigation controllers and modal view controllers, so your users can quit the app and come back exactly where they left off.

How mature is Three20?

As of today I would call this code alpha quality. If you attempt to use Three20 at this stage, be prepared for a little bugginess. While this code is derived from Facebook for iPhone 2.2, much of it has been rewritten, and that new code has not yet shipped in any app on the App Store. I am using Three20 to develop Facebook for iPhone 3.0, which is slated for early May, so things should be stable by then.

New open source projects are always exciting because you never know who is going to wander into your garden. If you have any questions, please email me!

The 1.0 version of the app was trashed in reviews for its lack of features, which was really hard for me to take given how hard I worked on it. People must have assumed that all I had to do was plug Facebook's data into Apple's ready-to-use UI components and hit the GO button. I wish it had been that easy, but unfortunately many of the components I needed were missing from the iPhone SDK, even though they existed in Apple's own apps. The lack of a mail composer and a photo browser were particularly disappointing.

I had to make a choice: I could dash off weak versions of these components and hope Apple adds the full versions to the SDK later, or I could attempt to replicate them in great enough detail to convince users they were using a standard interface. I chose to take the latter path, and it definitely cost me a lot of development time which could have been used to add more features. One other side effect was that users actually did think they were using a standard interface built by Apple, and so they gave me no love for the work I did, and instead insulted me for not taking the time to deliver more features.

In retrospect, I think I made the right decision. I still can't believe how many apps I've downloaded from the App Store which exhibit no ambition to reach the high bar of quality set by Apple's apps. Many of these apps still receive great reviews for having long feature checklists, which is unfortunate because it only encourages more lazy UI engineering. Just the number of half-assed photo browsers I've found is astounding. I've spent a ton of time working on Facebook's photo browser and it is still only about 80% as good as Apple's, but it close enough to feel familiar to anyone that has used the built-in Photos app.

I have no doubt that Apple will make big improvements to the SDK in the near future, but in the mean time I want to help the open source community fill in the gaps. The iPhone SDK agreement says that you can't distribute "frameworks", but my contacts at Apple Developer Relations have said that it is OK to distribute "sample code". I would like to try and extract as much as I can from Facebook for iPhone and publish it as simple Xcode projects that you can play with and copy from.

A lot of people have been writing to let me know that getfirebug.com has been down for the last week or so - especially bad timing given that Firefox 3 is here and people are looking to upgrade Firebug too. I'm very aware of the problem with getfirebug.com's web host. To prevent this from happening again, I decided to just transfer ownership of getfirebug.com to Mozilla, who will take much better care of it than the crappy web host it has been running on to this point. The transfer is in progress and getfirebug.com should be up and running again within a day or two.

Firebug 1.2 is the new version that is compatible with Firefox 3. Don't thank me for the new version, as I didn't write a line of code for it. The credit goes to the open source community that has sprung up around Firebug in the last year, led by John J. Barton of IBM. They've done an amazing job and made me feel really good about the decision to make Firebug free and open source.

getfirebug.com may not be back online tomorrow when Firefox 3 ships, but fret not, because Firebug 1.2 is already available to download from addons.mozilla.org. If you have Firebug 1.0x installed in Firefox 2 then you should get automatically upgraded when you install Firefox 3.

The blog had previously been running on Movable Type (Perl) with some PHP around it. I'm really a Python guy, so that kind of irritated me. I've always wanted to use the site as an experimental platform for new publishing ideas, but not so much that I wanted to suffer through PHP or Perl to do it. Now the blog is a very simple Django application which I can easily enhance at a moment's notice. This was my first Django app and I can say without qualification that Django rocks. It was so easy that I wrote most of the code on airplanes while flying across the country.

Another change is that I have decided to go without comments this time around. I think that I've self-censored a lot of potentially interesting blog posts because I didn't want to get into arguments with readers in the comments. I'd like to blog because it helps me find clarity in my thoughts and improve as a writer, not because I want to entertain or persuade anyone.