Getting Started with iOS Web Applications: Block Best Practices

Being relatively new to building Web applications for iPhone, iPad and other Webkit/iOS browsers, I’ve been spending more and more time searching through the Apple Developer Safari Reference Library.

It’s a very complete resource, but so far, I’ve found it to be mildly frustrating for the beginner. For instance, constructing a basic block requires referencing about 3-5 different pages in the Apple documentation (that don’t link together in a meaningful way), as well as a variety of third-party developers’ sites.

So, I’ll step through what I typically do, explaining it line by line. Hopefully it will help someone who might otherwise go through the same problems I experienced when I was first getting started with Web app development for iOS mobiles and Webkit. I’m not saying that this is the 100% best way to do it; it is the way that seems to work best for me. If you have any suggestions to improve it (or refute some of my thinking), please feel free to comment on this post or contact me directly.

What Character Set?

First up, the http-equiv meta tag. I always encode my pages for UTF-8 because I typically deal with users around the world who have Web browsers that may render local characters incorrectly. UTF-8 allows for a large character set. Learn more about UTF-8 at UTF8.com.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

This Really is a Safari Web App

Setting the apple-mobile-web-app-capable meta tag to yes means that the page can be added as a full-screen app, and run “outside” of Safari. I say outside in quotes, because really it is still running using the Webkit rendering engine, but the user isn’t presented with the URL bar, or other chrome that, while useful when browsing the Web, only gets in the way when he or she is using your Web app.

<meta name="apple-mobile-web-app-capable" content="yes" />

The Status Bar

Next, we define how the top bar looks (the bit that has the carrier, time and other system-wide icons). By default, this value is default, meaning, a grey chrome finish and completely opaque. Lately, I’ve been going with setting this to black which is how it sounds. The other option available is translucent-black. This lets your app “bleed through,” which sounds like a good idea, and can look nice if you take this into consideration when you build your mobile Web app… but in practice can end up looking a little sloppy in my opinion.

<meta name="apple-mobile-web-app-status-bar-style" content="black" />

Viewport vs. Window

The viewport is one of the tricker concepts to understand. By default, iOS Safari renders content in a window with a 1024 pixel width. It then scales things down using it’s own logic to fit what it can on your screen (the viewport). The basic idea is that the viewport is inside of the window. On the desktop version of Safari, the two are set to the exact same size.

What I’ve found to work best for the iOS devices is the following. Basically, I’m saying, set the scale to 1:1 (make the viewport the same size as the window); the width should be the device’s width (this is a constant that changes based on rotation of the device — better to set it to this than to give a static width); and don’t let the user scale anything (again, because I’ve designed this as a Web app, specifically for iOS, there should be no need to scale).

<meta name="viewport" content="initial-scale=1.0, width=device-width, user-scalable=no" />

Auto-Detect Phone Numbers

Many of the Web apps that I work with extend digital asset management systems, and so they include things like identification numbers for TV commercials, print job numbers, etc.; rarely do I use telephone numbers in my Web apps. So, I turn off automatic detection of telephone numbers to prevent bad links. Your Web app may be different, and you might want this behavior… if so, then by all means, skip over this line.

For me, I start with no phone number detection, and then flag items manually that should be sent to the phone (for instance, a technical support phone number in the footer). For this type of scenario, I’ll use a tag like <a href=”tel:212-555-1212″>Support by Phone</a>. Using “tel:” as the first part of the href let’s Safari know that the link is be sent to the phone app rather than as a Web link.

<meta name="format-detection" content="telephone=no" />

Default Home Screen Icon

By default when you click the “+” icon in Safari to add a Web app to your home page, Safari will take a screenshot and use it as the icon. Generally, this isn’t very pretty. You can supply a more user-friendly design by uploading a 57×57 pixel PNG (not GIF or JPG), and pointing apple-touch-icon to it. Don’t include any rounded corners, or the glass/glow art — Safari takes care of this for you. There is an alternate meta tag that allows you to supply a pre-composed image instead, but generally, I don’t go that route.

<link rel="apple-touch-icon" href="/lib/media/apple/icon.png" />

Startup Image

Similarly, you can provide a “startup image” that displays before your Web app runs (actually, it displays while the device compares its cached version of your Web app to the live version on your server, and if there are differences it downloads them). This should be a 320×460 pixels in size, again in PNG format. Remember, this will only appear when your Web app is running full-screen (i.e., when you click on it from your device’s home screen); it doesn’t display when browsing to it in Safari.

<link rel="apple-touch-startup-image" href="/lib/media/apple/splash.png" />

Localized CSS

Lastly, I link to my stylesheet that defines styles specific to the Web app. If you’ve used any third-party libraries to help with layout, they would appear before this link so that you can override any styles locally. Some examples of these libraries are iUI and iWebKit.

<link rel="text/css" href="/lib/css/ios-common.css" />

Does Order Matter?

I don’t really know. Typically, I organize my <head> block by placing any <meta> tags first, then <link> tags, and then the <title> tag. I really don’t think that this matters much, but I’m a fairly visual person, and having things grouped this way makes it easier for me to browse my source code.

In Summary

In summary, here is the completed <head> block:

<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
<meta name="viewport"
content="initial-scale=1.0, width=device-width, user-scalable=no" />
<meta name="format-detection" content="telephone=no" />
<link rel="apple-touch-icon" href="/lib/media/apple/icon.png" />
<link rel="apple-touch-startup-image" href="/lib/media/apple/splash.png" />
css" href="/lib/css/ios-common.css" />
<title>Name of Your App Here</title>
</head>

You may also like...

2 Responses

  1. Bretislav Beranek says:

    Thanks Andrew for providing info on iPhone and iPad web app development, very usefully and much appreciated!

  2. Nicolas Embleton says:

    Very nice post. Centralizing some very cool info. Thanks.

Leave a Reply

%d bloggers like this: