By John Gruber
Understand, fix, and automate across your entire codebase. Learn more.
One area in particular where iPhone web apps fall short of native iPhone apps is scrolling. Take for example a long list, such as your full address book in Contacts, or all your songs in the iPod app. When you scroll these lists, you can fling the list, and the list will scroll at high speed after you let go. The effect is sort of like spinning a wheel with very little friction. With iPhone web apps, you can make a list that looks almost, maybe even exactly, like a native iPhone list view. But all web views on the iPhone scroll with almost no momentum. You can’t fling them. iPhone web views feel like they have a lot of scrolling friction.
This friction might make sense for regular web pages rendered on the iPhone’s small screen, where by “regular” I mean “not optimized specifically for display on the iPhone”. But it just feels slow — stuck — on iPhone-optimized apps.
If you’ve never taken notice of it, try it now, comparing something like your Contacts app list with an iPhone web app like Showtime. (In Showtime, tap “Watchlist” and then tap the “+” button to get a nice long list to scroll through.) Another good scrolling comparison: native iPhone Twitter clients like Tweetie and Birdfeed versus iPhone web app Twitter clients like Hahlo and the new Mobile Twitter. The difference is significant, and far more than cosmetic. As Justin Williams recently wrote:
I believe that with the current crop of Web technologies available in MobileSafari, apps like Hahlo, PocketTweets and Showtime could thrive as an alternative to their native counterparts if Apple allowed developers to adjust the scrolling/drag coefficient of Mobile WebKit. If you compare the scrolling speed of your Twitter timeline in Hahlo and Tweetie, the results are drastically different. Tweetie feels like it effortlessly scrolls based on how much momentum you exert in the scroll action, while Hahlo is being constrained by a fifty pound weight on its back.
Scrolling isn’t the only UI/experience issue where web apps seemingly can’t quite match what native iPhone apps can offer. Another is that MobileSafari doesn’t allow for CSS fixed-position elements, which means you can’t make a toolbar that stays put at the very top or bottom of the screen without having it scroll away when you scroll the content.
And that’s just talking about the user experience side of things. The other side is that of development. Last month I wrote:
When you write a Cocoa Touch app for the iPhone, you’re not starting from scratch. You’re starting with the Cocoa Touch framework. As Faruk Ateş astutely points out in his response to Koch, to discount the framework is to discount everything that sets the iPhone apart as a development platform. Not only are native iPhone apps faster and more capable than their web-app equivalents, but they’re easier to write.
Some readers objected to this, arguing, more or less, that no matter how good the Cocoa Touch framework is, native iPhone apps are harder to develop than web apps because one must learn both the app framework (Cocoa) and a new programming language, Objective-C. But that’s not really a fair comparison. It’s like saying it’s easier to run than to bike if you don’t know how to ride a bicycle.
What I’m saying is that talented Cocoa Touch developers have an easier job implementing the same iPhone app than talented web app developers do. The Cocoa Touch framework makes all sort of things free or easy. Things like smooth fast animation between views. Things like buttons and lists and toolbars that look just like other standard iPhone buttons, lists, and toolbars.
There do exist some open source frameworks for iPhone web app developers, so that one need not start from scratch implementing things to mimic Cocoa Touch UI elements. iUI, started by Joe Hewitt just a few weeks after the original iPhone debuted in July 2007, is one. jQTouch, by David Kaneda and based on jQuery, is another. (Showtime is built using jQTouch.)
But these frameworks don’t solve the problem with scrolling speed/friction, or fixed-position elements.
It ends up there is a company, however, that has developed an amazing iPhone web app framework which:
Completely hides the address bar, even when running not from a saved-to-the-home app icon, but within a page in MobileSafari itself.
Allows for fixed-position toolbars that never budge from the top when you scroll.
And: sets its own scrolling friction coefficient, allowing you to fling long lists.
The company behind this web framework is Apple. And the framework is apparently named PastryKit.
If you have an iPhone or iPod Touch handy, stop reading this and go here:
This is not a secret web site. In fact, it may well already be in your iPhone bookmarks — it’s where you get redirected when you choose the “iPhone User Guide” bookmark that’s included as one of the defaults for MobileSafari. I don’t know when Apple launched this PastryKit-powered version of the site, but it’s been under our noses for a while, with very little notice.1
If you don’t have an iPhone or iPod Touch handy, or if you do and you’re back after trying it out and want to poke at it with Safari’s Web Inspector, you can also load it in Mac or Windows Safari by setting the user agent string to MobileSafari 3.x in Safari’s Develop menu. (Without the MobileSafari user agent string, you’ll get redirected to a different iPhone help page; using a MobileSafari 2.x user agent string, you’ll see last year’s version of the User Guide, which is far less impressive technically.) Shrink your Safari window down to roughly iPhone dimensions before loading the site, because the UI will be laid out to fill the dimensions of the viewport when it loads.
After installing the User Guide app to your home screen and launching it from there, there’s really very little to suggest that it isn’t a native iPhone application. No MobileSafari address bar at the top, no MobileSafari toolbar at the bottom. Scrolling is fast and has momentum. It even works perfectly offline, because the contents of the user guide are stored locally in a database using HTML5.
The rubber-band “bounce” scrolling — where if the view is already at the top but you pull down in an attempt to scroll up and you see whitespace and it all just bounces back into place when you let go — breaks if you pull down all the way off the bottom of the display. What happens there is the view gets “stuck” in the position where it’s displaying the stretched-out whitespace at the top of the view; you can unstick it by just tapping somewhere in the content area.
But on the whole this User Guide app and the PastryKit framework are rather amazing. The $64,000 question, though, is whether PastryKit is something Apple intends (or that a team within Apple hopes) to ship publicly. It seems like a lot of effort to build a framework this rich just for this iPhone User Guide, so I’m hopeful the answer is yes. Perhaps something integrated with the next major release of Dashcode? And, perhaps with integrated UI layout tools, along the lines of Interface Builder?
Here’s to hoping we haven’t heard the last of PastryKit, and that Apple continues work on making mobile WebKit an open alternative to the App Store.
For the sake of posterity and for those of you without access to an iPhone or Safari, I’ve made two screencasts showing the iPhone User Guide web app in action.