Tips for iOS-Optimizing Your Website
Viewing the web through a pocket-sized screen is a different experience than viewing it on a massive desktop screen. It deserves an experience optimized around it. Unfortunately, mobile webpages often come up short, especially when compared to their desktop counterparts. From the very beginning, I designed AfterPad specifically for mobile – The iPhone was the target size, and the iPad and computer versions were modifications to the iPhone UI.
This comes with a number of weaknesses – I’d really like to have a few more tabs on the top of the site – but it also comes with strengths. When iOS is your primary platform, you can throw away a lot of legacy “best practices”, AND take advantage of some iOS-exclusive features.
Throughout the process of building AfterPad, I’ve found some handy tricks to make the site feel a lot more “at home” on iOS. I am not, by any means, a master web designer, but I figured I should share some of the techniques I use.
This is not a complete guide to web design, or even a complete guide to mobile web design. But it does have a few cutting-edge tricks that a lot of web designers might not be aware of.
Set your Viewport equal to device-width
This is a basic step – definitely not a cutting-edge trick – but any guide to making a mobile-friendly site wouldn’t be complete without it.
Mobile Safari was designed for an era of desktop websites. Because mobile versions of websites didn’t exist when the iPhone was released, Apple employed a clever trick to make standard websites look good. By default, Mobile Safari creates a fake screen that’s 1024 pixels wide, renders your page inside this fake screen, and allows people to zoom in to see the full content.
This is how the iPhone displays the “full Internet” – it emulates the size of a traditional computer monitor. This makes a ton of sense for sites that are designed assuming most people’s monitors are 1024 pixels wide. But for mobile themes, you need to address the real width of the iPhone screen.
The following code, in the head section of your HTML, turns off Safari’s fake desktop rendering:
<meta name="viewport" content="width=device-width">
If your website is designed to emulate an app-like experience, or if it uses fixed-position elements, you can go further than this by preventing users from zooming your page.
To prevent zooming, use the following meta code, instead of the above:
<meta name="viewport" content="width-device-width, user-scalable=no">
If you decide to prevent visitors from zooming in on your site, you need to be extra careful to make your site’s text readable, especially for people with vision problems. You should definitely implement the next trick:
Take Advantage of Dynamic Type
This is a new trick. Very few websites take advantage of it, which is a shame, because it’s one of the most important features to ever come to Mobile Safari.
With iOS 8, iOS introduced Dynamic Type, a system-wide way for users to control text size. Not only does this provide a great way for users to personalize their reading experience, but it also acts as an accessibility control, allowing far larger text sizes for users with vision problems.
Safari traditionally didn’t need this, because it was possible for users to zoom-in and magnify text they wanted to read. However, many mobile websites opt to block zooming, making for a more native-feeling experience, but one that can be difficult to read for people with vision problems.
If your mobile site blocks zooming, you should implement dynamic type. You may think you know best about text sizing, but for people with accessibility concerns, you probably don’t.
To implement dynamic type, add the following rule to your CSS. It can be used site-wide, specifically for paragraph elements, or anywhere in between. This example assigns it site-wide to the body element:
body {
font: -apple-system-body;
}
Because this code must be assigned to the “font” shorthand property, it changes both the font-size AND font-family properties. Unless you want to use Apple’s San Francisco font on your website, you need to add the font-family rule below the “font” rule, which overrides San Francisco with the font of your choice.
Keep in mind, if you’ve assigned dynamic type to a parent element, you can override it for a child element by assigning a font-size to the child element. If you use em units to define the size of child elements, they’ll even scale according to the user’s dynamic type setting!
Consider Using iOS-Native Fonts
I know that bundling “premium” web-fonts is popular, but they come with downsides. They take time to download. During that time, you can either display nothing – your text is blank for a second or two, then blinks in all at once – or you can display a fallback font – your text shows up using a native font, then switches awkwardly to your fancy one after the fancy one finishes downloading.
The good news is, you might not need to do either of these. The font situation on iOS is better than you think. Apple bundles several excellent fonts with iOS, and you can use them all on your website with zero performance penalty and zero license fee.
iOSFonts.com keeps track of every font available on iOS, and let’s you see which fonts are supported by each version. If you happen to like any of these fonts, you don’t have to any special tricks to use them: simply add the font name to your “font-family” property.
body {
font: -apple-system-body;
font-family: "Avenir Next", "GillSans-Light", sans-serif;
}
Note: if you’ve taken advantage of the dynamic-type feature mentioned above, you’ll need to place your font-family rule below your dynamic type font rule.
Prevent Automatic Text Resizing
Mobile Safari likes to resize fonts. In the early days of iPhone web browsing, websites weren’t optimized for small screens. The iPhone would show you a shrunken-down version of the desktop site, and you’d zoom-in on the part you wanted to read. To make it easier to see what you’re zooming-in on, Safari would magnify the text in paragraph blocks, often making the body of an article larger than its heading.
If you’re hand-tuning your site for mobile, your text should already be optimized for reading on a mobile device, and you might not even allow zooming.
To prevent Safari from automatically resizing text, add the following rule to your CSS:
body {
-webkit-text-size-adjust: 100%;
}
Note: this rule is unrelated to whether users are allowed to zoom, and has nothing to do with dynamic type. If you allow zooming, visitors can still enlarge text by zooming in. If you’ve adopted iOS dynamic type, font size will still be influence by the global dynamic type iOS setting.
Use 16px font-size for Text Boxes
This is a lesser-known requirement. If your website uses a text box where visitors input text – for a search field, a forum post composition field, anything like that – set the font-size of those fields to 16px.
If you don’t do this, Safari zooms in every time your visitor taps on the text field – it really wants text-input fields to be 16px, and it’ll magnify things until it gets its wish. It sometimes does this even with zooming turned off, and the default viewport set to device-width.
Use the following code to make Safari stop zooming-in when visitors select a text box:
textarea,
input,
select {
font-size: 16px;
}
This is one of those little things that makes a big difference.
Use max-width and width Properties for Images
This is one of the quickest and most effective ways to make a mobile-optimized version of your site. It’s most useful on blogs. On mobile version of most blogs, embedded pictures look best when they’re the full width of the iPhone’s display, possibly with a small margin. On desktops, with much wider displays, these pictures would look far too big.
There’s an easy solution: instead of using the width property to control the width of your images, use max-width. Then set the width to 100%. Then, if you want to center the images, set the left and right margins to auto and the display mode to block.
img {
width: 100%;
max-width: 640px;
display: block;
margin-left: auto;
margin-right: auto;
}
The above code will make every image the full width of its container, up to a maximum of 640px wide. Any wider than that, and the image will be centered, with margins filling the difference. These are the exact values I use on my site. The same trick can be used for any element – quote blocks, videos, paragraphs of text. This is an essential tool for making a responsive mobile site.
Customize the Tap Highlight Color
Web designers often use JavaScript touch events to customize the tap behavior of buttons and links. This works, but it never feels quite right – it tends to trigger when you inadvertently tap something while scrolling, which looks jankey and feels out-of-place.
You might be able to get away with customizing iOS’ standard tap highlighting instead. The following code changes color of the box that appears when you long-press a link to red:
a {
-webkit-tap-highlight-color: rgba(255,0,0,0.1);
}
Note that the tap highlight appears over the link, meaning it must be slightly transparent, or it obscures the link.
AfterPad uses only the -webkit-tap-highlight-color property to control the appearance of selected elements. By combining it with padding, it’s possible to have somewhat native-feeling list boxes, without the overhead of using JavaScript.
Optimize for Safari’s Reader View
Safari Reader View is a tool that allows website visitors to see just the content of an article, with none of the cruft. You might not like the idea of people stripping out all the sidebars and navigation tabs (and ads) from your site and just viewing the text, but the fact of the matter is, people do it. And if your site looks broken in this view, you’re the one who looks bad. The good news is, the tricks here will likely increase your search position in Google, and should also make your site easier to read in Instapaper, Pocket, and Readability.
The most important thing you can do to make your site work correctly with Reader View is make sure your site is built on well-formed HTML. Writing good HTML is outside the scope of this article, but the basics are important.
- Don’t have multiple h1 tags in a single article element.
- If you aren’t using article elements, don’t have multiple h1 tags at all.
If you screw these things up, Safari might not know what the title of your post is supposed to be, and it could make the mistake of assuming one of your sub-headings is the title.
Another major rule: Reader View will generally only work for articles with a minimum of around four paragraphs. Any less than that, and it doesn’t usually show up.
There’s one extra rule that screwed my site up for a long time: you can’t wrap the content of your article in a container. Your h1, h2, or header elements MUST be in the same container as the p tags that make up your article.
The following code does not work:
<article>
<header>
<h1>My Great Article</h1>
</header>
<section>
<h2>Introduction</h2>
<p>[paragraph 1]</p>
<h2>Main Point</h2>
<p>[paragraph 2]</p>
<p>[paragraph 3]</p>
<h2>Conclusion</h2>
<p>[paragraph 4]</p>
</section>
<footer>By WriterPerson</footer>
</article>
If you write the above code, Reader View will think your article is titled “Introduction”. That’s because the h2 header containing the word “Introduction” is the first heading element inside the box that contains your p paragraphs – in this case, a section element.
<article>
<header>
<h1>My Great Article</h1>
</header>
<h2>Introduction</h2>
<p>[paragraph 1]</p>
<h2>Main Point</h2>
<p>[paragraph 2]</p>
<p>[paragraph 3]</p>
<h2>Conclusion</h2>
<p>[paragraph 4]</p>
<footer>By WriterPerson</footer>
</article>
The above code will probably work. Because there is an h1 element inside the same block article with all the p paragraphs, it will be assumed to be the title of the article.
Still, Reader View is a mysterious and fickle beast. Even if you take advantage of the above advice, your articles still might not work correctly. But if you don’t take advantage of this advice, they almost certainly won’t work. Take this advice as a starting-off point.
Allow Smooth Scrolling in Scrollable Elements
By default, Mobile Safari is designed around the idea that when you drag your finger on the page, no matter where your finger is, the entire page scrolls. This is a perfectly reasonably assumption, but sometimes it doesn’t hold up. If you have a site with a separately scrollable element – say, a sideways-scrolling image box or a vertical-scrolling description view – you’ll need to employ an extra trick to make scrolling work correctly.
The traditional way to make a scrolling element is by setting overflow: scroll on that element’s CSS. The problem is, if you just do that in Mobile Safari, scrolling feels very wrong – there is no bounce, no acceleration, and no smoothness.
The following CSS fixes this problem:
.scrollingBox {
-webkit-overflow-scrolling: touch;
}
If you add this code, scrolling in subviews will feel just as smooth as scrolling in a native app.
Don’t Beg People To Install Your App
Look, I get it. You’re proud of your app and you want people to use it. You know how much better it is than your website. You know how valuable it is to be installed on someone’s device. You know that if you don’t get a reader to install your app right away, they might forget. You know that if your site uses ads, some of your visitors are blocking those ads. None of this matters – you still shouldn’t irritate visitors about installing your app.
If your website is terrible, visitors are likely to assume that your app is also terrible – why on earth would anyone install it? Would you? It’s far easier to build a website than it is to build an app – if you can’t even build a good website, nobody is going to install your app, no matter how much you beg them.
If you have an app, and you absolutely must tell your visitors about it (like if your site only exists to support your app), there’s one way you should do it: using the official APIs provided by Apple and Google.
I’m not going to get into the details here; Apple provides a great website with more information on how to do this.
Users hate app pop-ups. Google has recently started penalizing sites that don’t take advantage of the official APIs. Do the right thing here.