Most of the iPad reactions I've read have been negative, but I have been completely satisfied with what Apple announced. iPad is exactly the product I've been wishing for ever since I wrapped my mind around the iPhone and its constraints. While the rumor mill was churning with all kinds of crazy possibilities for the Apple tablet, I mostly rolled my eyes, because I felt strongly that all Apple needed to do to revolutionize computing was simply to make an iPhone with a large screen. Anyone who feels underwhelmed by that doesn't understand how much of the iPhone OS's potential is still untapped.

I spent a year and a half attempting to reduce a massive, complex social networking website into a handheld, touch-screen form factor. My goal was initially just to make a mobile companion for the facebook.com mothership, but once I got comfortable with the platform I became convinced it was possible to create a version of Facebook that was actually better than the website! Of all the platforms I've developed on in my career, from the desktop to the web, iPhone OS gave me the greatest sense of empowerment, and had the highest ceiling for raising the art of UI design. Except there was one thing keeping me from reaching that ceiling: the screen was too small.

At some point I came to the conclusion that Facebook on iPhone OS could not truly exceed the website until I could adapt it to a screen size closer to a laptop. It needed to support more than one column of information at a time. I couldn't fit enough tools on the screen to support any kind of advanced creative work. Photos were too small to show off to my far-sighted parents. The web required too much panning and zooming to enjoy reading. Beyond just Facebook, most of the apps I used most on my iPhone also suffered from these limitations, like Google Reader, Instapaper, and all image, video, and text editing tools. The bottom line is, many apps which were cute toys on iPhone can become full-featured power tools on the iPad, making you forget about their desktop/laptop predecessors. We just have to invent them.

Opportunity

iPad is an incredible opportunity for developers to re-imagine every single category of desktop and web software there is. Seriously, if you're a developer and you're not thinking about how your app could work better on the iPad and its descendants, you deserve to get left behind.

True, iPad 1.0 has a lot of limitations which make it hard to be compared to a laptop today. We're not there yet, people, but does it really take that much imagination to see how we will get there? Apple clearly wants to increase its investment in iPhone OS and reduce its investment in Mac OS X. At some point in the near future, Apple will adapt iPhone OS to even larger screens, add multi-tasking, and release something like a laptop or iMac with the OS. When it happens, it will make perfect sense, because by then there will be orders of magnitude more iPhone/iPad apps on the App Store than there ever were for Mac OS X and Windows.

A Closed Platform?

Given my concerns about the way Apple runs the App Store, you might expect me to jump on the bandwagon screaming about how Apple is evil and iPad is the death of open computing. Nonsense. My only problem with Apple is the fact that they insist on pre-approving every app on the App Store. The store may not be open, but the iPhone/iPad platform itself could hardly be more open to tinkerers of all ages.

The one thing that makes an iPhone/iPad app "closed" is that it lives in a sandbox, which means it can't just read and write willy-nilly to the file system, access hardware, or interfere with other apps. In my mind, this is one of the best features of the OS. It makes native apps more like web apps, which are similarly sandboxed, and therefore much more secure. On Macs and PCs, you have to re-install the OS every couple years or so just to undo the damage done by apps, but iPhone OS is completely immune to this.

As a developer, it's a bit sad losing the ability to come up with crazy plugins and daemons and system-level utilities, but I believe it's a tradeoff worth making. What people are overlooking is that the Internet is an integral part of the iPhone OS, and it is the part of the OS you can tinker with to your heart's delight. If you want to invent a new scripting language or background service or something, you're still totally free to do that, but you're going to have to run it on a web server. If you want total freedom on the client side, then write a web app. You're simply no longer going to be able to tempt users into installing software that corrupts their computer.

So, in the end, what it comes down to is that iPad offers new metaphors that will let users engage with their computers with dramatically less friction. That gives me, as a developer, a sense of power and potency and creativity like no other. It makes the software market feel wide open again, like no one's hegemony is safe. How anyone can feel underwhelmed by that is beyond me.

The Internet has been incredibly empowering to creators, and just as destructive to middle men. In the 20th century, every musician needed a record label to get his or her music heard. Every author needed a publishing house to be read. Every journalist needed a newspaper. Anyone who wanted to send a message needed the post office. In the Internet age, the tail no longer wags the dog, and those middle men have become a luxury, not a necessity.

Meanwhile, the software industry is moving in the opposite direction. With the web and desktop operating systems, the only thing in between software developers and users is a mesh of cables and protocols. In the new world of mobile apps, a layer of bureacrats stand in the middle, forcing each developer to queue up for a series of patdowns and metal detectors and strip searches before they can reach their customers.

That's not to say there is no value to middle men. Middle men exist to reduce the cost of getting a product from A to B, and as long as that cost is significant, they will be useful. However, the moment the middle man monopolizes the means of distribution, he becomes a gatekeeper, and creators can be made to fail not by the merits and popularity of their products, but by the whims and short-term interests of the gatekeeper.

We're at a critical juncture in the evolution of software. The web is still here and it is still strong. Anyone can still put any information or applications on a web server without asking for permission, and anyone in the world can still access it just by typing a URL. I don't think I appreciated how important that is until recently. Nobody designs new systems like that anymore, or at least few of them succeed. What an incredible stroke of luck the web was, and what a shame it would be to let that freedom slip away.

I do not wish to fight any mobile device makers who want to create a software ecosystem and act as the gatekeepers for that ecosystem. What I do want to fight for is the viability of the mobile web. Developers are rushing to create native apps, meanwhile letting their mobile web apps atrophy (I have certainly been guilty of that myself). Web technology is still relatively weak, and improving slowly. At this pace, what will the mobile web look like in 10 years? Will we wake up and find that the next generation of great software companies have incredibly powerful native apps, but mobile websites that are little more than "About" pages?

In short, the mobile web needs better tools, better standards, and better browsers, and it needs them fast, before the only technologies that matter are the ones controlled by the gatekeepers.

I'd like to add my voice to the stream of complaints about the iPhone App Store, but before I say anything critical, I have to promise one thing. No matter how annoyed I get, I will not stop developing for Apple's platforms or using Apple's products as long as they continue to produce the best stuff on the market. I never forget how deeply Apple cares about making their users happy, and that counts more than how they treat their developers. Besides, when I have a problem with a friend, I don't threaten to boycott our friendship until they change, so I'm not going to do that to Apple either.

Having said that, I have only one major complaint with the App Store, and I can state it quite simply: the review process needs to be eliminated completely.

Does that sound scary to you, imagining a world in which any developer can just publish an app to your little touch screen computer without Apple's saintly reviewers scrubbing it of all evil first? Well, it shouldn't, because there is this thing called the World Wide Web which already works that way, and it has served millions and millions of people quite well for a long time now.

Oh, but you say that iPhone apps are different, because they run native code and can do scary things that web pages can't? Again, you're wrong, because iPhone apps are sandboxed and have scarcely any more privileges than a web app. About the only scary thing they can do outside the sandbox is access your address book, but Apple can easily fix that by requiring they ask permission first, just like they must do to track your location.

The fact is this: Apple does not have the means to perform thorough quality assurance on any app. This is up to the developer. We have our own product managers and quality assurance testers, and we are liable to our users and the courts if we do anything evil or stupid. Apple may catch a few shallow bugs in the review process, but let's face it, the real things they are looking for are not bugs, but violations of the terms of service. This is all about lawyers, not quality, and it shows that the model of Apple's justice system is guilty until proven innocent. They don't trust us, and I resent that, because the vast majority of us are trustworthy.

I shouldn't have to argue for why it is better to assume people are innocent until proven guilty. There are plenty of successful platforms out there which free developers to publish anything, but punish them if they do something harmful. This allows developers to move fast, fix bugs immediately, get feedback from users at a very low cost. Any bug that Apple finds after their two week delay would have been found by users on day one, and fixed on day two. I'd rather have a bug in the wild for one day than have an app in the review queue for two weeks.

If you think that all apps should be held prisoner by Apple until proven safe, you should also be able to convince yourself that this is how the web should work. Perhaps I am just spoiled by my many years of web development. The next time I create a web app I will probably feel a little guilty when I upload the files to my web server, knowing that I didn't have to ask the web police to review the app first to make sure I wasn't evil.

(I should probably add the disclaimer that the opinions expressed here are my own, and not my employer's.)

Buying a new iPhone is a much more exciting experience for an iPhone app developer than it is for a typical iPhone user.

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.

Last week I released my first iPhone open source project, Facebook Connect for iPhone, and today I'm ready to start talking about the next one.
Five months ago I talked about open-sourcing as much of the Facebook iPhone app as I could, and as you can see by the delay, that has turned out to be easier said than done.

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!

Last week I launched the second major iteration of Facebook's iPhone app, which finally lives up to our users' expectations and delivers most of the features they wanted. Getting here has been really challenging, and I'm finally at a point where I can reflect back on the experience and try to share what I've learned.

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 emailing me with Firebug questions in the last couple months - more emails than I've been able to reply to, so I apologize if you haven't heard back from me. In the last few days the emails have been more urgent than usual, so I figured that blogging would be the best way to get some answers out to everyone.

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.

Today marks the third major iteration of this blog since its inception in 2002. On the outside there is nothing interesting about the new design - it's intentionally plain. The really exciting thing (to me, at least) is what you can't see: joehewitt.com is now 100% Python-powered.

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.

I'll be right back.