The Definitive Resolution to the iPhone versus Android Debate
A Brief History of Smartphones
The iPhone first went on sale on 29 June 2007 in the United States. Though smartphones and touch devices have existed for a while, the iPhone was what really brought the definition today of a “smartphone” - a small, though growing in size, rectangular device with a touchscreen on it
- into the mainstream. According to the press release: “iPhone ushers in an era of software power and sophistication never before seen in a mobile device, which completely redefines what users can do on their mobile phones.” A few months later, on 9 September 2007, Apple announced the sale of its millionth iPhone:
“One million iPhones in 74 days—it took almost two years to achieve this milestone with iPod,” said Steve Jobs, Apple’s CEO. “We can’t wait to get this revolutionary product into the hands of even more customers this holiday season.”
The first commercial Android phone came out a year later, though development for the operating system, built on top of the open source Linux kernel, began in 2003: according to Wikipedia, “The first commercially available smartphone running Android was the HTC Dream, released on October 22, 2008.” Fostered by the Open Handset Alliance composed of, at the time, 34 large corporations including Google, Intel, and Qualcomm that collectively developed Android “under one of the most progressive, developer-friendly open-source licenses,” the Android market slowly grew in size before overtaking that of the iPhone sometime in 2010.
That brings us to where we are today, where, according to Business Insider, Android occupied about 80% of the smartphone market as of 2014. As has been the case with the majority of large open source projects, the choice of choosing an open-source license that allows anyone to see, edit, and contribute to the project greatly accelerated the development and distribution of Android, contributing to its current position in the smartphone market today, where it sits above all proprietary alternatives. Apple has preferred a mixed model for iOS instead, incorporating some open source projects that it fosters but leaving much of iOS closed off, resulting in a very consistent user experience that is distinctly Apple: clean and slightly sophisticated.
By developing iOS as a mostly closed source project, Apple maintained total control over iOS, allowing it to control every aspect of the project but stunting its development a bit. Meanwhile, Android is the result of collaboration between tons of different organizations with different goals. The consequence of having the project be open source also results in large inconsistencies between different Androids - say, an HTC One M8 versus a Nexus One or a Samsung Galaxy - that makes it a little difficult to generalize about Android.
Differences at a Glance
In general, the biggest difference between owning an iPhone and owning an Android is who is in charge of your device. While you may have bought a smartphone, you may not truly own it in the sense that you can’t change many aspects of it at will without explicit permission from the company that manufactured it. iPhone users should be familiar with this: in the world of iPhones, Apple is the final say in everything unless you have the tools to circumvent their grip. Apple decides what you install on your phone, what most of it looks like, how it functions, and where you go to get help if there’s a problem or something you don’t like. They even decide what you can keep on your phone: unlike Androids, iPhones do not expose their filesystem to the user; what this means is that you can’t organize or download miscellaneous files like PDFs on iPhones.
This is in contrast to the world of Androids, where much more is up to the user. Want an app that isn’t in the Play Store? No problem: find a .apk file on the Internet, and you can install it if you’ve switched on the “unknown sources” option in your settings menu. Don’t like your home screen? It’s easy to find an app that replaces it. The same thing goes for the icons, fonts, and other user interface elements. Don’t like your messaging app? Replace that too. Replace all (or most) of the apps you don’t like. You can replace the majority of an Android’s user land with things that better suit your preferences, and you can even replace your phone’s default Android itself if you’re feeling ambitious. Back to the filesystem problem: connecting an Android to a computer allows you to easily add files to it, and you can even move these files from within the device itself if you have a file manager app, and you can download files directly from your mobile browser. This freedom and sense of openness is something that is distinctly missing from iPhones.
So what does being “open” really mean? It depends on the context.
An Open Ecosystem
The most immediately relevant definition is the more free experience of using an Android compared to an iPhone. Google doesn’t really care if you want to install an app it doesn’t approve of or replace most of the apps that it gave you by default, and neither does the manufacturer of your specific phone. With this freedom comes responsibility, though: because you can do things that Google doesn’t explicitly approve of, there is a risk of accidentally doing some harm to your phone by installing a malicious app, something that Apple would never let you do to your phone. Because of this, iOS can sort of be seen like a walled garden, where everything is pretty but restricted and safe, which is something that can be seen as preferable to Android’s open platform - the world of iOS follows the doctrine of Apple-knows-best, and thankfully, Apple usually does know what’s good for you. What’s best for you could be different though.
A prime example of this is the differences between the App Store Review Guidelines and Google Play Developer Program Policies. Immediately, the stricter nature of the App Store guidelines becomes apparent:
"[Your app must] do something useful, unique or provide some form of lasting entertainment… If your App looks like it was cobbled together in a few days, or you're trying to get your first practice App into the store to impress your friends, please brace yourself for rejection… If it sounds like we're control freaks, well, maybe it's because we're so committed to our users and making sure they have a quality experience with our products. Just like almost all of you are, too."
The App Store guidelines contain many restrictions that seem mostly subjective and may be completely unnecessary, including tons of functional limitations and many entirely stylistic choices: “If your user interface is complex or less than very good, it may be rejected.” The Google Play guidelines instead prefer the a more lax approach, following the doctrine of openness that made the platform possible in the first place. The result of this is that the App Store looks a lot more polished, but that the sum of its apps provide only a fraction of the functionality of that of apps on the Play Store. A prime example is that Firefox for Android has native support for extensions like AdBlock, NoScript, and HTTPSEverywhere, while Firefox for iOS can’t even use its own layout engine because of the terms of the App Store that require it to use WebKit from Safari.
Of course, you could circumvent all of this by jailbreaking your iPhone, but not only is that unsupported by Apple (meanwhile, rooting Android is explicitly supported by some phone manufacturers): the device, in comparison to a rooted Android, is still a bit limited in functionality. For one, a jailbroken iPhone will remain with the default iOS no matter what you do to it. For Androids: if you don’t like the Android your phone came with (more details on this later), you can replace it with The Official Android, a modified Android with extra features like CyanogenMod, or even an entirely different operating system like Ubuntu Touch or SailfishOS. The most you can do on a jailbroken iPhone is add some unsupported apps, something Android can already do without any modifications; with a rooted Android, you can go as far as changing or removing Android itself if you want to.
Open Source
The second meaning of open is the literal opening of the source code. Android is an open source project, meaning that all of its source code - the lines and lines of code that make Android work - are available to the public for anyone to see. This is in contrast to iOS’s mostly closed source nature, which doesn’t let anyone see the code. This is a big part of why only Apple products run iOS, while the products of several different companies run Android.
This has many implications, one of which being the fact that, because everyone can see the code, everyone can make changes to it and contribute those changes back to Android and/or build their own, modified versions of Android. This is why Android on a Nexus feels different from Android on an HTC One, and why it’s a little difficult to make general statements about Android. It’s not just different home screens and lock screens: the internals are a little different, too. Google Android is not HTC Android, though they are extremely similar and their differences are actually fairly small. The Android Open Source Project is the only pure Android, and from it, several customized versions of Android are created and shipped on different phones or distributed across the Internet. iOS doesn’t work like this: there’s only one iOS, developed by Apple. This makes for a more consistent experience across all iPhones, which is something that Apple fans appreciate.
The benefit of having a project be open source, though, is that the number of developers working on a project increases far beyond the scope of the original development team. Google isn’t the only one behind Android: HTC, Samsung, Intel, Qualcomm, Sony, and other large corporations as well as a global community of volunteers all contribute to the development of Android. Meanwhile, Apple alone develops iOS. Apple does steward several open source projects that it incorporates into iOS, but the code that makes up the core functionality of iOS is kept secret. A benefit of this is that it’s harder to see where there are bugs and exploit them, but the corollary to that is that it’s harder to find and fix them yourself; it’s a lot easier to squish bugs if the entire world is able to help than if you’re just doing it on your own.
An Empirical Comparison
Being open is nice and all, but how well do the two classes of phones perform? A study was conducted using the phones of the students at PVMHS in order to determine what phone was, computationally, the fastest, by measuring how fast phones’ browsers could solve math problems or manipulate sequences of characters. Participants were selected via a convenience sample and then voluntarily visited a website to test their phones and submit the resulting data. The study found that, on average, iPhones appear to be faster than Androids, but this difference is negligible for light usage like browsing the Internet or scrolling through Twitter, becoming more and more apparent as usage grows heavier, as is the case with things like fancy games or other computationally intense applications.
Motivation: Often, the most common method that people use to compare smartphones’ performances casually is to attempt to do something similar on either phones, timing the phones or racing them side-by-side to see which one can complete the task earlier. However, this is problematic, as it introduces too many sources of error: what if one phone has a temporary lag? What if someone has faster fingers or a faster reaction time? What if they fumble? What if one phone doesn’t even have the right app to begin with? Alternatively, one could point to the specification sheet of a phone, comparing clock speeds or whatnot. However, problems arise from this too, as these are simply manufacturer-issued numbers and may not say much about how a phone actually performs in day-to-day usage.
Obviously, a cleaner, more consistent way to compare smartphone performance is needed. Arguably the most common and simple one is through use of a benchmark. From Wikipedia:
"In computing, a benchmark is the act of running a computer program, a set of programs, or other operations, in order to assess the relative performance of an object, normally by running a number of standard tests and trials against it."
So, it was decided that a benchmark would be used. The only problem was choosing an implementation: the Apple App Store’s app requirements are relatively stringent, as was pointed out earlier, and, though apps can be side loaded onto phones without going through their respective app stores’ quality reviews, this would likely result in lower participation in the study as extra work on the participant side is needed to allow this to happen. Ideally, the majority of the process should be automated so that participants don’t have to do much.
With that limitation in mind, it was decided that the benchmark would be done through a web browser, as some of the same web browsers are available on all smartphones and it is presumed that their very experienced developers wrote them to maximize performance in order to maintain or grow market share, therefore making their performance representative of the performance of the platform they reside on. This would allow all smartphones to participate in the study and provide relatively representative metrics that could be used in comparisons.
Setup: The benchmarking part of the benchmark suite was a small piece of JavaScript code which ran a variety of tests that will be discussed later. All of the necessary resources are preloaded before the test begins in order to ignore differences in Internet speeds. Server-side, pages were served using Lighttpd 1.4.36 in a Docker container on a laptop running Linux 4.2.5 that faithfully remained running for the duration of the study (9 days). Graphs were generated with an R script that was generated by a shell script that scanned response data to pick appropriate graph parameters.
Participants were chosen from a convenience sample and were given a link and QR code that pointed to a redirect to the website that was running the study; from there, participants voluntarily navigated to the website and opted to take part in the study. It was determined that this would not affect the results much, as phones are mass-produced by factory specs and performance should not vary much between owners; an iPhone 5 in Massachusetts should yield the same results as one in Djibouti or the Principality of Sealand, but it’s possible that this could have introduced some kind of error somewhere.
Phone profiles: In total, 36 responses were received. All operating system and phone model information was either reported by the user-agent string or was self-reported by participants. Of these responses, 8 were Androids and 17 were iPhones; the rest were data submitted by people using desktops, laptops, or other non-smartphone devices and was excluded from the study.
The following table shows the distribution of operating systems:
The following table shows the distribution of phone models, if any could be determined:
Benchmark results: A total of 4 benchmarks were run on each phone, consisting of 10 trials each. This meant 40 trials for each individual phone, resulting in a total data set of 1000 trials, with 250 trials for each individual benchmark.
This benchmark measured how fast a phone could evaluate regular expressions, a method of matching patterns (a bit like a search query) to strings (a sequence of letters, numbers, etc.). A single trial consisted of 75 separate, single-character patterns matched against a 371 character string, repeated 16 times. iOS was slightly faster than Android, boasting a median time of 13 milliseconds compared to Android’s median time of 21 milliseconds.
This benchmark measured how fast a phone could encrypt and decrypt a string, using the Stanford JavaScript Crypto Library (SJCL). Encryption is the act of obscuring a message from viewing by external parties (think the National Security Agency or bad actors on the Internet), and decryption is the act of retrieving the original message back from the obscured one. A single trial consisted of a single encryption of a 371 character string and a subsequent decryption of the encrypted data, repeated 32 times. A larger string was initially used, but this was changed in favor of a smaller string and more loops after it was discovered that the version with the large string would not run on some iOS devices. In this benchmark, iOS was again faster with a median time of 41 milliseconds compared to Android’s median time of 102.5 milliseconds.
Of all of the benchmarks, this was the one that was most relevant to daily phone usage, as it utilizes a large quantity of both string and math operations in addition to other kinds of operations like table manipulations that are closer to the structure of an actual application. The SJCL is available on GitHub.
This benchmark measured how fast a phone could repeatedly add 1 to a value until the value reached 10 million (well, to be accurate, 10 million minus one). A single trial consisted of as many times it was needed to add 1 to a value until it reached 10 million. It’s not clear from the picture, but Android was the winner here: Android phones had a median time of 56 milliseconds, while iOS phones had a median time of 61.5 milliseconds. Admittedly, though, this benchmark is the farthest one from what would usually happen in day-to-day phone usage, so this victory may not mean much.
This benchmark measured how fast a phone could solve the factorial of 2048, using the math.js library to achieve high-precision numbers. A single trial ended when the phone was able to compute 2048!. Again, iOS won with a median time of 182.5 milliseconds compared to Android’s median time of 268.5 milliseconds. math.js, like SJCL, is available on GitHub.
Caveats: As stated earlier, these benchmarks were done in web browsers. Web browser developers are excellent programmers, so they’ve likely maximized how fast their programs are, but running benchmarks through a web browser will always be slower than running benchmarks through native programs; a benchmark in the web browser first needs to go through that web browser’s JavaScript engine, and this results in slower, less accurate computations that depend on the performance of the engine. Additionally, the study used a convenience sample, did not control for background apps, which may have influenced the results, and it tested a very small range of operations - things like graphics rendering were excluded.
Verdict: According to this study, the average iPhone appears to be faster than the average Android. The differences, being in milliseconds, may be small, but how big of a difference a few milliseconds means in real life depends on the scenario. When browsing the internet or using simple apps, the difference should be imperceptible, but if you’re doing big calculations, playing a fancy game, or something else that relies on lots of computation power and makes your phone feel warmer in your hand, things may run faster or smoother on iPhones.
Replication: The source code for the entire project is available on GitHub with instructions available in the README if you would like to replicate or modify this study. If you’d like to do your own analysis of the data: the data obtained from this study is available on Google Drive as two separate .csv files - byTrial.csv has each individual trial on a separate line, and raw.csv has each set of trials for each phone on each particular benchmark on a separate line. The raw response data obtained during the run of the study cannot be provided due to privacy concerns. The delimiter in both .csv files is the vertical bar character (|).
Conclusion
Taking all of that into consideration: if you’re just browsing the Internet or looking through Twitter, it doesn’t really matter which smartphone you choose. Androids and iPhones perform similarly enough that for light use cases, the differences are imperceptible. For more computationally intense tasks, though, iPhones fare better, though the benefit of this is questionable because your computationally intense apps that aren’t games likely won’t be available for iPhones in the first place.
For tinkerers, customizers, and people who like controlling most aspects of their user experience: the clear winner here is Android, which literally allows you to change any part of it if you have the resources to do so. People who need unconventional apps may also want to get an Android, as Apple’s App Store guidelines prevent apps with special use cases from entering the App Store. Additionally, if you plan on using your phone like a laptop by storing files on it like PDF files that you can access when on the go, you may want to get an Android, as iPhones don’t allow you to interact with their filesystem.
If you like walled gardens: iOS is the phone operating system for you. If you like to be a bit adventurous: Android is probably the right choice.