Glossary

This page defines the words the docs use, in the sense Day gives them. Where a term has an everyday meaning too, the entry says which one applies. Each entry names the page that introduces the concept; that is the place to read next. Elsewhere in the docs, a term with a dotted underline is one of these, and hovering it shows the definition.

Backend: The Rust crate that implements Day's toolkit interface for one toolkit, such as day-appkit or day-gtk. A Day binary links exactly one, chosen by a Cargo feature when it is built.Defined in Architecture
Binding: The link between a reactive closure and one native widget attribute: the closure re-runs when its reads change, and its result is applied to the widget. label(move || …) creates one. Also the trait behind two-way controls such as slider(signal).Defined in Reactivity
Capabilityalso Cap: What a backend can do, asked at run time with capability(Cap::…): Native, Emulated, or Unsupported. An app checks before offering a toolbar or a menu bar. A device capability, such as the battery or location, is a different thing: that is a part.Defined in Menus, toolbars, and windows
day (the CLI)also day-cli: The command-line tool that creates, builds, launches, packs, lints, and scripts Day projects, the same by hand, from CI, or from an IDE. Lowercase day is the binary and the Rust crate; capitalized Day is the framework.Defined in CLI & projects
Day.toml: The project manifest, and the marker that makes a Cargo package a Day project. It holds everything Day-specific, such as the app id and its targets; name and version come from Cargo.toml and are never restated.Defined in CLI & projects
dayscript: Day's automation language: a YAML file of steps that drives and asserts a running app. The engine is compiled into your app and executes steps as real Day events, so one script runs on every target and waits are deterministic.Defined in Testing with dayscript
Declarative: Describing what the UI is rather than the steps that build it. A Day app is a declarative tree of pieces; Day turns the tree into widgets and keeps them in sync with your state.Defined in Overview
Decoratoralso modifier: A modifier such as .padding(), .frame(), or .id() that wraps a piece and returns Decorated<P>, keeping the piece's own type. Decorators live only in Day's tree and create no native widget.Defined in Pieces
Fluent: Mozilla Fluent, the message format Day localizes with. Translations live in resource/locales/<lang>/app.ftl, one file per language, and build.rs turns each message into a typed function under res::str.Defined in Localization
Imperative: Step-by-step instructions to a widget, as opposed to a description of the result. Day keeps imperative work behind the reactive system, in the patches that update a native widget.Defined in Tweaks
Kind: The stable string that names a piece to every backend, such as day.label or day.piece.lottie. A backend dispatches a kind to its renderer; a kind it does not know draws a placeholder.Defined in How rendering works
Locale: Which translation and formatting rules are in force. A locale is chosen from a CLI override, then the OS preference, then the app's default, and it can change while the app runs.Defined in Localization
Native: Made of the platform's own widgets. A Day button() is an NSButton on macOS and a MaterialButton on Android, so text input, scrolling, dark mode, and screen readers are the platform's too.Defined in Overview
Nav: The navigation piece for one of several top-level sections, bound to a Signal<String> holding the active item's key. It becomes a sidebar on the desktop and tabs where that is the platform's idiom.Defined in Navigation
Page: One screen's worth of UI: a function that returns a piece, registered under a route and shown by a nav or a nav_stack. Pages live under src/pages/ by convention. A window can show more than one at a time: a phone shows a single page, while the same app on a tablet or desktop may lay out a sidebar, a list, a detail page, and an inspector across several navigation levels.Defined in Navigation
Part: A headless platform capability: a set of functions with no UI whose implementation differs per operating system, shipped as an ordinary crate (day-part-*). Battery, clipboard, and location are parts.Defined in Device capabilities (parts)
Piece: A description of one part of the UI, built once into a native widget. label, button, and column are pieces; so is any function of yours that returns impl Piece. The word also names a UI extension crate (day-piece-*).Defined in Pieces
Placeholder: What you see where a piece has no native implementation on this toolkit: its kind, in angle brackets. Coverage grows toolkit by toolkit, and the placeholder marks what is left.Defined in The extension model
Platform: An operating system a Day app is built for and deployed to: macOS, iOS, Android, Linux, Windows, HarmonyOS, or the web. A platform can host more than one toolkit; the pair is a target.Defined in Platform support
Reactive: Updating by itself when something it reads changes. Day's reactive system is a fine-grained signal graph: state lives in signals, and a closure that reads one re-runs when it changes, ending in one native widget update.Defined in Reactivity
Resource: A file under the project's resource/ directory, such as a locale, an image, a font, an icon, or an asset, each staged through the platform's native resource system. Code reaches one through a generated constant under res:: rather than a bare string. Each platform's own tooling processes, compresses, and packages them, so a resource ends up where that platform expects it, in the form it expects.Defined in Resources, images, fonts & icons
Route: A typed navigation destination declared with the routes! macro: what nav, nav_stack, deep links, and dayscript navigate speak. Written as segments/joined/by/slashes; a single key is relative and a multi-segment path is absolute.Defined in Navigation
Sidebar: A list of sections beside the content. Day builds the selected page on demand and disposes it when the selection changes, so a sidebar's page state lives in your signals.Defined in Navigation
Signal: Signal<T>, a reactive cell holding one value. The handle is Copy, so you move it into as many closures as you like; reading it inside a reactive closure subscribes that closure to changes.Defined in Reactivity
Size class: A bucket for a window's width or height in points, using Android's window size classes on every platform: Compact, Medium, Expanded, Large, and ExtraLarge for width. The class can change while the app runs, when a phone rotates or a desktop, tablet, or browser window is resized, and navigation re-resolves its shape each time, so one nav host fits a phone, a tablet, and a desktop window.Defined in Size classes
Split view: A window divided into a section list and a detail pane. It is how the platform draws a sidebar nav host when there is room; on narrow screens the same nav host pushes pages instead.Defined in API tour
Target: An (OS, toolkit) pair, written macos-appkit, ios-uikit, android-mdc. One binary is compiled per target, containing only that toolkit's backend.Defined in Overview
Toolkit: A native widget system: UIKit, Android's Material Components, AppKit, GTK 4, Qt 6 Widgets, Windows XAML, ArkUI, or the browser DOM. Day builds each piece with the widgets of one toolkit per binary.Defined in Overview
Tweak: A supported way to reach the real native widget behind a built-in piece and configure it, while Day keeps owning layout and lifecycle. A piece with a tweak applied keeps the same widget, with a little more configured.Defined in Tweaks
Walkthrough: The main script in a project's dayscript/, conventionally walkthrough.yaml. CI runs it on every target, and the gallery shows its captures.Defined in Testing with dayscript