• 22-Oct-2007
• Crowne Plaza Hotel
• Seattle, WA

This talk was part of a traveling road show done by Apple to show developers what they need to get their web sites and applications to work optimally with the iPhone.

Safari on iPhone: Compatibility, Optimization, Applications

Apple Developer Connection’s Web Development for iPhone

Developers have three choices for making their web sites/applications work well with the iPhone:

• Compatible – The page is standards-based, and operates on the iPhone just as it does on a desktop web browser. No dependency on Java, Flash, or plugins.
• Optimized – In addition to being compatible, it scales for readability, minimizes zooming and panning, is finger friendly, is tuned for wireless, and may integrate with some built-in iPhone applications.
• Application – On top of being optimized, it provides discrete functionality, looks, feels, and integrates with built-in applications, and minimizes the user awareness of a browser experience.

Compatible

If the application works on Safari 3.x, then it’ll most likely work fine on the iPhone. Much of what they outlined is true to make sure a page works across many browsers and platforms (work both with and without JavaScript, use standards, separate content from presentation from interaction, detect objects rather than looking at the browser signature, etc.)

The iPhone understands CSS Media Queries, but acts as a “screen” browser rather than “handheld”, since the way the browser renders pages is much more akin to a desktop than current handheld devices. You can, however, have your CSS test for the device’s dimensions.

Resource limits were outlined (10MB per text resource, 8MB image etc.) For scripts, JavaScript is limited to a 10MB heap, and script segments can only execute for 5 seconds.

The iPhone can natively render Excel spreadsheets, PDF, Word documents, and QuickTime. It also fully supports the Canvas element. The iPhone has no filesystem, so it can support neither downloading nor uploading of files.

Optimized

Optimizing a page for the iPhone is an extension of making it compatible.

All content is first rendered as if the window were 980 pixels wide by 1091 pixels high. After that, it is scaled to fit onto the display. You can change the default rendering by setting the meta property “viewport”, and can also change the scaling behavior. You can also change text scaling in CSS with the -webkit-text-size-adjust property.

While it may seem like a small change to use fingers instead of a mouse or pointer, it really does change how a page needs to be coded. Apple recommends at least 40 pixels for targets, much larger than the smallest size a user can comfortably hit with a mouse. Also, scroll bars aren’t visible, so objects within a page which scroll will show no cue that they can be scrolled (scrolling with a single finger scrolls the whole page; scrolling with two fingers will scroll the object, however).

Webkit on the iPhone will call JavaScript events for tapping, panning, flicking, panning with two fingers, and rotating the device. It will also call the events associated with forms. However, since the iPhone doesn’t have cut, copy, paste, drag and drop, or selections, events related to those are not called.

To make sure your page won’t be too slow, it’s good to think of the EDGE network as a little faster than a modem. Developers should minimize image use, don’t send scripts which aren’t going to be used, and use things such as AJAX to have content sent in chunks. In addition, server-side compression really helps.

Applications

The biggest aspect of making a web page an iPhone application is the browser will seem to disappear to the user, and it will feel like a native iPhone application by using similar layout and animation. It should also integrate with the built-in applications (Google Maps, dialing, email, etc.)

Apple acknowledges that there is still much to do with the iPhone, and the wish list is already pretty long. The presenters all encouraged developers to file bug reports and requests, since that helps Apple to see what features are most requested.

iPhone User Interface Design

This talk stressed that design is critical, and that’s not surprising since that belief is true throughout all the products delivered by Apple. The steps outlined were to define your solution (including saying no to things which will keep you off the right track; you should focus on the solution, not the features), design your workflow (how the user interacts with the application; should be easy to use, minimize text entry, be quick, and follow the UI on other iPhone applications), and refining your appearance (make it appear like other iPhone applications, maximize the content shown while minimizing how much space it takes).

This talk let me to have many thoughts on how several web pages could be altered to look better on the iPhone than just like they do on the desktop.

Managing Content and Synced Data for iPhone

This talk was actually the catch-all for topics not previously covered.

In many ways, Dashboard widgets have a lot in common with iPhone applications – they’re built with HTML/CSS/JavaScript, they need to fit in a small area, and they need to be very conservative in their use of resources.

For video, QuickTime Player Pro already knows how to generate video for the iPhone. In addition, it’s recommended to use a Reference Movie, so QuickTime can automatically select the size of movie which would best work with the current connection (whether on EDGE or WiFi).

For user data integration on the Mac, using the frameworks for the Address Book, iCal, iTunes, Safari Bookmarks, and iPhoto are the best bet. For Windows, many of the things are synced with Outlook.

Lab

The rest of the afternoon was dedicated to giving developers access to the Apple employees who were there, representing a wide range from technical questions to evangelism.

I spoke a bit with the person who gave the UI talk about the UW Home Page, and he agreed that while it wouldn’t be too bad to reformat the page to fit better on the iPhone (reduce the use of columns, have subpages for things such as QuickLinks or Visit the UW), it’s probably not appropriate to try to think of it as an application. In addition, it would be difficult to have iPhone-optimized pages go beyond perhaps the top pages.

It seems that the Campus Maps would be a good target for optimizing or even making an iPhone application, since it would be something that iPhone users would want to use a lot. The White Pages would possibly be another good iPhone application.

At the end of the day, people showed off their own applications. In fact, one photographer did a first cut at changing his portfolio web site to be an iPhone application.