Developing a native app

A native app supplies the part that is specific to its job: the resource types it understands, the views that show them and the actions that change them. The system supplies storage, search, history, undo, permissions, syncing and the routes into those actions from the visible interface, keyboard, assistive tools and scripts.

Start with a resource

A resource is something the person works with: a note, book, annotation, event or track. Resources can contain other resources; an annotation can belong to a book without being reduced to a byte range in one private database.

Register the resource type and its view. The system owns the stored state and decides where it lives and how it syncs. The app decides how that type looks and which job-specific behaviour it needs.

Make every change an action

An action is a small, serialisable change such as Add note, Rename track or Delete annotation. It must contain all of its inputs and apply deterministically. Mint an ID when the action is created and put it in the payload; do not read the clock, generate another ID or consult global state while applying it.

That constraint is what lets another peer replay the same operation, lets the system record a useful history boundary and gives undo, tests and attribution one shared mechanism.

The toolbar, command palette, keyboard route, screen reader and script should dispatch the same action. Do not build a second automation API with more power than the interface a person uses.

Build one complete vertical slice

1. Pick one useful resource type.
2. Give it a minimal view.
3. Define one action that changes it.
4. Apply the action without hidden inputs.
5. Invoke it from the visible UI and the command palette.
6. Check history and undo before adding the next action.

This is deliberately narrower than scaffolding an entire application. It tests the part that makes an app native to the platform before time is spent on the rest of its interface.

Read running examples

The source repository becomes public with the alpha. Once it does, start with apps/notes/src/actions.rs for a small application action set, apps/maps/src/actions.rs for a different domain, ui/examples/ for toolkit patterns, and apps/ for the complete application directory. Until then, these paths are references rather than dead public links.

Start with the example closest to the state your app holds. Expect interfaces to change while the model is being tested across the remaining applications.