Editor's Note (February 2023): There have been new developments with the launch of a new Unison™ app, from Intel®, unveiled at CES 2023. Read our coverage about the Intel Unison App.
Android maintains its position as the leading mobile operating system (OS) used worldwide—representing, in August 2022, a 70% share of the mobile operating system market compared to Apple’s iOS representing a 28% share. You’d think, then, that Android and the smartphone manufacturers who build their phones on top of the Android OS (e.g., Samsung, Google, Huawei, etc.) would control many factors of the smartphone industry.
However, as a recent iOS/Android texting debate highlights, Apple, and its iMessage platform, continues to prioritize its “walled garden,” closed ecosystem, rather than adopting the more universal texting protocol, rich communication services (RCS). And to the chagrin of many Android users on the receiving end of SMS texts sent by their friends and colleagues wielding iOS smartphones, it’s clear that Apple has made up its mind on RCS.
A lot of people still buy iPhones, certainly enough to make an impact on compatibility when texting between operating systems.
But beyond fixing texting, we have some questions.
What are some of the fundamental aspects that make a manufacturer choose a closed system over an open one (that is, what are the advantages and disadvantages of closed ecosystems and building a “walled garden” versus an open playground)? What’s more, why would a user choose a smartphone built on Android versus iOS? Finally, what are the major challenges that present when developing apps for Android versus iOS?
These are some of the questions I sought to answer when I recently sat down with Nick Rutherford, a Senior App Engineer specializing in the Android operating system, who works at Milwaukee® Tool on the ONE-KEY™ app.
In this article, I’ll share some of Nick’s insights into a phenomenon known as Android fragmentation, offering his perspective on the challenges unique to developing apps on the Android operating system, as well as discussing what makes Android stand out from iOS, and why you might consider one OS over the other (and what you can expect from each).
What’s Inside
What Is Fragmentation in Android? Mobile Device Fragmentation, Explained
Before we get into what it’s like for developers making apps on top of Android OS (and bearing to light the challenges app users may not know go on behind the scenes to make their apps work), we first need to form an understanding of what software fragmentation is.
So, what is device fragmentation, anyway?
Device Fragmentation Meaning
Software “fragmentation,” according to Headspin.io, can be described as the problems presenting as the result of a “diversity of browsers, devices, and platform versions in use at any given point in time.”
As the BrowserStack Blog has pointed out, over 4 billion people access the web through combinations of “9000+ distinct devices, shipped with 21 different operating systems (vendor + version, along with 8 major browser engines that power hundreds of browsers.”
The result of fragmentation can lead to many unique incident types that, when can combined, can lead to a perfect storm of end user problems that prove challenging for companies to troubleshoot, fix, and plan for preventing:
- OS version-specific errors and bugs
- Compatibility issues (between devices, browsers, applications, etc.)
- App versioning issues (when using apps)
- Browser-specific issues (bugs, versioning, etc.)
It’s worth noting, the above-mentioned Apple/Android texting example speaks to a specific topic within computer/software development known as interoperability, or the ability of software or systems to exchange and make use of information such that they’re able to work (operate) in conjunction with each other. Interoperability, Tech Target notes, deals with compatibility of “different systems, devices, and applications or products” to function “in a coordinated way, without effort from the end user.”
Mobile Device Fragmentation
Then, mobile device fragmentation, a subset of software fragmentation, specifically pertains to mobile devices and, as folio3 Mobile notes, “a process that happens when mobile users are using older versions of an operating system, while others are using newer versions.”
Mobile device fragmentation (which we’ll discuss later in this article) can prove uniquely challenging to app developers who must plan for and incorporate backward compatibility to ensure the experience of older OS (as well as app) versions is not disrupted when new software versions are introduced.
What Is Fragmentation in Android? Explaining Android OS Fragmentation and Why It Exists
As previously discussed in this publication, when Android was first developed by Rich Miner, Nick Sears, Chris White, and Andy Rubin in 2003, its founders made the conscious choice to use the Linux operating system for Android’s basis. This made it possible for third-party mobile manufacturers to build phones on top of the Android operating system.
In many ways, their decision is in the spirit of open-source software, the basic tenets of which favor open collaboration and public trust in the software.
And while open-source software provides many advantages, it has also launched unique challenges.
Chief among these challenges is Android OS fragmentation, a phenomenon that developers for the Android operating system (such as app developers) need to contend with in order to ensure their software products are compatible across many facets, including:
- Many manufacturers’ devices (and any potential hardware or firmware problems unique to each manufacturer).
- The version of Android these devices are running (which is not standardized industry-wide, while also in some cases users may not update their OS when prompted).
- App version, with some users not updating their app version when prompted.
Unlike iOS, where Apple is both the hardware developer of its smartphone as well as the software developer of the software that lives on those smartphones—and hence have more control over the codebase—software developers have much more to consider when building applications built on top of the Android OS.
“When Apple makes changes to iOS, it doesn’t usually tweak the whole library,” Senior Android Application Engineer Nick Rutherford notes. When changes are introduced to Android, he adds, “whole libraries can be updated.” There’s much more time spent in discovery, investigating potential issues that may impact development time, Rutherford tells me. “[The] scope of work will dramatically change depending on our findings.” Describing a vastly dissimilar development process that’s needed when developing Android-based applications, he explains what “usual” development looks like on iOS smartphones, a straightforward process: “You get a ticket, you work on the feature, it goes to QA.” By contrast, in Android, he says it starts first with “tackling and looking into the ticket. If they discover there’s a big problem, it could affect development time largely.”
Closed vs Open Ecosystems: What is Fragmentation in App Development?
So, now that we’ve established that Android fragmentation can be a problem, how do these problems affect Android app development? How are these challenges overcome? And why might the juice be worth the squeeze with developers (as well as the users of their products) who choose to develop open ecosystems over the more predictable, closed ecosystem?
When asked about what challenges developing for Android OS presents from a project standpoint, Senior Android Application Engineer Nick Rutherford narrowed it down to 3:
- Solving implementation challenges
- Making sure the user experience (UX) is consistent across all devices and OS versions
- Making sure you don’t introduce bugs for older versions
Different Interactions Can Create Implementation Challenges
One major hurdle Android development teams have to regularly tackle, Rutherford tells me, is dealing with specific types of features and implementation of a wide variety of smartphone manufacturers and OS versions.
As an example, he points out Bluetooth® interactions. For Milwaukee Tool, developing the One-Key tool tracking app, naturally certain user permissions are needed to be user-opted-in for full app functionality (namely, Bluetooth® and Location Services). Users saw major changes in Android 11 and 12 to how these need to be set up at the device-level.
“For things like Bluetooth functionality, different phones use Bluetooth libraries,” he explains. "We need to make sure we’re asking for the right permissions in order to get the correct response.”
He expounds within the context of a common user interaction, connecting to a One-Key compatible tool:
A User goes through and connects their device from a Bluetooth standard. [Unlike in iOS,] Bluetooth libraries are different. In the Android version, when a user is connecting, we may have to outsource a Bluetooth library. When a user goes and connects their device, they’ll see the same screen, but the UX is different and, depending on where they are, it may take longer to connect their device because Bluetooth libraries need to read different Bluetooth devices. The Bluetooth experience is a little different because there are a few more hoops to jump through, which may cause issues for some users.
Making Sure UI Is Consistent Across All Devices and OS Versions
Another major challenge tied to so many Android devices, Rutherford tells me, is making sure users have a consistent experience, no matter the device, Android version, or app version they’re running. “We have to make sure everything looks the same across phones,” he explains, adding, and “designs from UX [are] scalable across all the different phones, [including] low-hanging fruit smartphones [to the newest, most advanced smartphone]. We need to ensure phones with a super small phone screen can see the same experience as a more recent phone.”
Part of this challenge, which makes the work of Android engineers quite marvelous, is not only building functionality for everyone, but also optimizing the experience for all. Part of the job of an Android engineer, Rutherford explains, is finding answers to questions like, “How do we give users the best user interaction with the phone they have, based on what’s possible?”
Making Sure New Bugs Aren’t Created for Older Versions
Rutherford explains that older versions of the app can create new opportunities for bugs, which need to be investigated to “ensure we’re not creating new bugs or making the app crash [for end users with older versions of the app].”
“From a project standpoint, there’s a lot more investigation, and identifying risks introduced to codebase, because we have so many version types.”
He explains, while enterprise users whose IT departments use mobile device management (MDM) systems that can force a version update, for many individual users, they may choose to stay on an old version of the app indefinitely. “How do we lend a hand to those who haven’t upgraded? Solving bugs for them, not introducing crashes.”
The Key Takeaway for Android Users
Application development for Android engineers is a different process than the more straightforward process with iOS (the latter that enjoys the benefits of a more guarded, proprietary OS).
However, that’s not to say the juice isn’t worth the squeeze.
For Nick Rutherford, he likes open systems philosophically. He explains that, regardless of OS, app developers can’t get around the issue of having bugs entirely; bugs (and squashing them) will always be a part of developing software. And with that, he explains, “you need collaboration and in an open project/open ecosystem, the more collaboration, the better [the software].”
For end users, while there may be interactions that are unique to Android, as the largest operating system, there are also plenty more developers in the industry specifically adding contributions to improve the operating system—and from an app development standpoint, there are highly skilled teams of engineers meeting you at whichever level you’re at, and working to ensure there's backward compatibility (which is more than we can assuredly say of Apple from an ideological standpoint).
