Mobile Safari Overview and Behavior
First, let's get the nomenclature straight. While Apple calls an appropriately designed web page for an iPhone an "iPhone application," I'm going to stick with the term "web page" because in the end, no matter how well the web page integrates into the iPhone's look-and-feel, that's what it is.
Mobile Safari brings lots of features to the table for developers. It uses the same WebKit rendering engine that the desktop version of Safari uses. It's also compliant with a number of the latest web standards: HTML 4.01, XHTML 1.0, CSS 2.1 and partial CSS 3, Document Object Model (DOM) 2, and ECMAScript 3, a Javascript standard. Mobile Safari also supports the AJAX XMLHTTPRequest remote scripting object. These features let the browser render most web pages accurately and manage interactive script sessions.
You probably noticed the word "most" in that last sentence. It's there for a reason. Mobile Safari doesn't support Java applets, nor (at this time) does it handle Flash content. The browser is unaware of the phone's filesystem, so there's no downloading of plugins or other files. However, it does support cookies.
Another difference is that in Mobile Safari, certain browser events have changed or have disappeared in order to support Apple's gestures interface. For example, scrolling through a web page's content by use of a finger flick requires that the iPhone's gesture interface capture and consume events that might normally be construed as mouse events. Most mouseover events, if they appear in the browser at all, are now mapped to mousedown events. For the same reasons, the hover style is gone. If your web page uses mouseover events to implement menu choices, you need to rework the Javascript handlers to respond to mousedown events or to clickable elements instead. On the positive side, the form and document elements produce the usual onblur, onchange, and onfocus events.
Finally, Apple's human interface guidelines dictate that iPhone web pages should be small, and focussed on doing one thing very well. There are valid reasons for this:
- The iPhone has a small screen. Cluttering it up with multiple windows or controls makes the web page's functions difficult to intuit or access. Nor does Mobile Safari support multiple windows, other than the temporary display of alert or dialog boxes over the main page.
- The network interface can vary in throughput. As the iPhone user interacts with your web page, the connection speed to the host can vary as the device moves between WiFi, 3G, and 2.5G wireless networks. Therefore, you must assume the worst-case scenario and design the page for the slowest network. Smaller pages load faster on slow networks, but this also limits the pages as to what they can do.
- The iPhone has constrained RAM and processing throughput. Therefore, Mobile Safari can't execute web pages with complex scripts. To appreciate this problem, point Mobile Safari to a heavily scripted web-based e-mail service and watch it take the page several minutes to render and respond. There's a reason the iPhone comes with its own native e-mail application.
In short, the iPhone's small screen, varying network speeds, and limited processing throughput dictates that you keep your web pages small and simple. You can link to other, separate pages, but they should also follow these guidelines. Lengthy page loads and with sluggish responses are only going to frustrate users so that they don't use your web application.
