One supports two honest application models. A contract-driven web application can use the first-party One Web framework. An application can also use an ordinary web, mobile, desktop, terminal, or device framework without turning that framework into a One renderer.
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 One Web 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:
const result = await orders.get({ customerId, orderId });
if (result.kind === "success") return <Order order={result.value} />;
if (result.kind === "domain_fault") return <NotFound />;
return <Unavailable state={result} />;Follow Use One from a framework-native application. Mobile, desktop, terminal, and device variants are covered in Build other application targets.
See also roots and composition and languages and SDKs.