Your own systems, on the radio, without shipping code to a handset

Every operation has a system the radio should talk to — a job board, a defect log, a gate register. A mini app puts one on the handset as a screen your people can use, described as a specification rather than written as code.

Tell us what you would build See the security model

In beta. The spec format, the widget renderer, the permission model and the audited webhook proxy are built and covered by tests, and four of our own apps — mail, telephony, aviation and maritime — run on the same machinery in production today. What has NOT happened is an outside organisation authoring one. We would rather build the first few with you than publish a format nobody has used in anger.

A specification, never code

You describe a screen as typed widgets — text, a status table, fields, a picker, buttons — and the handset draws it natively. Nothing an integrator writes ever executes on the device.

Renders instantly on cheap rugged hardware, because it is a native screen rather than a web view
No JavaScript engine, no bridge, no permission dialog standing between a third party and the microphone
An administrator sees the complete list of what an app can do before enabling it — complete because there is no escape hatch to leave off the list

What a mini app can do

Enough for the things a radio actually needs: log something, dispatch something, check a status, start a transmission.

Send what somebody typed to your own endpoint, proxied by us so it is logged and rate-limited rather than called from the handset
Start a push-to-talk transmission into a named channel, with the same floor control and the same encryption a person gets
Post a message, optionally with an alert tone, under the name of the person who pressed the button
Open a conversation the app already has

And what it deliberately cannot

The limits are the product. An integration can drive the radio; it cannot listen to it.

It cannot read message or voice content. No widget binds to it and no action returns it
It cannot reach an arbitrary host — endpoints are registered up front and resolved on our side, so the handset never talks to a stranger and its address never leaks
It cannot transmit in a way a person could not, because it uses the same floor and the same keys

Some of ours are built the same way

Mail, World Phone and the aviation and maritime screens are mini apps in every way that matters to an administrator: turned on per organisation, carrying permissions you approve, appearing in the same list, hidden by the same switch.

Only the drawing differs — a few of ours are native screens because a spec cannot express an inbox or a map, and we would rather admit that than grow the format into a small programming language
Hiding an app is enforced on the server, so a hidden app is not merely an icon the client chose not to draw
Which means the machinery is exercised daily by us, not just by a test suite

Why this is a security feature, not a limitation

This product’s claim is that the server relays ciphertext it cannot read and the handset is the only place plaintext exists. Running somebody else’s JavaScript next to that plaintext would be the largest hole the product has, and no permission prompt really closes it.

Every data flow is declared, so what an app can see is a list an administrator can read rather than a promise
The cost is honest: integrators build from a fixed widget set instead of shipping arbitrary interfaces
For logging an incident, dispatching a job or checking a status, that has been enough — and it is why we can tell you what an app cannot do and mean it

What would you put on the handset?

Tell us the system and the screen you picture, and we will tell you whether the format covers it today — and build the first one with you if it does.

Talk to us