A List Apart


Put Your Content in my Pocket, Part II

Issue № 245

Put Your Content in my Pocket, Part II

by Published in Browsers, Mobile/Multidevice, Accessibility, Interaction Design, Usability26 Comments

A note from the editors: This historically important article—part of the first series to show web designers what they needed to know about iPhones—was brilliant for its time, but is now outdated.

Hopefully, you’ve now read the first part of this series and have started to think about the iPhone and how it relates to your own web development efforts. In this second article of the series, I’ll focus on some of the things that made me scratch my head and dig around for answers or otherwise impeded my work.

If you had any doubts about the relevancy of this series to your own web properties, last week’s announcement of Mobile Safari being available on the iPod sweetens the deal: there have been over 100 million iPods sold to date. The mobile web is no longer just about phones.

Size matters

Let’s begin with the size of the screen. There are two sets of dimensions to consider, depending on how the user has oriented the device: 320×480 pixels (portrait) or 480×320 pixels (landscape). But you don’t get to use all of those pixels: the top status bar, where the signal strength, time, and battery indicators are located, uses 20 pixels of screen real estate. Then there’s the Mobile Safari address bar (60 pixels at the top) and toolbar (44 pixels at the bottom in portrait, 32 pixels in landscape).

Additionally, Mobile Safari—unlike other browsers—does not maintain a constant size for content viewing. Because of the small screen, the content area is constantly adjusted to maximize the space available for the task at hand. For one thing, Mobile Safari’s address bar moves out of the way as you scroll down the page. If the user is in portrait mode, the height of the viewport is 356px at the top and 416px further down the page (with a constant width of 320 pixels). In landscape mode, the dimensions are 208px or 268px by 480px.

Available screen real state with iPhone in vertical orientation

Available screen real state with iPhone in portrait orientation

Available screen real state with iPhone in horizontal orientation

Available screen real state with iPhone in landscape orientation

The onscreen keyboard will also hide some of your content while the user is typing. In portrait mode, the keyboard uses 260px at the bottom of the screen (covering the toolbar). The portrait keyboard uses 224px.

Remember also that viewport scaling means that your content may not be displayed pixel-for-pixel within these dimensions. If you’d like to prevent that, you can use the <meta> tag to disable scaling—a very useful trick when you are trying to emulate the iPhone UI. You can disable scaling using this meta tag:

<meta name="viewport" c user-scalable=no" />

Smart phone, tiny brain

The physical size of the display is not your only limitation. Unlike your desktop, with its gigabytes of memory, the iPhone has a much smaller area to store data. The four or eight GB of storage on the iPhone is for files, not for caching data like web pages.

Only Apple knows how much RAM is actually in the iPhone. What we do know are the limits imposed by the Mobile Safari browser when loading a page:

  • Each text resource must be less than 10 MB (.html, .css, and .js files as well as any other text-based resources).
  • Images must be less than eight MB uncompressed, calculated as width x height x four bytes. In other words, less than two megapixels. (The exception: JPEG images up to 32 MB will be loaded, but automatically resampled down to the eight MB size.)
  • Animated GIF graphics must be less than two MB.
  • Total page content size should be less than 30 MB.

Not only are there limits on how much data can be stored, but there are limits on how fast it can be processed. Again, Apple is keeping quiet about the CPU that’s in the phone, but it’s rumored to be about 400-600 mhz. Compare this with your desktop that’s running three or four times as fast.

To get an idea of the performance differences between the two platforms, I ran some simple benchmarks. The test results show that the iPhone executes JavaScript about 80 times more slowly than an average desktop computer. If your application takes 1/10 of a second to execute on your desktop, it could take up to eight seconds on the iPhone.

Because of the memory and speed limitations, the JavaScript interpreter also places limits on your code: a maximum of 10 MB of data (objects) can be created, and any JavaScript that runs for more than five seconds in a function call will be terminated with an exception.

Note also that scripts will pause frequently to minimize CPU usage. Scripts will not run during a phone call, if a window is inactive, or if another iPhone application is running. Scripts will continue to run during QuickTime playback—though there is no way to control the playback with a script.

Eight windows OK. Nine? Nein.

Finally, there are limits in the Mobile Safari browser itself. The user is only allowed to open a total of eight windows. You can create a new window using either window.open() or “_new” as a link target attribute. If you try to open a pop-up when there are no windows left, the user will see an error (“Could not open a pop-up because there are too many pages open”) and the page load will fail. This also triggers a bug in the current version of Mobile Safari: the browser history in the original window becomes unusable. My advice is to open links in the same window and let the user control the creation of new pages.

Missing in action

As you explore the iPhone, you’ll be happy to learn that the browser works surprisingly well. Still, there are cases where functionality is either missing or behaves differently than it does on the desktop.

Much of what’s missing in Mobile Safari is missing because the user is working with a finger, not a mouse. There are no gestural equivalents to many familiar desktop actions, so corresponding events cannot be generated. When developing on the phone, you’ll find that events for cut/copy/paste, drag and drop, or selection changes (select/unselect) do not fire. Other events behave differently on the phone—most notably mouseDown, which fires after the completion of a tap instead of at the beginning.

In a similar vein, you’ll find that there is no multiple-selection mechanism, since there is no Command or Control key to use while tapping. This may be a good thing: how many sites have you seen with a note to “hold down the key” next to the <select> element? Multiple selection is not an intuitive action for many users.

It’s not surprising that the showModalDialog() method doesn’t work either, since there are no such windows on the iPhone. The same is true about the print() method—there is no way to get printed output from the phone.

There are also issues that arise because of the simplified user interface. After using the phone for awhile, you’ll notice that there are no open or save dialogs. Indeed, there is no file system that’s visible to the user, so it’s not surprising that the <input type=“file” ...> does not work—there’s no way for a user to pick the file to upload.

Likewise, you’ll find that download links may not work. If the linked file is a known content type, then Mobile Safari can display it directly; if the file type is unknown, an error dialog will display (“Safari can’t download this file”) since there is no way for a user to store it. The valid content types on the iPhone are:

  • PDF
  • Excel, Word (converted to HTML on demand, they are not editable)
  • Plain Text (.TXT)
  • MOV (QuickTime)

Be aware that the following file types will not work in Mobile Safari, even though they are supported in the desktop version of Safari:

  • BMP (Microsoft Bitmap), PICT (Macintosh Picture)
  • RTF (Rich Text Format)
  • SVG (Scalable Vector Graphics)
  • AVI (Video for Windows), MPEG

Finally, there’s an interesting behavior when scrolling with a script: window.scrollTo(0,1)  will hide the address bar in Mobile Safari. Use this trick with care, since it hides the refresh button and can lead to usability problems.

The sincerest form of flattery

If you decide to build an application that tries to mimic the iPhone user interface, you’ll want to stick to some of the standards set by Apple.

Of course, you may choose your own color scheme and other branding elements, but remember that sizes for controls, fonts and other interface elements were chosen by Apple to maximize usability. You’d do well to follow their lead:


  • Use Helvetica.
  • Use bold font-weight to maximize readability (remember, your design will often be used in daylight conditions).
  • Use normal font weight for secondary information.


  • Each row should be 44 pixels high.
  • Set text at 20px.
  • Inset text 10px from edges, and center vertically in row.
  • Make controls 29px high, with 12px bold text and a 5px border radius, centered vertically in row.


  • Group items in a 300px wide box with 8px radius (10px on each side of box).
  • Set text at 20px.
  • Inset text 10px from edges.
  • Place labels above group box.
  • Inset labels 20px (so that they line up with 10px inset for group box and 10px inset for text within the box).

Standard colors:

  • Use #d9d9d9 for borders and list dividers.
  • Use #c5ccd3 for light blue (background).
  • Use #4c566c for dark blue (group box header).

A picture is worth a thousand words. Here’re some simple HTML and CSS examples that illustrate the way to define these UI elements: list example, group example.

Wire tap

Generally, it’s not a good idea to sniff the user agent when developing sites: the whole point of web standards is “one size fits all.” It’s much smarter to detect JavaScript objects and deal with the browser’s deficiencies:

if ("showModalDialog" in window)
    // show a modal dialog
    // the iPhone cannot show
    // a modal dialog, so do
    // something else

With the recent announcement of Mobile Safari on the iPod, you may find it necessary to detect the different types of hardware being used. The iPhone’s user agent will look something like this (line wraps marked » —Ed.):

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) »
AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 »
Mobile/1C25 Safari/419.3

We don’t yet know what the user agent for the iPod will be, but it’s pretty safe to assume that the platform string won’t contain “iPhone;”. If you need to know that the browser is Safari, then you can use “Safari/” and “Mobile/” will indicate that the visitor was using an iPod or iPhone. Note that “AppleWebKit/” can be present even when the browser is not Safari: this will be the case when other applications and devices, such as NetNewsWire and the Nokia S60, use Web Kit to implement a browsing environment.

Again, the best use for this information is gathering statistics, not blocking users from content.


Of course, you’ll encounter problems in your own development that I haven’t covered in this overview. I’ll finish this article by mentioning some resources that I’ve found useful in my own work. I think you’ll find that these sites will quickly find their way into your bookmarks:

  • Apple—The mothership is the first place I look if I encounter a problem.
  • iPhoneWebDev.com—A resource for more advanced information on the iPhone. If I don’t find what I need at Apple, this is the next stop in my browsing.
  • John Allsopp’s CSS3 support on iPhone—John Allsopp is documenting the extent of CSS3 support on the iPhone. This is a great resource when using more advanced CSS techniques in your designs.
  • The iPhoneWebDev Google Group—The only stupid question is the one you don’t ask. This Google group is a great place to connect with other developers who are targeting the iPhone.

26 Reader Comments

Load Comments