Internal reference docs
These are Day's framework internal docs: the design and reference notes that live in the repository's docs/ folder, rendered here for easy reading. They are written for contributors and framework authors, and are the source of truth for how each subsystem works. If you are building an app, start with the curatedDocumentation instead.
Core & UI
Framework-level UI: navigation, lists, layout containers, drawing, text, and the cross-cutting concerns every app touches.
Navigation
Day models navigation the way it models everything else: as a projection of an app-owned Signal. There is no imperative navigation controller in app code:…
List
list drives the platform's recycling list (NSTableView / UITableView / RecyclerView / GtkListView / QListView), so large collections get native…
Tabs
Note (migration): tabs are now selector(sel).style(SelectorStyle::Tabs), a one-of-N > selector bound to a Signal<String> of the active tab key…
Shapes
Status: implemented (Proposal A, the canvas-backed unified shape piece). The shape piece > (daypieces), reactive…
Text
label(...) renders native text. Its font is chosen from a semantic (logical) style that maps to each platform's own text styles, so a Day app matches the…
Picker
Status: implemented as a built-in piece (kinds::PICKER; moved in from the satellite > day-piece-picker 2026-07). One API, three SwiftUI-style stylings,…
Dialogs
Alerts, confirmations, action sheets, text prompts (and later native pickers) are imperative request→response interactions: an action opens one and needs…
Menus
Day renders menus with each toolkit's native menu machinery: NSMenu, GtkPopoverMenu / GtkPopoverMenuBar, QMenu / QMenuBar, UIMenu (via…
Progress
A progress indicator reports the state of ongoing work. Day exposes the two SwiftUI shapes as separate constructors so the call site says which one it…
Files
Day opens and saves files through each platform's native file-interaction UI, using the same imperative request→response model as dialogs: an action opens…
Resources
Day apps bundle three kinds of resource, all looked up by name, all routed through each platform's native resource machinery so they get the platform's…
Accessibility
Status: implemented (annotation pillar). A11yProps (label/hint/value/role/hidden/ > decorative/identifier) now reaches native accessibility APIs on all…
Localization
Day localizes with Mozilla Fluent. Text is a key resolved against the current locale; the current locale is a Signal, so every tr() binding re-runs on a…
Lifecycle
A Day app can hook the moments its process moves through: launching, gaining and losing focus, going to and from the background, running low on memory,…
Pieces
Standalone UI Pieces: native widgets that live in their own crates and plug in without any core changes.
Web view
Status: implemented as day-piece-webview, an external Day Piece (like day-piece-combobox) > registered link-time into each backend's renderer slice…
Media
Status: implemented as day-piece-media, an external Day Piece (like day-piece-webview), > registered into each backend's renderer slice without touching…
Lottie
Status: implemented as day-piece-lottie, an external Day Piece rendering a Lottie animation, > iOS + Android only. It is the reference for a piece that…
Map
Status: implemented as day-piece-map, an external Day Piece (like day-piece-media), > registered link-time into each backend's renderer slice without…
Search field
Status: implemented as day-piece-searchfield, an external Day Piece (like day-piece-combobox) > registered link-time into each backend's renderer slice…
Activity
Status: implemented as day-piece-activity, an external Day Piece (like day-piece-media) > registered link-time into each backend's renderer slice without…
Parts
Headless capability crates, the non-UI counterpart of Pieces. They provide device and system access without any widgets.
Battery
Status: implemented as day-part-battery (in parts/, the headless counterpart of > pieces/). It's a headless day-ecosystem crate (no UI Piece): a shared…
Sensors
Status: implemented as day-part-sensors (in parts/, the headless counterpart of pieces/). > It's a headless day-ecosystem crate (no UI Piece): a shared…
Clipboard
Status: implemented as day-part-clipboard (in parts/, the headless counterpart of > pieces/). It's a headless day-ecosystem crate (no UI Piece): a shared…
Network
Status: implemented as day-part-network (in parts/, the headless counterpart of pieces/), a > headless day-ecosystem crate with no UI Piece: a shared…
Http
Status: implemented as day-part-http (in parts/), a headless day-ecosystem crate with no > UI Piece: request/response HTTP (plus streaming downloads)…
Haptics
Status: implemented as day-part-haptics (in parts/, the headless counterpart of > pieces/). It's a headless day-ecosystem crate (no UI Piece): a shared…
Prefs
Status: implemented as day-part-prefs (in parts/, the headless counterpart of pieces/). > It's a headless day-ecosystem crate (no UI Piece): a shared…
Device info
Status: implemented as day-part-deviceinfo (in parts/, the headless counterpart of > pieces/). It's a headless day-ecosystem crate (no UI Piece): a shared…
Permissions
Status: implemented as day-part-permissions (in parts/, the headless counterpart of > pieces/), plus the build-time declaration pipeline in the CLI. It's…
Location
Status: implemented as day-part-location (in parts/, the headless counterpart of > pieces/). It's a headless day-ecosystem crate (no UI Piece): the…
Platform & tooling
Platform backends, the extension model for writing your own Pieces, API conventions, and editor tooling.
HarmonyOS
HarmonyOS Next dropped the AOSP layer; its UI framework is ArkUI. Day targets it with a native backend (day-arkui) built on the ArkUI Native NodeAPI,…
Extending
A piece is a reusable Day widget. Day ships built-in pieces (button, slider, list, …), but anyone can publish a piece as an independent crate that adds…
API style
Rust has no named arguments, so Day emulates their clarity where it pays and keeps SwiftUI-like terseness where it doesn't. The rule, in priority order:
VS Code extension
The Day VS Code extension lives in its own repository, daybrite/day-vscode, with its own release cycle (it drives whatever day CLI is installed, so its…
Other
Additional internal reference docs.
Agent
How coding agents (VS Code agent mode, Claude Code, any MCP client) build, run, and (uniquely) drive and see Day apps. The design rule throughout: every…
Datepicker
Status: implemented as day-piece-datetime, an external Day Piece registered link-time into > each backend's renderer slice without touching day: the first…
Environment
Day locates host toolchains and SDKs through one shared implementation (crates/day-toolchain), used by the day CLI, by every crate build script that…
Focus
Status: implemented on every backend (AppKit, UIKit, GTK, Qt, Android, XAML, ArkUI, and > mock). Event::FocusChanged(bool) (reserved by §8.3) is real,…
Forms
Status: implemented in day-pieces (portable: no per-backend renderer code beyond the > section-card surface below). A settings-style grouped form: form…
Pullrefresh
Status: implemented as day-piece-pullrefresh, an external Day Piece registered link-time > into each backend's renderer slice without touching day. It is…
Store
Status: implemented as store/ in a project, day store init / day store stage, the > day::lint::store-* checks, and a distribute job in day's own CI. What…
Tweaks
A tweak configures the native widget behind a Day-created piece: the extra NSButton or XAML Button method call that doesn't justify a whole custom piece.…
Web
Day's ninth backend renders in a browser. The DOM is the toolkit: a Day button is a real <button>, a slider is <input type="range">, a dialog is <dialog>:…
43 internal documents.