Ambient, voice, and spatial computing are demoting the screen from default to fallback. How I design zero screen first Flutter apps for the post rectangle era.
Count the rectangles within arm's reach. I just did it at my desk in Dubai and got five before I stopped bothering: phone, laptop, watch, a second monitor, a tablet somewhere with 3% battery. Every one is a glowing pane of glass that has hired my eyes and hands as full-time employees. We've normalized this so completely that "using a computer" and "staring at a screen" have become the same sentence. They were never supposed to be.
Here's the bet I'm making, and I'll defend it below: over the next ten years the screen loses its status as the default computing surface. It doesn't die. It becomes a fallback — the thing you reach for when the ambient, voice, and spatial layers can't do the job. That's a demotion, and demotions reorder everything downstream: how we design interfaces, what we build, and which of our current assumptions age badly. I build Flutter apps for a living, so this is partly me thinking out loud about the ground shifting under my own feet.
We didn't choose the screen because it's the ideal way for humans to interact with machines. We chose it because it was the cheapest, most general-purpose output device we could mass-produce. A screen can pretend to be anything: a document, a dial, a map, a face. That flexibility is exactly why the graphical user interface won, and it's also why it's mediocre at nearly everything specific.
Think about what a screen actually demands from you:
For decades we papered over this with better pixels, higher refresh rates, and faster taps. But the core deal of screen-based computing never changed: to compute, you stop what you're doing and enter the machine's world. Ambient, voice, and spatial computing invert that deal. The machine enters your world instead. Once that inversion actually works — and I'll argue it's finally starting to — the screen stops being the front door and becomes the emergency exit.
If you want a single mental model for this whole post, that's it: the machine coming to you, instead of you going to the machine. Every trend below is a variation on that one theme.
The clearest signal that the screen is being demoted is that the best interactions increasingly have no screen at all. You walk into a room and the lights are already right. Your alarm is quiet because your calendar knows you have no morning meeting. The house tells you the front door's been unlocked for an hour, unprompted, because that's unusual.
None of that involves looking at anything. The interface is the environment — light, sound, temperature, a subtle notification chime with a specific meaning. This is ambient computing: the computer dissolved into the room and acting on your behalf without asking for your gaze. It's the logical endpoint of ubiquitous computing, the idea Mark Weiser sketched decades ago about technology that recedes into the background of daily life.
The reason this is only landing now isn't hardware. Cheap sensors, microphones, and speakers have existed for years. What was missing was a system that could hold enough context to act correctly without a screen to fall back on. A screen forgives ambiguity — it just shows you options and lets you pick. Ambient systems can't do that. They have to be right, or right enough, because the cost of interrupting you is high and the bandwidth to correct them is low.
That's the hard part, and it's a data-modeling problem more than a UI problem. To skip the screen, the system needs a model of your state that's good enough to act on: presence, routine, preference, the difference between "unusual" and "wrong." I spend most of my week modeling exactly this kind of state, and the honest truth is most systems today aren't good enough yet.
I learned this the expensive way. On an early version of a product at Shpper we tried to make one notification "smart" — suppress it when we were confident the user didn't need it. Sounds trivial. It was six weeks of pain. The moment you remove the screen and the list of options, every gap in your data model turns into a wrong action instead of a slightly awkward layout. A missing timezone field is a cosmetic bug on a screen; in an ambient flow it's a 3 a.m. alert. We shipped it, then quietly added a "why did I get this?" tap-through, because even our own team didn't trust the thing until it could explain itself.
That tap-through is the tell: the ambient future still leans on a screen as its conscience. The trajectory is clear and the payoff — computing that costs you zero attention — is real. The engineering bill to get there is just larger than the demos suggest. If you're building in this space, budget for the state model, not the sensors.
Voice interfaces have been "the future" for fifteen years and mostly a punchline for fourteen of them. "Set a timer" worked. Anything past that fell off a cliff. I turned the assistants off on every device I owned, and I know I wasn't alone.
Here's what changed, and it's the crux of this whole shift: voice didn't fail because of the microphone. It failed because of the model behind it. The mic was always fine. Speech-to-text was mostly fine. The problem was that old voice systems matched your transcribed words against a rigid grammar of predefined intents. Say it slightly wrong, add a subordinate clause, refer to something from two sentences ago, and it broke. It wasn't understanding you; it was pattern-matching against a menu you couldn't see.
Large language models quietly deleted that entire failure mode. Now the thing on the other end can hold context across turns, handle "no wait, the other one," ask a clarifying question when it's genuinely unsure, and map messy natural language onto real actions and tool calls. Voice went from "a command line you have to memorize" to "an actual conversation." That's not an incremental improvement. That's the difference between a feature people disable and an interface people trust.
Once a voice interface is trustworthy, a huge category of tasks never needs a screen:
The screen only comes back when the answer is inherently visual: a map, a chart, a photo, a document you need to scan. Which is exactly the point. The screen becomes the thing voice escalates to, not the default you start from.
Trust in a voice interface isn't a vibe — it's a threshold you can reason about. Users forgive a system that says "I'm not sure, did you mean X?" far more than one that confidently does the wrong thing. So when I design a voice-first flow, I treat calibrated uncertainty as a first-class feature: the assistant should know when it doesn't know, and degrade to a question or a glanceable confirmation instead of guessing. A wrong silent action burns trust three times faster than a clarifying question earns it.
Spatial computing — digital objects placed and anchored in real 3D space — is the piece people are most skeptical about, and fairly so. The first decade of augmented and mixed reality was defined by heavy headsets, motion sickness, battery anxiety, and a use case that never rose above "cool demo." I've worn enough of them to have opinions. Most of them made me want to sit down.
But separate the current hardware from the actual idea. The idea is that information should live where the task is, at the scale the task needs, instead of being crammed onto a rectangle you hold at a fixed distance. Concretely:
The reason this matters for my thesis: spatial is where the big, rich, visual work migrates once glasses get light and cheap enough to wear all day. That's the last thing people assume the screen is safe for — "sure, voice handles quick stuff, but real work needs a monitor." Spatial computing is coming directly for that assumption. Not this year. But the headset-nausea phase is an engineering problem, and engineering problems get solved. When the glasses feel like glasses, the monitor becomes the fallback for spatial the same way the phone becomes the fallback for voice.
This is the part that actually changes my job, so let me get concrete. Designing for a screen and designing for the ambient world are almost opposite disciplines. Screen design assumes attention. Ambient design assumes you have none to spare. Here are the principles I've started applying, even in ordinary Flutter apps that still ship a full UI today.
Ask: what's the version of this feature that needs no screen at all? A reminder app's core loop is "capture a thing, get nudged about a thing." Both can be pure voice and audio. The screen is for the 10% case where you want to see the whole list. Build the 90% path first; treat the list view as the fallback, not the product. This inverts the usual order of work, and that's the point — if the screen is the last thing you design, it stops secretly becoming a crutch for a weak underlying model.
Screen flows assume you'll finish the wizard. Ambient flows get abandoned constantly — you started asking something and walked into a meeting. State has to survive interruption gracefully. In practice that means designing around resumable, idempotent operations, not multi-step forms that lose everything if you leave. If replaying the same intent twice can't corrupt anything, you've built something that survives the real world.
The best ambient output is a single bit: a light color, a chime, a one-line spoken sentence. If your feature can't collapse to something glanceable or a single spoken sentence, it's not ready to leave the screen yet. That constraint is brutal and clarifying — it forces you to answer "what is the one thing the user actually needs to know here?"
Here's the shape of it in code — an interaction router that treats surfaces as a fallback chain, not a single target. Notice that the screen is the last branch:
enum Surface { ambient, voice, glance, screen }Future<void> present(Interaction i, UserContext ctx) async { // Escalate only as far as the content and context demand. if (i.canBeAmbient && ctx.attention == Attention.none) { return ambient.signal(i.toSignal()); // a light, a chime — no words } if (i.isConversational && ctx.handsFree) { return voice.speak(i.toUtterance()); } if (i.fitsAGlance && ctx.hasWearable) { return glance.show(i.toGlanceCard()); // one line, one action } return screen.render(i.toFullView()); // the fallback: the whole rectangle}The mental model I want to burn in: screen.render is the last branch, not the first. For most of the history of software it was the only branch. Designing the escalation ladder above it — deciding what can be a chime, what can be a sentence, what genuinely needs pixels — is the actual work of the next decade.
One implementation note from experience: keep UserContext (attention, hands-free, wearable presence) as an explicit input, not something each surface sniffs out for itself. The context model is the thing you'll iterate on for years; the surfaces are comparatively dumb renderers. Get the boundary right and you can improve the "when to escalate" logic without rewriting every feature.
If the screen is a fallback, the concept of an "app" — an icon you tap, a rectangle you enter, a session you start and end — starts to look dated. The most valuable software of the next ten years won't have an icon. It'll be a capability that lives in the ambient layer and only manifests a UI when it has to.
Think about what a bank "app" fundamentally does. Ninety percent of it is: tell me my balance, warn me about weird charges, move money on command. Every one of those is a sentence. The screen version — log in, navigate tabs, find the thing — is the worst way to do all three. It exists because that's the surface we had. Strip it back and the bank becomes a capability you query and that pings you, with a screen appearing only for the rare visual task like reviewing a year of spending.
This is a genuinely uncomfortable shift for anyone whose business model is built on screen time. An app that disappears into the environment doesn't show ads, doesn't have a feed, doesn't measure engagement in minutes. The whole attention-economy stack assumes the rectangle is the product. When the rectangle becomes a fallback, that assumption breaks — and I suspect that's exactly why the incumbents will be the slowest to build this. The companies that win the ambient layer will mostly be ones that don't have a screen-time business to protect.
For those of us who build things, there's a quieter opportunity here. The best software has always tried to get out of the user's way. Ambient computing is the first surface where getting out of the way is the entire design goal, not a nice-to-have you sand down after shipping.
I'm not a utopian about this, and I don't want to write the version of this post that pretends the screen was a mistake we're finally correcting. We lose real things when we take away the rectangle, and they're worth naming honestly.
So the screen doesn't vanish. It retreats to the jobs it's genuinely best at: dense visual data, precise selection, shared viewing, auditable trails, and discovery of what a system can even do. That's a real and permanent role. It's just no longer the default role, and that's the whole argument.
The trap to avoid is building the ambient future as a thin voice wrapper bolted onto a screen-first product, because that's the easy demo and it always disappoints. The screen has to become the fallback in the architecture, not just in the marketing. If your "voice mode" is a feature flag over a screen app, you've built a costume, not a shift.
screen.render as the last branch in the escalation ladder, not the first.