iPhone web app development has its limitations
Craig Hunter
August 20, 2007
When Apple announced the third-party app strategy for the iPhone back in June at WWDC -- ie, web apps -- the news landed in the Apple developer community with a resounding thud. My initial reaction, shared by many other developers, was a combination of frustration and disappointment. No need for specific links here -- a Google search on "iPhone SDK" pretty much shows it all.
It's not that web apps aren't real apps. In my opinion, if it helps the user perform a particular task or "application" on their device, it's an app. And, as I found out, it's possible to stay up all hours of the night obsessing over a web app, just like developing a traditional Cocoa app. Actually, more so in my case, as web apps are new to me and new stuff ropes me in big time.
So, yeah, web apps are real apps, but they are not without some legitimate gripes. Foremost in my mind, a web app really only makes sense when it's based on some aspect of collaboration, sharing, or remote data / content access -- stuff that benefits from the web or requires it. For example, it would be nuts to require web access just to be able to type a to-do list on my iPhone. But if the to-do list can be shared among other users or with my other computers and devices, it makes sense as a web app. There are other concerns, but this is the big one for me. I would have a real hard time justifying a web app that doesn't have an honest web component to it.
Of course, web apps are currently the ONLY way to make non-hacker, mainstream software for the iPhone right now, so my gripe doesn't have a lot of meat. Reality does that sometimes. In this case, I think reality is acting like a form of natural selection, dividing would be iPhone developers into four categories: 1- traditional developers that are staying away, 2- traditional developers who are getting their feet wet with web apps, 3- hacker developers who are marching forward and developing native apps the hard way, and 4- existing web app developers. Actually, there's a 5th group out there -- people making iPhone-sized websites -- but I think they'd be doing that no matter what the app development outlook was.
I'm least worried about the hacker developers, as they have to be pretty damn smart and work hard to do what they are doing, plus they're making good progress. It's what comes from living under an oppressive regime. The seasoned web app developers know what they're doing too, and have been turning out some good apps (albeit in limited numbers). You'll know one when you see it.
I guess I am most concerned about category # 1 -- the traditional developers who are staying away. iPhone app development will suffer without the influx of creativity and talent these guys could bring to the table. Some of the best software on OS X these days comes from small, independent developers, and it would be great to have these guys developing for the iPhone. I know some are watching the market, and perhaps holding out for a native SDK from Apple or someone else. Others may want to get into the game right now, but are put off by the notion of web apps, or by the business aspects of web apps. Among other things, traditional developers may be discouraged by web apps because they often carry server side overhead and infrastructure requirements, they require new strategies for software registration and management, and they offer little or no protection of source code.
As a member of category # 2, I can tell you that these issues are a big deal, and I continue to wrestle with them. It's especially troubling to me that source code is so vulnerable (certainly any Javascript, CSS, HTML is open for the taking). It's hard to build a business case around an app when any notion of proprietary work goes out the window. Look around, and it's not surprising that so many web apps are free, or meant to be a segue to a different form of revenue like advertising.
I attempted to make my first iPhone web app into a viable business effort by offering it as a companion product to a Mac desktop app. This keeps registration tied to the traditional software product, and gives me some control over distribution and usage. But it also relegates the web app to be more like a "feature" of the desktop app. This will enhance the value of the desktop app and may make it appeal to additional customers, but the web app will probably never be a smashing success on its own. A "killer" iPhone app might work in this role though, if it was so good and compelling that it actually drove sales of the desktop app in a major way.
Business aspects aside, the main issue I see as a traditional developer is that iPhone web app development is still very limited. Outside of some viewport settings, a couple special link types (really only the "tel:" link is new), and some new "-webkit" style attributes, there is little about making iPhone-specific web apps that differs from generic web apps. And that's possibly the most disappointing aspect of all from my standpoint. Apple's announcement states that "developers can create Web 2.0 applications which look and behave just like the applications built into iPhone", but that's not the case.
For one thing, you'll never forget your iPhone web app is running in a browser, because Safari on the iPhone puts up a fairly large URL bar. In fact, it uses up a whopping 60 pixels of vertical space, or about 14% of the available real-estate in Safari's viewport. Sure, you can flick it out of the way when panning the viewport, but it will come back at some point. Joe Hewitt (author of the great iUI iPhone app template, which is as much of an SDK as we have these days) came up with a simple solution to hide the URL bar by calling a Javascript "scrollTo(0,1)" once a page has loaded, but that is defeated when the user pans the viewport (perhaps unintentionally), rotates the screen, or brings up form controls or the keyboard in some cases. It takes a lot of babysitting to make the effect stick, and even then, the frequent appear / disappear act of the URL bar doesn't really lend a finished feel to things -- it's kind of like hiding a coffee table under a throw rug. Apple needs to give us a way to reliably hide or collapse that URL bar if our web apps are to start looking like real iPhone apps. Maybe a double tap on the status bar can expand everything back to default, or have a button (similar to the title bar "pill" on Mac OS X apps with toolbars) that can expand / hide the upper URL bar.
Another problem is that Safari intercepts many of the iPhone's unique input gestures such as the one-finger flick / drag and the two-finger pinch. The only input events that make it through everywhere are basic click events. Scroll events work for frame and overflow elements, but these use a little-known two finger maneuver (similar to scrolling on a MacBook trackpad) that is both awkward and inelegant compared to the one-finger flick / drag. Apple needs to give us more options to accept the iPhone's direct input events. I think we could do a lot of cool things with the touchscreen and unique gestures if we had better access.
Finally, a big limitation is that Safari on iPhone presents pages in a large panning viewport where all elements are fixed relative to one another. As a result, web apps really behave more like web pages than real apps (not surprising since Safari is formally intended to display web pages). You can layer elements and position them as usual, but there is no independence between fixed and absolute or relative positioning when the viewport moves -- so forget floating, fixed position toolbars and the like. Ironically, a lot of the stuff that makes web apps look great in Safari 3 on the desktop doesn't work out on the iPhone because of this lack of element position independence. And the iPhone's small screen is where we need it the most.
These are just a few issues I have run into that take the glow off of developing web apps for the iPhone. There are more, but they all follow the same basic theme. Now, don't get me wrong -- I adore my iPhone and I really enjoy developing web apps and experimenting with it. But it has become clear to me that the web app path is very limiting, mostly because Apple has not actively expanded our capabilities much beyond creating generic web apps. At this stage, there is just not a lot about developing web apps for the iPhone that is iPhone-specific or iPhone-optimized. That's disappointing considering the iPhone is such a unique, breakthrough device.
For all the seriousness behind that "web 2.0" app announcement Apple floated at WWDC, there is very little in the way of substance, and maybe that's the real tragedy here. Forget the missing native SDK, how about an SDK for the official web app development path? If we really want to come up with great web apps for the iPhone, they need to look better than web pages in Safari, and Apple should be the one leading the charge. Let's see them eat some of their own iPhone-flavored dog food.