articles
So, you want to develop iPhone apps?
So, you've been hankering to developer iPhone apps since January's keynote when the iPhone was announced. You eagerly awaited Apple's WWDC, when you prayed the SDK would be released. You learned what some consider good news, and some bad, that the way to do apps for the iPhone is to build webapps.
And still, despite the phone's release, hard and fast details of just how you do this remain thin on the ground. Word was that attendees at the WWDC had the inside scoop on the kinds of technical details you need to do it right, but all attendees were under and NDA, and no one was spilling the beans.
The phone came out, and we still didn't know which version of Webkit its copy of Safari was running, of what events your app would receive when the user interacted with the screen. Just how much screen real estate could you rely on? And how could you write style sheets which targeted just the iPhone?
The last few days, a lot of people have been trying to piece these puzzles together. One great source of information is iPhoneWebDev. Apple themselves have released some details, but they are still pretty scant, to tell the truth.
According to Apple
"Safari 3 Public Beta, now available for Mac and Windows, provides you with the ideal environment for Safari on iPhone compatibility testing"
But is that really the case?
Safari on the iPhone presents some significant, indeed arguably profound challenges to developers. The way users interact with the device is very different from the way most people interact with web content on desktop or laptop computer.
The events that your Javascript receives when the user interacts with a page are different from those you'd expect even from Safari on the Mac or on Windows.
While Safari for the iPhone is based on the same rendering engine as Safari, WebKit, it is not the same as that in Safari 3. What CSS properties and selectors are supported on the iPhone - are they all tat are supported in Safari 3? And if not, which are missing?
How does the iPhone display pages that are greater than the phyiscal width and height of the iPhone display? Are they cropped? Scaled? As developers can we have some say over what happens? And just how much screen real estate is avialable for web content on the iPhone?
How can I get the iPhone to ignore particular style sheets? How can I link to a style sheet in such a way that only the iPhone will use them?
In this and subsequent articles, I'll try to answer at least some of these questions. Because I am in Australia, I've not been able to get my hands on the device, and so what I've gleaned comes from a combination of Apple's documents, screenshots, and information posted by other, particularly over at iPhoneWebDev, some of it in response to questions I've asked. Thanks very much to all those who've provided information, answered my questions, and generally helped us all get our heads around these issues.
I'll start with addressing the issue of how is content displayed on the screen? Is it scaled? Is there anything we can do about that? And just how many pixels does web content have to be displayed in?
What you see is, well, what exactly?
The iPhone has a screen size of 320x480 pixels, at a resolution of 160dpi.
This means that any page will have at most 320 pixels x 480 pixels to display in - whether these relate to height or width depends on whether the phone is in landscape or portrait mode, which the user can change between simply by rotating the phone. In fact, it's not quite that simple, because the phone itself has a status bar of 20px high, a top "url text field" (think of it as the application's toolbar) of 60px high, and a bottom toolbar which accounts for at least 32px (in landscape mode, and 44px in portrait mode).
While there is a trick to scrolling to hide the top toolbar (but not the status bar), that's probably not recommended, as it's rather radically changing the user's experience without their involvement. It's not clear whether the user can hide these toolbars to increase real estate size, or whether that's something we might see in future versions.
So, in summary - in portrait mode, the actual area for displaying a page will be 480px minus
- the status bar - 20px
- the top toolbar - 60px
- the bottom toolbar ("button bar") - 44px
Giving a grand total height for the content of a page of 356px, and a width of 320px
In landscape mode, the height available for your content is 320px minus
- the status bar - 20px
- the top toolbar - 60px
- the bottom toolbar ("button bar") - 32px (yes, it's slightly less tall in landscape)
Giving a grand total height for the content of a page of 208px And a width of 480px
It gets a bit more complicated again. Where a page is wider than the device width, Safari on the iPhone does not display a page as you might expect, by clipping the page at the width and height of the device, and adding scrollbars, as would happen in a desktop browser if you set the window (or technically the "viewport") width and height to say 376px by 320px.
Instead, when you load a page, Safari on the iPhone scales it as if the viewport width was in fact 980 pixels.
so instead of this
we get
When a user loads a page in Safari on the iPhone, Safari scales it to fit horizontally on the screen with a notional screen width of 980px. The particular complication comes when your page is actually designed to work on the iPhone, and has for example a width specified using CSS of 320 pixels. What happens then? The content will in fact be scaled down, which is almost certainly not what you intended.
What's technically going on is this. Safari has a notional "viewport" element, which has width, height, initial-scale, minimum-scale, maximum-scale and user-scalable properties. You can set one or more of these using the meta element in your page, and Safari determines the other values based on these.
If you have designed pages so that they work explicitly for the iPhone, you'd want to set a viewport width, so that Safari doesn't scale your page to fit at a notional width of 980 pixels, but rather, displays it at the specified width.
You do this with the meta element in the head of your HTML document, like so
<meta name="viewport" content="width = 320" />
Another, and at first glance cleaner approach is to set the initial-scale value to 1. If you do so, according to Apple's technical documentation "Safari assumes the width is 320 pixels in portrait and 480 pixels in landscape mode".
You do this as follows
<meta name="viewport" content="initial-scale=1" />
It's clearly early days for both the developers of content, and Apple as well, when it comes codifying best practices in developing content for the iPhone. I'm interested as to why Safari's developers decided to use the meta element in HTML, rather than using explicit widths set on the HTML element in particular style sheets - for example in style sheets targeting the iPhone using media queries, which we'll discuss shortly.
As mentioned, I haven't actually got my hands on an iPhone, due to the fact they simply aren't available in Australia. So this information is gleaned from official Apple documentation, as well as from reports by users. A great forum for discussing and learning about these issues is the iPhoneWebDev google group.
If you have any comments, questions, corrections or follow up on this article, please drop by my blog and leave comments there.
In the next installment, CSS properties and values supported in Safari on the iPhone
John Allsopp is a director at westciv and the lead developer of Style Master CSS editor. He writes widely on web standards and software development issues and maintains the blog dog or higher.