The 4 Big Differences Between Mobile and Web: #1 Device Fragmentation

In our previous post, we introduced the four differences between mobile web (device fragmentation, resource availability, business model and user experience). In this post, we’ll cover the concept of platform fragmentation.

Device Fragmentation

Even in a browser world, supporting the same app across multiple browsers can be an adventure. Chrome, Firefox, Internet Explorer and Safari all have slightly different configurations. However, at the very least, there’s some “homogeneous-ish” installed base of PCs running Windows and Macs running Mac OS, likely with an Intel chipset, and HTML5, CSS and JavaScript as the common foundation for the browser.

As a result, a web app runs on pretty much any chipset / device / OS / browser combination without any problems.

Compare that to mobile — where phones and tablets come in a variety of different shapes and sizes, screen resolutions, chipsets and OS versions. Even within iOS, the arguably most homogeneous ecosystem (in relative terms), there are many different types and generations of devices (iPod touch, iPhone, iPad, Apple Watch, and now also Apple TV), running who-knows-what-version of iOS on one of Apple’s Ax family of chipsets. And then device fragmentation for Android has been a well known fact for a long time: multiple OEMs, multiple SemiCos, multiple OS versions, etc., etc… In short, for mobile, there is fragmentation both within and across ecosystems.

Fragmentation matters and impacts development decisions. In our definition in Part 1 of this series we said that mobile apps need to be written for a specific platform and the ones that matter most are iOS, Android and Windows (let’s call them “the three platforms”). Three challenges arise from supporting multiple platforms:

• Different code bases: If the goal is to reach a wide audience, a developer needs to maintain three different code bases to run natively on all three platforms.
• Incompatible code bases: What works for one specific version “x” for an operating system doesn’t necessarily work for version “(x+1)”. For example, Apple deprecated some classes with iOS 9 (e.g. UIWebView, NSURLConnection), requiring developers to alter their code to have their apps run on iOS 9.
• Bloated code bases: While upgrading the code base to an “(x=1)” version, the app still needs to run on the “x” version. Hence, to address all market-relevant device / OS combinations for a platform, the application binary starts to get bigger and bigger, taking up space on a device and also requiring longer over-the-air download times, potentially impacting a user’s data plan. In fact, Apple increased the size limit of an app package submitted through iTunes Connect from 2 GB to 4 GB in February 2015. Apple then also introduced the concept of “App Thinning” with iOS 9, allowing developers to “optimize the installation of iOS and watchOS apps by tailoring app delivery to the capabilities of the user’s particular device, with minimal footprint.”

In summary, mobile is different from web because it requires development and ongoing management of one code base per supported native platform. And for any app to be relevant and reach a wider audience, it needs to support at least iOS and Android, which according to IDC had a combined market share of over 90% of smartphone shipments in Q2 2015.

The counter argument in favor of a web app then is that there’s only a single code base required, which scales across all platforms. And so why not simply use a web app then? That’s where the next difference kicks in, which we’ll cover in the part III of V: Resource availability, which covers the unique characteristics of mobile device, and how they impact app development.

Originally published at www.crittercism.com on October 7, 2015.