The future of mobile OS interfaces

The quiet revolution nobody noticed

Nobody noticed Meego Harmattan. The initial hype around the new mobile OS died down quickly: a couple of devices that had already worn the fans’ nerves raw before Harmattan, the N900, which owners then kept for years as “the best phone with a keyboard,” the N950, which only developers got so they could stock the app store for the N9, the N9, which hardly anyone needed, Elop, the collapse of Nokia’s smartphone production — that whole churn of events meant nobody noticed the quiet revolution the engineers and designers had, by some miracle, managed to pull off.

The engineers showed how to squeeze near-studio recording quality out of a cheap codec and a properly designed enclosure — I say this because my N950 could record a rock concert from the front row with sound quality that made people clutch their heads and wail, “How on earth is that possible?” And also because I once spoke at a conference to a Nokia engineer who had worked on the N950’s enclosure.

And the designers accidentally killed the concept of business applications. Along the way they killed the notion of a “unique control set,” showing it would be the same for everyone and that in practice it doesn’t matter. That was a thousand years ago, and nobody noticed.

When it came to the control set, things were simple — the designers reconciled the polish of iOS with the practicality of Android concepts. Today it’s hard to point convincingly at the thousands of tiny coincidences; what matters is the feel of the interface that emerged back then — and back then, it seems, Android 4 had only just appeared. That flexibility made it clear that in future the core set of components would follow one and the same path, the simplest and most functional. The illusion of a possible unique path collapsed.

But more critical were the individual interface elements that all but removed the need for dozens of apps. Want to see new posts from Facebook or Twitter? There’s already a separate screen that shows them once you add the social account in settings. Need to send a message on one of them? The messenger can already do that.

There were no superapps yet, the kind that effectively proved an app can grow so large it’s easier not to build it around the OS but to build the OS around it. There was no WeChat, where a person gets birth and marriage certificates, buys an apartment and furniture, checks a child’s school grades, and then dies there too. But the shift in concept was already there, ahead of its time.

Apps aren’t needed

Not an app as unique as the flight of a butterfly, but a data source. Not an extra slice of interface that doesn’t yet exist in the system, but an extension of what’s there. Not a huge amount of effort spent maintaining several code bases, but a backend and — maybe — a bit of UI customization pushed down from that same backend.

Skeptics said it was impossible to reconcile Android and iOS into a universal control set, to say nothing of small marginal OSes like Windows Phone. In practice it was more than possible, even at the level of cross-platform frameworks, not to mention multiplatform (Kotlin Multiplatform). The same people said it was impossible to send app logic or a user interface down from a server — and they were wrong again. The era of A/B testing arrived, and the necessary mechanism had to be built.

Only the cost of maintaining and developing business apps hasn’t changed — it stayed high. The cost of building a “native” design for different platforms, the overhead of analytics, and other artificially created parts of a product’s final price. This Sisyphean labor is still going on. Two identical apps still cost substantially more than one.

The way out, paradoxical as it sounds, is to partly ban the unique parts of the OS. There’s no need for a hundred identical weather apps; there’s need for a widget with a couple of screens working with hundreds of sources, each feeding it whatever the next would-be Gismeteo sends. There’s no need for dozens of carbon-copy messengers; there’s need for another account in the system that hands over a source with conversations in the format the system needs, and exactly one app that is no longer an app but part of the system. Along the way, much became standardized and lost any uniqueness.

The lack of customization can easily be offset by subscriptions extending the capabilities of that same content source — need a heavily modified UI, pay up and get a little more. But no, nobody will let you put a hundred and fifty Send-type buttons in the window of the default messaging app. One is enough.

Legacy

It gets more interesting once you see that how we handle data and content today is like a trilobite in a gypsum quarry. What you want is the trilobite, but what you see is a wall of gypsum quarry, or at best a rock that at first glance has nothing to do with trilobites. You take a hammer, strike some email backend, and inside there’s either an embryonic Telegram, or a wiki for a project, or a push for an ad blast.

In plain human terms, email is essentially indistinguishable from a messenger. Send a message, receive a message — not instantly, but God knows when. And not only is it still working — we’ve made this ancient information-exchange system ineradicable by giving it legal status. At first it was funny — an email as a document or evidence in court. Now it’s routine.

Why do we need a bug tracker if it just repeats a messenger? Or an email thread rendered slightly differently? Why a wiki into which information is duplicated from the tracker (if we’re lucky), from discussions at meetings (if we’re lucky), from messengers (if we’re very lucky)? Why duplicate the same information across dozens of representations, by hand? Out of inertia nobody stops to think, and everyone keeps “doing as they’ve always done.”

As an analogy for mobile devices: dozens of note-taking apps, document-syncing apps, snippets of content in messengers saved as separate posts, email, required everywhere and always because that’s what we’re used to. All of this has long needed a unified storage and, at worst, several representations.

The same goes for cookie-cutter apps of banks, maps, smart homes, app stores. There are hundreds of categories that essentially share one representation. It can easily be built contextually into the OS from the start, requiring providers of those same maps to supply nothing but a data source.

What about the unique flight of the butterfly?

It isn’t needed. Give the user the ability to apply a skin they like better, change the phone’s color. That’s enough for most. The minority’s interests just need to be taken into account and, again, built into the OS.

Is a mobile OS even needed as a standalone entity?

In pure form — not really. On the processor of a mid-range Samsung you can already comfortably run IntelliJ IDEA in a Linux subsystem. I worked in Samsung Dex for years, and for the vast majority of an average laptop’s tasks, a phone and a monitor were enough. The mobile form factor as a standalone entity has effectively outlived itself. You don’t need a laptop, you don’t need a separate phone. You need a phone with a dock in the form of an average laptop. Given that the future of IDEs (development environments, or whatever replaces them) lies in moving all the heavy work to the backend with the lightest possible front end, a powerful laptop remains genuinely necessary only in a small number of industries, where it makes sense not so much as “a laptop you can carry” as “a desktop you can haul around.”

In that sense, all the “mobility” of such an OS is a trimmed-down representation of the desktop and nothing more.

Summary

Part of the OS with data sources instead of apps, universal access to data instead of dozens of outdated representations, and a mobile OS as one of the desktop’s representations — that’s the way. But to choose that path you need to create, not copy — and that’s in short supply right now.