Why Android Must Die - and Why Nokia Did It Right

Have you ever held an Android (or newer BlackBerry) phone in your hands and played with it? Have you ever experienced that sometimes, randomly, when you didn’t do anything out of the ordinary, the phone freezes for a variable amount of time? Nothing seems to be helping, you can punch keys and screen as much as you want, but the phone is dead. Then, miraculously, the phone springs back to life.

You’ve probably seen that. It’s one of the most annoying features of Java, the system that underpins Android (and BlackBerry apps), garbage collection. Essentially, your app uses the memory in chunks it gets in credit. After a while, the tax collector comes to visit, everybody has to stop what they are doing, and the tax collector decides what memory is not used any longer, frees it up, moves everything around to be in a smaller packet, and then leaves.

Apple apps don’t do that. They free their memory as soon as they don’t need it. That slows things down incrementally, but you never have that stupid freeze that blocks you out of your phone (well, only out of your app). Apple apps are written in Objective C, where memory is handled differently. Better, from the perspective of mobile apps.

But why did Android choose Java where Apple chose Objective C? And why does it mean that, as the title boldly states, Android Must Die? And what does Nokia have to do with any of this?

Why Android Is the Way It Is

[This following part is mostly speculation on my part, but the speculation is an educated guess and helps you understand that point of the article.]

Android consists of three main parts:

1. The OS core, which is a derivative of Linux
2. The specifications surrounding the hardware that is supported and the APIs required to access that hardware
3. Apps and the app development cycle

When the company Android Inc. was started, in 2003, smartphones were not on many people’s radar screen. Even when Google bought the company (in 2005) it was unclear where the market was going. The dominant force in smart devices was Palm, which had the Treo phone (with its PalmOS).

The choices made by Andy Rubin, the CEO of Android, Inc. made perfect sense. It all started with the core, an operating system derived from Linux. By 2003, Linux was by far the most ported operating system, which means that any hardware you threw at it, it would know how to handle. Even if some hardware was not available, the sheer amount of ports made it much easier to add a new platform or processor.

On top of the core, which was open and free for all to use, Android allowed programmers to write application in Java. The choice was probably driven by the Java sandbox and security restrictions: any Java application can be restricted in the things it is allowed to do (for instance, write to a file or take a picture). That seemed a very important feature. Additionally, Java was a known entity in the enterprise world, which was extremely important for smart phones. Back in the day, a huge chunk of the expenditure for expensive phones was driven by enterprises, and having something that appealed to the IT guys was going to be a much easier sell.

Another wise choice was to give great access to the hardware using a series of well-defined and sensible APIs. Android developers have a wide array of APIs for things like accelerometers, Internet connectivity, access to the camera, etc.

From the original choices, it is obvious what market Android Inc was targeting: expensive phones for enterprises that would do their own in-house development of apps. The hardware was going to be commoditized and open, so that different manufacturers could offer handsets to end customers.

Android vs. iPhone

Obviously, the market chosen and the market attained are completely different. Instead of selling expensive handsets by the hundreds of thousands to large enterprises, Android phones ended up fitting at a low price point in the consumer market, competing against the juggernaut Apple, which rakes in an astonishing amount of the profit available.

Apple chose a completely different path from Android. Its mobile operating system is a variant of its desktop OS, MacOS. iOS (for iPhone operating system) is a variant of BSD, which puts it in the same general category as Linux. Application development, though, is handled in Objective C. That is a choice that, with others, makes app development a completely different ballgame.

Instead of relying on application permissions like in Android, iPhone apps are vetted by Apple directly. That makes the process slightly error-prone (in case the testers at Apple don’t find malicious code in an app) and requires constant vigilance on the part of Apple.

Android, instead, is much more open. Apps are not vetted, and anyone can write an Android app and place it on the Google marketplace. Security is handled by sandboxing (isolating any app from all other apps) and permission handling (the user is asked to allow an app to perform certain tasks, like reading contacts or making outbound calls).

In addition, Apple controls the hardware on which iOS runs much more tightly than Google. The only manufacturer of iPhones and iDevices is Apple. The software is not licensed to others, and there are only a limited number of different devices available. That makes it easier for developers to deal with differences in screens and sensors but severely limits the choices available to consumers.

The Third Way

For a brief time, Nokia was trying to get into the smartphone market with a completely different type of product. It was, in essence, a desktop computer shrunk to the size of a phone, with phone functionality. The first device of this type they offered was the Nokia N900, of whom I am a proud owner. The software that ran on it was called Maemo.

The main difference between Nokia’s approach and Android’s was that a Nokia/Linux phone ran any software that ran on a desktop computer, as long as it was compiled for the phone.

That’s stupid, you’ll say. Who wants to use desktop software on a phone? I wouldn’t want that!

That is very true, and that was not the goal. The intent was to have all the tools available for developers. On the N900, you could write software in a variety of environments that included Java and Objective C (the tools used by Android and Apple), but also a variety of other tools, from the super-fast (C) to the super-easy to write (Python).

Development on the N900 happened in the same way as on an Android phone: Nokia gave you tools and interfaces, but you could use whatever tools you liked and interface with the ones provided whichever way you saw fit. In particular, companies could write software in fast-but-inscrutable C, while tinkerers could write slow but functional scripts in Python.

The Problem With Android

In many ways, Android feels like a compromise solution between iOS and Maemo. It is open like Maemo: anyone can download the operating system and look at it – in particular, handset manufacturers. Development occurs using standard tools available to anyone. Publishing apps to the two platforms is painless and easy.

Like iOS, though, Android doesn’t allow you to leverage strengths you already developed. All apps have to be written either in Java or as web applications, which means you are frequently required to re-invent the wheel. Also, you have to have a dedicated developer, since Android development skills do not cross over to virtually anything.

Java itself has several problems for app developers. For one, it suffers from the dreaded garbage collection problem, although that would be fixable. More importantly, though (and unlike in iOS apps), it’s really easy to reverse engineer apps, or to steal them outright.

You see, anyone can install an app to an Android phone. If you have a copy of an app, you can install it on your phone with no issue. You can’t do that on an iPhone, since all apps have to be downloaded from the app store. Predictably, this means that Android apps are pirated a lot, and that hence they cannot command the same price premium that iOS apps get. (That would be less of an issue if Android had its fair market share, but currently Apple is outranking Android.)

If Nokia Got It Right, Why Is It Doing So Poorly?

Nokia had two main problems with Maemo: quality and direction.

On the quality side, Maemo never really worked well. That was not a problem with Maemo itself, but with numerous bugs that never were addressed. My N900 was an amazing phone in hardware and software – but it was sometimes incredibly frustrating. It would not connect to certain WiFi networks, it would reboot in the middle of a call, it would lose data without recourse.

At the same time, I could teach it amazing new things. I taught it, for instance, how to connect to WiFi networks that required a web form automatically. I taught it how to automagically merge similar contacts to avoid duplicates. I taught it how to give me shopping lists based on where I was shopping. I taught it how to find the nearest restaurant or coffee place on a route I was taking.

Of course, I am a tinkerer and it’s easy to figure out these things for me. But you would benefit from my tinkering, too – once I make it available to you.

Problem is, Nokia never cared enough. Something inside the company, probably the rivalry between the Symbian people and the hardware people, made Maemo always underpowered. There were never enough resources to do the boring stuff, fixing bugs. Additionally, even when someone offered solutions to a problem, Nokia was slow in taking in the effort and improve.

In the end, Nokia decided that Linux was not ready for prime time (despite Android raking in big numbers) and ditched it virtually overnight. You can still buy a Nokia Linux phone – the N9.

Nokia decided that Windows Phone was going to be the way to go. If you ask me, that was a gigantic mistake, one that will cost the company its future and present. But that’s for shareholders to swallow, not for me and you.

Why Android Must Die

Android is a compromise where no compromise is needed. That’s a one sentence explanation of why Android must die.

Everything about Android is compromise:

• App development is restricted, but the restrictions buy no one any benefits.
• The operating system is open, but restrictions on app development negate the benefits coming from there
• Control over handsets is loose, which maximizes risks from malware and piracy and buys none of the benefits of finding a tinkerer that knows how to solve your problem
• The APIs are loose enough that all apps look different, confusing users – but you don’t have any of the benefits of low-level access in a variety of environments.
• Java’s security model is too coarse for real restrictions, but users get scared when an app asks for more permissions

And Now, the Final Chapter

What should a mobile operating system look like?

Apple’s approach has many merits, and one gargantuan flaw.

• It maximizes revenue for app developers by minimizing piracy, which entices more developers to join.
• it comforts consumers, who trust that the apps they download from the App Store are at the very least not dangerous
• It minimizes frustration for developers and consumers, who don’t have to worry about weird issues on off-beat (or mainstream) hardware

BUT, it also works only for one company that succeeds in grabbing a huge market share. Runners up cannot work on this model, because it is expensive to vet apps, because the runner app logically has fewer apps of lower quality, and because the development of apps for an off-beat environment is much more expensive than for something that can be leveraged otherwise.

Microsoft is slowly starting to figure it out with Windows for Phones. They bet their existence on a mobile operating system that tries to be Apple – from the price point (expensive!) to the approach to app installation (only from the Windows Store). That approach is doomed to fail: anyone buying a Windows Phone is forced to realize they bought full price for half the functionality.

My thinking is that if you can’t be Apple, try to be the anti-Apple. Open up your interfaces and marketplaces and allow people to install whatever they want on their phones. Leave it to the carriers and contracts to shut out phones that go haywire because of some software issue.

Deal with the variety of issues arising from different form factors and environments. You can easily outsource bug triage and bug fixing, and your customers will love you for the creative ways you allow them to use a phone. Watch phone? Check! Sunglasses phone? Check! Phone integrated into the car, or the TV? Check!

Create reference platforms (like Google’s Nexus line) and reference user interface styles that developers want to gravitate to. In the end, the reference will attract the hardware and software manufacturers, because it’s what people will want. But it’s going to be an organic process.

• Finally, abandon the security sandbox concept. The restrictions that come with the sandbox are not really meaningful, and you would be much better off dealing with security issues the old-fashioned way: trust. Provide a set of apps that are tested and trusted, and let people that love risk deal with it on their own.