How Zeph works
Ships today

ZephOS

The software on the device: a real-time kernel, a UI toolkit, the glance shell, and a sandbox for apps — built as one thing.

ZephOS is the software on the device.

A real-time kernel sits at the bottom. A UI toolkit sits on top of that, then a shell that owns the screen, then a sandbox that runs apps you did not write. Those four are compiled into one firmware image and flashed together: one thing to update, and it is the whole thing.

Apps are the exception. They arrive later, over the wire, into the sandbox.

What is inside the firmware

One firmware image. All four are flashed and updated together.

The app sandboxA WebAssembly interpreter. Apps are loaded into it at runtime, one at a time.
The glance shellThe strip of faces, the rooms behind them, and one router that every gesture and button funnels into.
ZephUIA screen is a tree of widgets. The renderer walks the tree and draws it.
The kernelReal-time, underneath everything: threads, drivers, storage, Bluetooth, USB.
The boardAn ESP32-S3 with an AMOLED display.
Apps sit above this block, not inside it: the sandbox ships with the firmware, the apps you put in it do not. ZephUI is marked because it is the layer the rest of this page turns on.

An app's screen is a tree

An app never draws pixels directly. It describes a screen — a tree of widgets: a title, a big numeral, a list, a row of buttons, a ring, an image — and the renderer turns that description into what you see.

An app's screen is a tree. So is a screen your computer pushes across while the device is in your hand. So are many of the screens the device ships with. One renderer, several authors.

How anything reaches the screen

The appSays what it wants shown.
a widget tree
ZephUIReads the tree. Draws the widgets.
pixels
The screenThe only place pixels are made.
What crosses the first arrow is a description of a screen. The renderer owns the screen — an app is handed no pixels of its own.

Two things follow from that arrow. An app picks from the widgets and backgrounds the renderer offers, and the renderer draws them. And a screen is small: it is a description of what to show, not the pixels themselves, so pushing one across from your computer costs nothing like sending an image.

How small a screen actually is

The device holds each screen as under a kilobyte of description — the widgets and their values, not the pixels. That is why a screen can be pushed across from your computer for almost nothing.

Apps run in a sandbox

An app is a small WebAssembly module you upload to the device, and ZephOS runs it in a sandbox. What you upload is what runs.

The module, for the curious

A module is up to 64 KB. The sandbox is a WebAssembly interpreter — WAMR — with no ahead-of-time or just-in-time compilation step on the device, so what you upload is what executes, and nothing turns into native code along the way.

An app reaches the system through a deliberately small set of doors. It can push a screen and move you between rooms. With permission, it can hold a little state of its own, keep the device awake, play a sound, record audio, keep files, and talk to its other half on your computer. Every one of those is a capability that has to be granted.

When a permission is checked

Each time an app reaches for one of those doors, the runtime checks the grant right then — at the moment of the call, not at install time.

The runtime is also watching. A guest that runs away, or that pushes screens faster than its budget allows, is cut off part-way through the call.

What an app is not handed: the run of your files, a network connection of its own, a way to keep running in the background, or any hardware the firmware did not pass it. Those doors are shut in the build.

One app at a time

The device runs one app at a time. Opening another retires the one that was running: it is torn down, and the new app stands up in its place. It is a real device with a fixed amount of memory, and that memory goes to the app in front of you.

The shell owns the way out

The glance shell is the part you touch: the strip of glances, the rooms behind them, and the overlays that come over the top. Its job is spatial — which face you are on, which room you are in, and how you leave.

Every input funnels into a single router. An edge swipe, a tap, a button press — each becomes the same small vocabulary of actions before anything reacts. So an app cannot invent its own escape hatch, and the way out never moves.

Where colour is today

The strip is monochrome: neutral ink on true black. Signal Blue is the accent; green, amber and red carry status. A face on the strip takes its colour from the system, whichever app is behind it.

Open the app and the colour is the app's. Its surface can set a solid background, a background image drawn full-bleed under the status bar, and a tint on the navigation bar — each one a colour the app names and the renderer applies. It can hide the status bar for its own screen too. The app chooses the colour; ZephUI still paints every pixel.

How a colour is named

Each colour the app sets is a plain hex value — written 0xRRGGBB — which the renderer applies as it paints.

Keep reading

On this page