30 . 9 . 13

The Rules of Developing Web Apps for Mobile Devices

Rule #1: Recognise and accept that mobile devices still suck at web.

Mobile devices, although becoming ever faster and more powerful, still don’t match up in any way to the power of desktop browsers. Even the almighty iPad does not handle CSS3 as well as one might expect.

Here’s an excerpt from the Webkit trac Wiki page:

“Sometimes it’s tempting to use webkit’s drawing features, like -webkit-gradient, when it’s not actually necessary – maintaining images and dealing with Photoshop and drawing tools can be a hassle. However, using CSS for those tasks moves that hassle from the designer’s computer to the target’s CPU. Gradients, shadows, and other decorations in CSS should be used only when necessary (e.g. when the shape is dynamic based on the content) – otherwise, static images are always faster”.

There you have it, straight from the horse’s mouth.  Mobile devices still need to be handled with kid gloves when it comes to CSS3 and animations. Accept it, and adjust your strategy accordingly.

This means keeping those box-shadows, rounded corners and transparencies to the absolute minimum. Flat is where it’s at, especially if you’re doing mobile.

 Rule #2: Get Tricky.

Mobile Safari on iOS generally does not handle CSS3 animations and transitions nicely. However, there are a few tricks you can use to kick your iDevice into gear.

In modern desktop browsers CSS3 animations – on the whole – perform more smoothly than JavaScript. The same cannot be said for mobile devices, but you can get your iDevice to fire up its hardware acceleration by attaching a translate3d CSS declaration to the element you are trying to animate.

-webkit-transform: translate3d(X,Y,Z);

If your CSS animation/transition is for position or scale; moving an element on the X/Y axis or scaling in/out, then switching to the webkit prescribed translate3d method will work a lot better for you.

If you’re transitioning other properties, then attaching an empty translate3d declaration will trick the device into using its hardware acceleration for you.

-webkit-transform: translate3d(0,0,0);

Rule #3: The adjustment bureau.

Don’t forget that retina devices with higher pixel density need accounting for when dealing with font sizes.

Always remember to include a -webkit-text-size-adjust: 100%; declaration on your html or body element to stop yourself ending up with tiny text on retina displays.

This is included as standard in Paul Irish’s HTML5 Boiler plate.

Rule #4: Optimize for the right situation.

If you’re building something where initial download speed and time is of the utmost importance then the features of CSS3 may be for you.

The reduction of HTTP requests and file sizes that comes from using CSS for such things as gradients, rounded corners and box shadows can help to optimize your pages for quick download. If it’s imperative for your users to get their content quickly and they won’t be hanging around too long or interacting too heavily with your pages, go with the CSS.

However, if your users will be doing a lot of scrolling around and spending a lot of time on your pages then wherever possible use images in place of CSS. Layering images instead of using CSS3 will help reduce processing load and your pages will be more responsive as a result. Your HTTP requests and initial download time may increase, but if you’re using sprites and caching assets correctly then the trade-off for a better user experience after the download is complete seems to be one worth making. It’s just a case of finding the right balance for each project.

Rule #5: The bigger picture.

Bandwidth and file sizes should always be a consideration for mobile content. The bigger the image, the larger the file size, the longer the download and the more slowly your web app will perform; simple really. So if your content strategy is to make up for a lack of content with a big image, or you just think it looks great, think again! It will not look so great when it starts blocking and glitching across the screen.

Rule #6: Either or, neither?

A key question to ask yourself and everyone involved in the project before writing a single line of code is: ‘What platform am I developing for?’.

Is this a Web App delivered to end users via a browser, be that a mobile browser or otherwise? Or is this a Native App delivered as a packaged piece of code to be downloaded and installed by the end user?

Or are you in fact developing for some quasi environment that is a heinous amalgamation of the two? I’m talking here about the ‘UIWebView Class’. This is basically a frame within a native iOS App used to display, primarily, pdf content, but also HTML5 content. Take serious note of the fact that the UIWebView Class is not mobile Safari or any other genuine browser. It does not handle or render content exactly as you might expect.

What does this mean? It means yet again that you are going to have to leave out any nice CSS3 transitions or effects that you had in mind as the UIWebView Class may baulk at them and can even result in the iOS App crashing.

The feature image that accompanies this blog is an original creation by our designer Gav Cannon.