Developer handbook
Dasher v6 and beyond. This handbook covers the active v6 codebase — the shared DasherCore engine and native frontends (Apple, Windows, GTK). For the stable v5 release, see Dasher 5.0 downloads or the v5 development notes.
Dasher v6 is one shared engine (DasherCore) consumed by several native frontends. This handbook is the navigation hub for anyone working on Dasher code.
The architecture at a glance
| Repository | Platform | UI stack | DasherCore integration |
|---|---|---|---|
| DasherCore | All | C++ engine + C API | is the engine |
| Dasher-Apple | iOS / macOS / visionOS | SwiftUI | submodule (C API via bridging header) |
| Dasher-Windows | Windows | Avalonia (.NET) | submodule (C API via P/Invoke) |
| Dasher-GTK | Linux (+ Win/macOS fallback) | GTK4 / gtkmm | submodule (C API via CMake) |
dasher-web is a standalone WASM demo (not a full frontend) — it powers the live demo on the homepage. It’s available for anyone who wants to embed Dasher on the web, but it is not under active feature development.
Read the architecture overview for how the engine and frontends fit together, and the C API contract in DasherCore for the exact integration surface.
Where do I start?
- I want to build a platform → build guides.
- I want to fix a bug / add a feature → contributing.
- I want to know what’s supported where → the feature status matrix.
- I’m changing UX or hardware interaction across platforms → RFCs.
- I’m changing colours, type, spacing → design tokens.
Build guides
- DasherCore (the engine)
- Dasher-Apple (iOS / macOS / visionOS)
- Dasher-Windows (Avalonia)
- Dasher-GTK (Linux)
Keeping frontends in sync
Parity is a first-class goal. Every frontend PR template asks: “does this change a capability users see on other platforms?” If yes, update the feature matrix. If it’s a new UX/hardware interaction, write an RFC first so the other platforms can align their blueprints.
See: