Accidental Obsolescence

Years ago, I remember hearing the term 'planned obsolescence' being thrown around. The context was typically surrounding Apple and their upgrade cycle. The idea was that Apple would not support their devices for more than two years, forcing users to upgrade to continue to receive support.

If you look at the first few iOS devices, it could be easy to see that. The original iPhone receive its last software update, iPhone OS 3.1.3, in February 2010, just over two and a half years of availability. It didn't stand a chance of receiving iOS 4. In fact, if you look at the history of iOS releases in general, each has typically left behind some device or another.

Yet, despite older devices eventually having to fall by the wayside, something interesting began happening with the iPad 2.

In March 2011, Apple unveiled the iPad 2. It was thinner than the original iPad, included both a front and rear facing camera, and packed the Apple designed A5 chip. While not incredibly more powerful than iOS devices sold in the previous year, the iPad 2 currently holds an incredible distinction: it supported six iOS releases! Only now, five years after introduction, is Apple letting the A5-family go. It launched with iOS 4.3.5 and will end with iOS 9.3.5, the most current stable release of iOS.

iOS 9 stands as a unique iOS release: it is the only major iOS version to not drop support for a device. In other words, all iOS 8 capable devices were able to get iOS 9. Given these recent trends, it's likely that a good number of iOS devices, especially the 64-bit ones running the A7 chip or newer, will be supported by iOS releases for years to come.

That all said, I'm sure any iPad 2 owner can tell you: The device ran smoothest with iOS 4 and slowest with iOS 9. But given that each release adds new features of some kind, it's only an eventuality that hardware cannot keep up with the software running on it. But to support major OS releases for six years is quite a lot, at least in the mobile space. Apple, thankfully, has the advantage of controlling both the hardware and software that goes into their devices, allowing them to tweak and manage every aspect. Because of the limited hardware options, it's also easy for them to maintain support for older devices if need be.

Accidental (They didn't mean to)

By comparison, take a look at the recent news regarding Android devices running certain Qualcomm chipsets:

Not all of the big Android phone makers have announced their plans for the Nougat update [Android's latest OS release], but if you look at Sony’s and Google’s and HTC’s official lists (as well as the supplemental lists being published by some carriers), you’ll notice they all have one big thing in common. None of the phones are more than a year or two old.

After doing some digging and talking to some people, we can say that it will be either very difficult if not completely impossible for any phone that uses Qualcomm’s Snapdragon 800 or 801 to get an official, Google-sanctioned Nougat update (including the Z3). And that’s a pretty big deal, since those two chips powered practically every single Android flagship sold from late 2013 until late 2014 and a few more recent devices to boot.

This situation has far-reaching implications for the Android ecosystem. And while it can be tempting to lay the blame at the feet of any one company—Google for creating this update mess in the first place, Qualcomm for failing to support older chipsets, and the phone makers for failing to keep up with new software—it’s really kind of everybody’s fault.

While the Android ecosystem allows for a great amount of variety and customization, it also can lead to situations like this. In this case, it looks likely that Qualcomm themselves have decided to stop supporting that chipset. Given that Android updates require sign-offs from multiple parties, just one can provide a roadblock.

This sets off a vicious cycle—OEMs usually don’t update their phones for more than a year or two, so chipmakers don’t worry about supporting their chipsets for more than a year or two, so OEMs can’t update their phones for more than a year or two even if they want to. It turns the 18-month minimum target that Google has been silently pushing for the last half-decade into less of a “minimum” and more of a “best-case scenario.” And people who don’t buy brand-new phones the day they come out are even worse off, since most of these update timelines are driven by launch date and not by the date the phones were taken off the market.

This isn't the first time we've seen a premium or flagship handset losing support before the intended date. But for smartphone users, does the idea of an 18-month support window make you feel comfortable? I know I wouldn't like that.

Google's (soon to be rebranded) Nexus line might be the best supported for Android updates, but I wonder if Google will do more to tighten down the Android experience on their own devices. Will they move to take more control of the entire experience and limit situations like this? Can that even be done? One thing's for sure: I doubt Google intended for Nougat to be limited in release. Yet, through no direct fault of their own, this is the current situation.

iOS and Android encryption

One of the reasons Apple has been requested to build a backdoor into iOS is because the FBI can't access the data on a certain iPhone directly. To get into the encrypted device, they need the correct PIN. Then they'll be able to access the data they want.

By default, all devices running iOS 8 and above are encrypted. Whether it's your new iPhone 6s or your grandmother's iPad 2, if it has the OS installed, the content on it has been encrypted to some degree. The best way to see how many iOS devices are encrypted is thus by seeing how many are using those operating systems.

Directly from Apple, we can see the breakdown of iOS usage across all iOS devices. All iOS devices running iOS 8 and up are encrypted, thus leading to the conclusion that 94% of all iOS devices have encryption enabled. I would say 'by default', but Apple's control of the operating system and limitations to the user prevent someone from 'disabling' that encryption.

Android, meanwhile, can't boast those same numbers. In fact, it's a lot harder to make a proper estimate of how many Android devices are encrypted. CNN's Jose Pagliery:

Google introduced encryption on Android in 2011, but it was buried deep within a phone's settings. Not until late 2014 did Google begin asking customers if they wanted to encrypt their phones during the setup process.
Although 97% of Android phones have encryption as an option, less than 35% of them actually got prompted to turn it on when they first activated the phone. Even then, not everybody chooses that extra layer of security.

While the option has been there, most users simply don't enable device encryption. It was enabled by default with the Lollipop update. And while Android's next version, Marshmallow, requires encryption to be enabled, the number of devices currently running it is only 2.3%. And even then, such encryption is only enforced on "high-performing devices". With the plethora of Android devices available out there, it's likely that consumers are not always buying or owning such a device.

If the San Bernardino terrorists were using Android devices, we probably wouldn't have seen any government requests at all. Chances are the device would either be on an older OS version or simply not be encrypted at all. If this had been the case, this situation could've been a lot different than it has played out.