Systems

Why Does a Phone Still Have to Be Android or iOS?

For more than a decade, pocket computing has had two real options. Most people think the battle is over. This post looks at why it feels that way, and at the loop that keeps new platforms from starting.

· Updated · 6 min read

Why Does a Phone Still Have to Be Android or iOS?

On Tuesday I wrote about the layers that sit around a phone operating system: stores, payments, developer tools, our data and our habits. This post asks a narrower question, the one that has been sitting with me since.

Why does a phone still have to be Android or iOS?

It sounds almost silly to ask. Phones are Android or iOS the way cars have four wheels. But that is exactly why I want to ask it. When something feels this settled, it is worth checking how it got settled and what keeps it there.

Why the battle feels over

For well over a decade, two operating systems have carried nearly all of pocket computing. Other attempts came and went. Most people I talk to treat this as finished history, like a sports final that ended years ago.

I understand why. The two platforms are good. They are mature, polished and updated every year. They also look nothing alike underneath: one is largely open source and runs on phones from many manufacturers, the other is closed and runs only on one company's hardware. Two very different models both won, and almost everything else lost. That makes the outcome feel less like an accident and more like a law of nature.

But "it feels over" is a feeling, not an argument. So let me try to take it apart.

Hardware and software grew up together

A modern phone OS is not written for some generic computer. It is tuned for specific chips, cameras, radios, batteries and screens, often over many years.

Apple is the clearest case. It designs its own chips, the Apple silicon family, and the software is built alongside them. Battery life, camera processing and on-device machine learning all depend on that tight fit. On the Android side, the same thing happens in a more spread-out way: chipmakers, phone makers and Google work on drivers, firmware and OS releases together, across a huge range of devices.

For a newcomer, this is a wall that is easy to underestimate. Writing a kernel and a nice interface is hard but possible. Getting a camera pipeline that matches what people now expect, or standby battery life that holds up for days, requires deep work with hardware partners. Those partners already have full schedules with the two platforms that pay their bills.

So a new OS does not only compete with software. It competes with years of joint engineering between software and silicon.

App gravity

Then there is what I think of as app gravity. Each platform has a huge catalogue of native apps, and that catalogue pulls everything toward it. Users go where the apps are. New apps launch where the users are. Every year the pull gets a little stronger.

The important part is that people do not use "apps" in general. They use specific ones. Their bank. The messaging app their family uses. The app for their office, their gym, their train ticket. If one of those is missing, the phone feels broken, no matter how good the rest of it is.

That turns the question around. A new platform does not need a lot of apps. It needs almost all of the specific apps each person depends on, at the same time, on day one.

The cold-start trap

This is where it gets stuck. Economists call platforms like these two-sided markets: they bring together two groups, here users and developers, and each group's value depends on the size of the other.

When a platform is big, that works in its favour. When a platform is new, it works the other way, and you get a loop:

  1. No users means developers have no reason to build for it.
  2. No developers means there are no apps.
  3. No apps means users have no reason to buy the phone.

And then you are back at the start. Each step is a reasonable decision by someone. A developer with a small team cannot justify a third codebase for a tiny audience. A buyer will not spend money on a phone that cannot run their bank's app. Nobody is being foolish. The loop is made of sensible choices.

What the loop looked like in practice

History has a few clear examples, and none of them were weak efforts.

Windows Phone. Microsoft launched it in 2010 with real money and serious partners behind it, and the platform ran until support for Windows 10 Mobile ended in January 2020. The software itself got a lot of praise for its design. Still, a common complaint through those years was the missing apps people used elsewhere.

BlackBerry 10. BlackBerry came from a strong position, with a loyal base and well-known hardware. BlackBerry 10 even included a runtime that could run many Android apps, which was a direct attempt to break the loop by borrowing another platform's catalogue. Its legacy services were switched off on January 4, 2022.

Firefox OS. Mozilla took a different route. It built a phone OS on web technologies, hoping web developers could make apps without learning a new native stack. Mozilla stopped developing it for smartphones in 2016. The code lived on, though, because it was forked into KaiOS, which found a home on simpler feature phones.

Each of these tried a different way to escape the loop. One spent heavily and recruited developers, one tried to borrow apps from a rival, and one tried to make the web the app platform. None of them became a third major smartphone platform.

Why the usual fixes fall short

The BlackBerry case teaches me something specific. A compatibility layer sounds like a shortcut, but it has a cost. If your phone mostly runs another platform's apps, developers have even less reason to build native ones for you. You end up with apps that feel second-hand. Users notice that too.

The web approach has a softer version of the same problem. Web apps help, but the apps people depend on most are often native, and they rely on platform features that a new OS has to match one by one.

And money alone does not solve it either. You can pay some developers to build apps. You cannot pay every bank, every transit company and every small business at once.

So is it actually over?

Here is where I try to be honest with myself. Everything above explains why the duopoly persists. It does not prove that it has to.

The cold-start trap is real, but it describes a specific kind of attempt: a new OS that enters the same market, on the same kind of device, and asks the same users and developers to switch. All three examples above fit that pattern quite closely. That might tell us how hard the problem is. Or it might only tell us how hard that one approach is.

I don't know which, and I don't want to pretend I do.

Conclusion

The two platforms persist for reasons that make sense. They were built together with the hardware, they hold the apps people rely on, and any newcomer starts inside a loop where every sensible choice points back to them. Capable teams with serious resources have run into that loop and stopped.

That is why most people think the battle is over. Maybe they are right.

But a strong explanation for why something is the way it is does not, on its own, tell us whether it has to stay that way. So I am leaving the question open, as it is:

Why does a phone still have to be Android or iOS?

References

← Back to writing