A few days ago we got iPhone fever with the rest of the world. We decided to build a SurveGizmo Mobile Poll application for the iPhone, which you can view at mobile.surveygizmo.com. We learned a few things about developing Web 2.0 applications for the iPhone worth sharing!

Various sources like Gizmodo, FiGMA, and MyiTablet and were reporting iPhone development tips from the recent Apple Developer Conference (WWDC). These tips were helpful but a little misleading. Actually playing with an iPhone changed our approach. Here are some tips we picked up.

10 (+1) Tips for iPhone Applications

#1 Content width

Web pages on the iPhone default to a birds-eye view. This is great when you are browsing CNN.com, but iPhone applications should fill up the entire screen without requiring the user to zoom in and out. Many of the content apps are created to take 100% of the screen and scale down appropriately, but we found this didn’t work well for iPoll, which is just a small page with a form. Here’s the solution, set the viewport metatag. This allows the developer to work in a div of fixed size and tells the iPhone how to render the page.

<meta name=”viewport” content=”width=320″ />

#2 Content height

The iPhone browser is designed to scroll with your finger not browser or div scroll bars, so this means that you don’t want to use fixed height designs. We had a lot of trouble with overflow CSS property. We suggest you leave that property alone and let the iPhone do the work.

# 3 Increase the size of form controls

The iPhone uses fingers for making selections. It’s very intuitive but it also makes spacing and sizing your form elements very important, especially for radio buttons and checkboxes. Here is some good news. Safari on the iPhone accepts width and height settings for radio and checkbox controls! It makes them larger and easier to select with your finger. Yes, you can do this with images too, but consider your bandwidth. iPhone apps should be written to work on EDGE.

# 4 Label Tags – still do not work in Safari

Sadly the label tag still does not work correctly on the iPhone. It would be nice, but you’ll have to code around this.

#5 Cache? — Kinda

The iPhone browser does cache content… but it doesn’t help the download speed much. We will do more testing on this, but it seems that every page load creates separate requests for cached content for every external resource (even if previously cached). Likely to do header checks. That’s fine and dandy, but on EDGE it slows things down and your page will not render until all external resources are loaded. So keep your external resource links to a minimum. Use modern design tricks for displaying multiple images from one file, only include the JS libraries that you need, etc.

We also suggest building multiple UI’s into a single file and using JS/CSS to navigate between them rather than moving between pages.

#6 Web 2.0 Javascript libraries – use with caution

The iPhone speed over EDGE can be slow, very slow. We wrote our first version of our Mobile Polls app with Prototype and script.aculo.us, but loading 50-100k of JS proved to not be terribly practical, at least for us. The application was too sluggish to be effective.

#7 Web 2.0 Animation effects

We experienced latency issues that seem to negate the benefit of web 2.0 animation effects like color highlighting, slides, accordions, etc. The effects didn’t seem to keep up and made some UIs unusable.

This is not a problem with the iPhone, really, but be aware that effects occurring after the “onload” event may not render well. They will be competing with whatever mechanism the WebKit uses to thumbnail the page, and you’ll get choppy animation.

#8 Use tab-enabled form elements

The iPhone makes good use of tabbed form controls. The keyboard has a “next” and “back” button for tabbing between them without losing focus on the keyboard. So, use elements like form fields and anchors for interaction rather than divs with onclick handlers. Your users will thank you!

#9 iPhone HTTP User Agent identification

As Mac Rumors reported the iPhone sends this header.

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

This allows for serving custom content or alternate styles sheets etc. iPhone Geek has already created a helpful php iPhone detection script.

#10 Hover Effects — don’t bother

Since there is no mouse, hover effects don’t work. You’ll need to build UI’s that provide other kinds of clear feedback or at least don’t rely on it. Make your interactive elements very clear.

Bonus Tip (just added) – The “Share” button alternative

The iPhone browser has a feature that Safari does not, a ‘Share’ button that emails your current web address to contacts in your iPhone. Dandy! Sadly, though, the button only appears when editing an URL, not when browsing. Our application needed this functionality (actually, we wanted access to the contact database so we could generate text messages), but we didn’t want to teach people to use the Share feature.

So, remember this ‘old’ trick? Use an old fashioned “mailto” link with &subject= and &body=. This allowed us to provide the same function with a single click on the web app itself, plus we could include some default text.

If you want to use multiple lines you need to use <BR> tags, not escaped line breaks. The iPhone email client is HTML based… it doesn’t respect \n breaks passed in the URL.

Happy iPhone Developing!

Tags: ,