For a great primer on mobile testing, check out my previous post that gives four tips for optimizing phones and tablets. Also, feel free to register for our brand-new webinar, “Be Mobile-First,” in which I’ll be teaching how companies can enter the mobile space and ensure their offerings are performant and well designed for smartphones and tablets.
Figuring out which browsers your website should support is an exhausting task. But figuring out which devices your app should support? This can be even more stressful, given more people than ever use mobile to engage with brands.
If you’re waking up in the middle of the night with the phrase “mobile-first!” ringing in your ears, I’m here to help! In this post I’ll guide you through how to narrow down the list of devices your application should support. I’ll also explain how you can check to make sure your app works as intended on those devices, and how you can execute a support plan that leaves you armed and informed for the next marketing meeting, so you can convince the right people to go mobile.
The 3 App Support Levels
To understand what it means to support an application, we have to look at the three levels of support for applications: device type, device model, and operating system.
Device type addresses if your app will support smartphones, tablets, or both. Apps on iPads and Android tablets behave differently than they do on smartphones due to differences in screen size—but to adjust to these differences, apps should do more than just automatically shrink down or expand out. Ideally, they should capitalize on the unique dimensions of each device. This takes more work on the development side and will later require more support resources, but it also ensures your app always looks great.
Device model addresses if the app will support the iPhone 5, 6, or 6S, and/or the Samsung Galaxy S5 or S6. (It’s usually possible for it to support all of them; this, again, just takes more time and work.) The two main differences between device models are screen size and processing power, as these both change almost every device cycle. This change can cause apps to render differently from year to year.
Operating system concerns iOS8 vs. iOS 9, and Android 5.0 Lollipop vs. Android 6.0 Marshmallow. OS upgrades are often substantial, making new features available for app building to developers while depreciating other features. This can make some apps unusable on older operating systems, an issue often known as backward incompatibility.
It’s easy to get overwhelmed as you determine how your app should support each of these three levels—but don’t panic! Let’s explore now how you can use data to narrow down the possibilities for each level.
Start by running analytics on your app to benchmark each level’s market share. If your app is already published, whichever app store it’s in will offer a breakdown of the device types, models, and operating systems have downloaded it. With this information you can set a rule for support—for example, only focusing on those with at least 5% of the market share.
Run analytics to benchmark each level's market share. Then, you can set a rule for support—for example, only focusing on devices and OSes with at least 5% of the market share.
Next, more closely examine the OSes that are accessing your app. If most of them are newer, then you should feel confident that even if you enable your app to use the most up-to-date libraries and features, there will no major loss in user numbers. This will result in a slimmed down app that’s more efficient because it’s not bogged down by legacy code for older systems.
At this point you should be able to build a list of which device types, models, and OSes your app should support.
Now that you have the data to know which device types, models, and OSes to support, how do you procure all those devices to physically show how the app will work on them?
One answer is to buy them all! However, the more logical (and notably cheaper) route is emulation. Both XCode and Android Studio let you deploy an app on a device and operating system of your choosing at runtime, which can give you a good idea of how it will run on the real thing with the same specifications.
Use XCode and Android Studio to emulate how an app will behave on a device and operating system.
Keep in mind: Emulation is no replacement for actual hardware devices, as communicating with cell carriers and interacting with external features on users’ phones can be hard to replicate. So after you emulate to see how an app will probably run on a certain device, conduct a second round of testing on the most popular devices (e.g., an iPhone, iPad, and the latest Android phone) to make sure it definitely works well.
With this advice, you can start conversations about supporting devices with confidence that your decisions are backed up by a data-driven process. Remember—the goal is to keep your app running as leanly as possible and to give users the best experience you can, no matter their device type, model, or operating system.