Applications

An application uses its chosen web, mobile, desktop, terminal, or device framework and integrates through the One contracts it needs. The application owns its interface and remains independently useful through those public boundaries.

The One Web guide covers the bounded Rust server-document facade used by Order Review. Its shared page and command-state values also have TypeScript bindings for the named Order Review browser and native consumers. These bindings do not establish a general One UI framework or require other applications to adopt Experience semantics. The Experience owner defines that exact scope.

Let a framework-native application own its interface

Routes, screens, components, loaders, actions, navigation, local state, styling, accessibility, interaction, and framework upgrades belong to the application. Use React, Next.js, SwiftUI, Compose, Flutter, Tauri, native terminal libraries, or another selected framework directly.

These applications do not acquire Experience places, presentation state, or realization claims merely because they use generated clients. If an external application needs to claim an exact Experience realization, it submits the admitted mapping and conformance evidence explicitly; One never infers that claim from routes, component names, rendered HTML, or package presence.

The application consumes narrow One contracts where they provide value:

nominal values, schemas, validation, and codecs;
operation clients and server bindings;
authentication and scoped capabilities;
typed state and streaming interfaces;
Build artifacts, deployment bindings, and runtime configuration;
observations, causal references, and inspection envelopes.

Give each application its own root

A browser, API, worker, migration, and operator interface should normally be separate roots. The browser closure includes public schemas and client credentials, not database drivers or server secrets. The operator closure can request inspection and bounded control capabilities without entering the customer application.

Shared UI or domain packages create explicit contract edges. Workspace membership does not merge roots.

Generate only mechanical bindings

Client generation projects owned contracts into the target language: nominal types, validators, codecs, operation calls, faults, and selected protocol bindings. A projection receipt records the contract revision, profile, toolchain, output, and loss.

Generated application shells, authentication flows, framework state, and product behavior are avoided because their value is not mechanical projection. Those remain ordinary maintained application code.

Keep live development honest

The development session may compose framework servers, typed API children, watchers, local providers, and source maps for one exact root. Its state is disposable and its authority is explicitly local.

Development readiness, simulation, and fixture data do not become Build, release, hosted, or production evidence. Production follows the same contracts through exact planning, Build, apply, and inspection.

Render product truth, not platform internals

End-user screens describe the user's work, choices, progress, and actionable outcomes. Internal stage names, provider wiring, raw faults, proof counters, and architecture evidence stay out of ordinary product chrome.

Deliberate configuration, troubleshooting, and evidence views may expose the smallest relevant technical state translated into user-actionable language. Glass-box inspectability remains available without turning every screen into a debugger.

Example

Illustrative TypeScript uses a generated client while the framework keeps its own route and component model:

TypeScript

const result = await orders.get({ customerId, orderId });
if (result.kind === "succeeded") return <Order order={result.value} />;
if (result.kind === "rejected") return <NotFound />;
return <Unavailable state={result} />;

Other application targets

The same generated clients enter mobile, desktop, terminal, and intermittently connected device applications. The framework keeps navigation, view state, layout, accessibility, and lifecycle; the client owns nominal values, operation calls, codecs, and dispositions.

A SwiftUI screen consumes a generated client without adopting an Experience renderer:

Swift

struct OrderScreen: View {
    let client: OrdersClient
    let key: OrderKey
    @State private var state: ResourceState<OrderView> = .empty

    var body: some View {
        OrderContent(state: state)
            .task { state = await client.get(key) }
    }
}

An ordinary terminal application dispatches the complete outcome:

Rust

match client.get(&key)? {
    Succeeded(order) => terminal.show_order(order),
    Rejected(NotFound) => terminal.show_not_found(key),
    Denied => terminal.show_access_required(),
    Failed(cause) => terminal.show_recovery(cause),
}

ParcelHub's current terminal presentation owns executable evidence for exact generated dispatch and unknown-outcome operator guidance. Intermittently connected devices use explicit bounded capability rather than retained online authority:

TypeScript

const result = await telemetry.append(batch, {
  cursor: retainedCursor,
  lease: selectedLease,
});

if (result.kind === "gapDetected") await resnapshot(result.oldestAvailable);
if (result.kind === "revoked") stopOfflineSubmission();

Follow Use One from a framework-native application.