Choosing devices and levels of support

When you're setting out to create a mobile web experience for an app, one of the first questions you have to be able to answer is, "Which devices are you going to support, and what is the achievable UI experience on those devices?" Answering this question is not always intuitive or straightforward as it depends on a number of factors.

Determining which browsers and devices to support

Choosing which devices and browsers to support is somewhat of an organic process, and a decision that has no right or wrong answer. Ideally, you want to support as many browsers (and therefore users) as possible. In practice however, the decision is somewhat of a balancing act between the project goals, the available budget, the availability of stable and well-distributed web technologies, and the device market share of your target audience.

If mobile development is new to you, you may not be familiar with the range of mobile browsers or devices. You therefore won't know what features are supported on what browsers, and consequently which devices you should support.

This is not as much of a problem as it seems. Unless you're building a product for a very specific audience (for example, a large corporate sales force where everyone carries the same brand of device) it's probably safe to presume that you will always need to support a variety of browsers and devices. As a matter of fact, even within such a sales force group, there may easily be 5-10 different device models, various screen sizes, and multiple form factors and browser versions.

This diversity will be present even when targeting popular devices such as the iPhone. There have been four versions of iOS since the platform launched, and although all iPhones have the same screen size, new browser features have been introduced with each operating system release. So although they appear quite similar, an iPhone 4 with iOS 5 will have different capabilities than an iPhone 3GS with iOS 4.3.5, or even an iPod Touch with iOS 4.3.5.

Now that you know you'll need to support a range of devices, let's determine just how wide this range should be. The best way to begin is by considering the features and overall experience of your app.

Considering features

First, determine the key features and behaviors of your app, and whether these require specific technologies. If, for example, your app makes heavy use of location coordinates, you may need a mechanism to detect the user's location. The HTML5 geolocation specification provides a fairly simple API that could generate highly granular coordinates, but the technology is not yet well supported across all devices.

This simple example illustrates the type of choice you will have to make.

  • If you decide that you only have the resources to implement and support HTML5 geolocation, you will have no choice but to exclude many older smartphones as well as most feature phones that lack such support.
  • If you decide that excluding these users is unacceptable given your business goals and the market share of these devices, this decision will in turn impact the resources you will need to devote to both design and the development of a secondary location detection method.

Starting with key features is important as the decisions you make may require or completely eliminate specific browsers or devices.

By comparison, the need for other technologies—for example CSS3 transitions or HTML5 video—may be considered simple enhancements (the absence of a transition doesn't typically affect functionality, and most platforms provide an easy means to launch video in a standalone native player). Rather than eliminate devices that don't support these features, it would make sense to detect support for them and only load the appropriate resources and scripts if the feature is supported.

Experience and context of use

Also related to technology factors are the overall design goals of your app. Some apps are designed for all-purpose use, while others are specific to a particular context or behavior such as shopping, watching TV, or inputting complex data in the context of work. These factors may inform the type of device that will be used, but that should still be considered carefully. Recent research indicates that users often spread tasks over periods of time and make use of whatever device is available to them. The fact that your app enables users to purchase and download films for use on their TV doesn't mean they won't spend their one-hour train commute browsing and bookmarking films on their phone for later viewing at home.

Market penetration within your audience

Next, examine the market penetration of the various mobile operating systems in the region your product operates in. Most mobile operating systems are popular all over the world, but you will still find significant differences from region to region. (1)

If you have a pre-existing desktop web version of the product, it's also important to review its web traffic and analytics reports. This data is particularly valuable, as it will indicate the most common devices in your region and, more importantly, devices that are in use by existing customers.

If your existing analytics show very little mobile traffic, please review the type of detection method being used. Many analytics packages rely on client-side JavaScript to track visitors and to extract device information such as screen size. Devices with less capable browsers may not support the necessary level of JavaScript and may therefore not appear in the report.
An alternative is to use server-side detection, which extracts device data from the user agent string.

When possible, also review the individual platform versions accessing your site. Many users will never update their phone's operating system, or will simply not have the option to do so. Your analytics package should be able to provide some version data, and regularly updated platform version stats can also be found on the Android and BlackBerry developer sites. (Apple sadly does not release these statistics, but data released by native app analytics services such as Flurry can often provide an indication of platform version popularity).


Finally, you may have existing dependencies related to budget, in-house skills, or frameworks and toolkits that you specialize in.

While it's not always possible to develop a project using the exact technologies you prefer, these factors should be considered, as the ramp-up time required to learn new technologies will ultimately affect the cost of the developing the app.

Each variant of app behavior (for example, the difference between loading data through a full-page refresh instead of using Ajax) may require additional visual and interaction design, along with further front-end development and testing.


Understanding the benefits, risks, and potential return on investment are central to being successful when building apps for the mobile web. Balancing the needs of your users against the features available on the platform sometimes needs careful consideration.


(1) An exhaustive list of sites that contain this type of data can be found in A comprehensive guide to mobile statistics by Cloud Four in Portland.

Last built: June 5, 2012