Reaktor Surface

An illustrated architecture for adaptive, tactile, graph-native interfaces

Surface: meaning to platform realization

HLD — Graph owns state and operations; Surface owns presentation. The common host and React adapter are planned work. Open the diagram for full size.

An interface is more than the image on a screen. It is a relationship between a person's intent, the application's state, the controls that express that state, and the platform that makes those controls usable. Reaktor Surface gives these responsibilities explicit boundaries. Its component contracts are defined in Kotlin. Its application capabilities and long-lived state belong to Reaktor Graph. Its two renderer targets are React for web in a JavaScript runtime and Compose Multiplatform. Its interaction, layout, motion and tactile feedback execute close to the renderer rather than waiting for an application-wide round trip.

This architecture supports both quiet and expressive interfaces. A form can remain almost still. A social interface can respond through compressible surfaces, neighboring material movement and optional haptics. A workbench can combine dense controls with a specialized canvas. In each case, the component's meaning and the user's work remain independent of its current appearance. Supported subgraph updates change the affected interface through the existing Reaktor execution system; Surface does not introduce a separate update authority.

Implementation status and the Manna design benchmark

Surface already implements pure behavior/planning kernels and a useful Compose catalogue. A production portable composition host and Kotlin React Surface renderer are still missing. Specialized editor packaging and full nested Notes editing also need target qualification. The architecture is a plausible fit, conditional on these proof slices; it is not evidence that the migration already works.

Read the Manna requirement-to-design benchmark for the evidence matrix and K1/K3/K4 exit criteria. React Native and custom React-to-CMP reconciliation are deferred. React Strict DOM remains an optional web experiment.

Read the chapters

The web textbook contains inline HLDs and the finalized 6 October renderer decision. The earlier illustrated PDF is an archived design snapshot; the current web chapters supersede its RSD/native renderer scope.

  • Foundations — Chapters 1–6: interface problems, core concepts, architecture, platforms, and a Send action.
  • Contracts and interaction — Chapters 7–10: component contracts, events, behavior, and interaction.
  • Design and ownership — Chapters 11–14: atomic design, state ownership, theming, and adaptive layout.
  • Renderers and shared authoring — Chapters 15–17: Compose, React, and renderer boundaries.
  • Motion and materials — Chapters 18–20: animation, tactile response, and material effects.
  • Performance and assets — Chapters 21–23: scheduling, memory, images, and asset delivery.
  • Dynamic UI and verification — Chapters 24–26: graph updates, specialized interfaces, and verification.
  • Application patterns — Chapters 27–30: BestBuds, workbenches, media, and communication.
  • Application extensions — Chapters 31–33: commerce, creative software, and accessibility.
  • Implementation plan — Chapter 34: a staged Compose-first implementation plan.
  • Desktop — Chapters 35–37: focus, keys, overlays, menus, commands, density and cost, then collections, panes, tab sets, notices and islands on the desktop.
  • References — Sources and further reading for Reaktor Surface.

The current implementation and proposals are distinguished within the chapters. Reaktor Graph remains the authority for application state and capabilities.