Developing for the iPhone

Updated: August 03, 2007

Safari's zooming and scrolling magic works particularly well on multi-column layouts such as the NY Times web site. When you double-tap, it looks at the element that is double-tapped, and finds its closest block (e.g. DIV,OL, UL, TABLE) or the image element (IMG) and zooms in on it.

"If someone were to view a Sandvox site using that browser they would see it as it was meant to be seen," he said. "That's certainly an advantage and the fact that is built on a relatively well-known technology means a developer doesn't have to do a lot of extra work." Many developers actually began work on their applications following Apple's announcement at its world-wide developer conference (WWDC) in June that, instead of providing an SDK, the company expected developers to use web 2.0 technologies to develop for the iPhone. While many bemoaned the lack of a true SDK, the good news was they could test these sites in Safari, weeks before the iPhone was actually available.

When the dust settled, it became clear to developers, especially those that attended the first independently sponsored iPhone Dev Camp a few weeks later, that the state of web 2.0 development actually meant that some quite sophisticated things were possible, in particular those that combined Ajax with published APIs from major web services.

There are now iPhone optimized versions of Bloglines, Digg, Del.icio.us, Facebook, Flickr, and Twitter as well as apps that attempt to fill in gaps such as the lack of instant messaging, games, or a ToDo list on the iPhone. Even customer service applications are starting to appear.

When it comes to web design, there are two major concerns. One is the size of the iPhone's touchscreen. Once you've accounted for the status bar, URL text field, and keyboard, you are left with 320 x 140 pixels for your content in portrait mode. When the keyboard is hidden, you have 320 x 356 pixels. Because your users will be using their fingers as a pointing device, it is important to make targets large enough to tap on. The other concern is the speed of AT&T's EDGE network. Although the iPhone also has Wi-Fi, you'll need to ensure that sites load quickly over the EDGE network if you want to ensure a consistent experience.

Simple CSS tweaks are often enough. For example, iPhone Central, a web site devoted to information about the iPhone found recently that the way the site was designed was causing the right hand columns to load before the content columns on the right, making the site seem slow to load. iPhone Central is also experimenting with an iPhone style version of its site.

Craig Hockenberry of the Iconfactory posted another tip on his blog furbo.org. He came up with a way to optimize mobile Safari's viewport by adding a tag that lets the iPhone know how wide to display the initial page:

"Every browser besides MobileSafari will ignore this information," he said. "But it does something very important on the iPhone: it optimizes the viewport for your content. By default, the iPhone uses a viewport of 980 pixels—a value chosen to maximize compatibility with a broad range of web sites. When you specify the viewport width explicitly, you will eliminate any empty space between that 980 pixels and the width of your element. On this site the is 808 pixels wide, so there were 172 pixels of content-free space being used to display the page. On a screen that's 320 pixels wide, that's significant. So much so, that by making this simple change, the headings on my blog posts are now readable on first load of the page (previously, the text was too small.)"

Web apps are a different story.

Hockenberry wasn't as successful in trying to bring his game Frenzic to the iPhone. "It would be perfect, it is touch based and takes just 10 minutes to play," he said. "The problem is you can't play sounds through JavaScript and a game without sound is like a movie without a soundtrack." Also problematic is the need to cache large images and the relatively slow speed of the JavaScript interpreter.

One problem yet to be solved is the lack of fixed postioning for onscreen elements such as the toolbars commonly found in web apps. They scroll along with everything else.

And that's only the beginning of what is missing. While the iPhone supports some special kinds of links such as those that let you dial the phone (use the tel:identifier) or go directly to the Google Maps application on the phone rather than launch Google Maps within a browser, there's no way to access the data in the built-in apps. There's no local file storage and there's no way to access hardware such as the iPhone's camera directly.

For developers that want to get started, Apple has posted web development guideliness to its Developer Connection Web site. The guidelines cover iPhone specifics such as using the finger as an input device, screen size constraints, and speeding up JavaScript. Because the iPhone runs a mobile version of Safari, you can test your applications on Safari 3 on Mac or Windows and in many other WebKit-based browsers. For the most part the iPhone is up-to-date when it comes to web 2.0 standards. But it is important to remember that the mobile version of Safari is not identical. You'll want to consult the guidelines to learn what you can and can't do in Mobile Safari. Notably missing is support for Flash and Java applets.

The tools you'll use are also the same as you'd use for web 2.0 development. However, a few iPhone specific resources are starting to appear. Many iPhone developers have begun to take advantage of Joe Hewitt's iUI CSS framework, which mimics the flicking and scrolling interface of the built-in iPhone apps.

The Aptana IDE is a free, open-source, cross-platform, JavaScript-focused development environment for building AJax applications that can jumpstart iPhone development. It includes code assist on JavaScript, HTML and CSS, FTP/SFTP support and a JavaScript debugger along with a plugin that adds preview support for iPhone applications, allowing you to see how they will look on the iPhone.