Platform support

Day’s targets differ in testing coverage, packaging, and available features. The tables below summarize support tiers and CI checks; the platform notes describe known limitations. Installation instructions are in System requirements.

Support tiers

A support tier describes the testing and maintenance given to an operating-system/toolkit pair. It does not measure API completeness. A development target can implement a feature fully while still lacking release packaging or regular testing on physical hardware.

The target table below assigns each platform to a tier. Support badges throughout the documentation link back to this section.

A target can move to a higher tier when maintainers can provide the testing and support it requires. See contributing to platform support for the responsibilities, including hardware testing, bug triage, and patch review.

Status at a glance

The table lists the checks configured in CI and the package formats the CLI produces. Signing requires the platform’s tools and credentials. Android walkthrough failures do not fail CI; the HarmonyOS job also tolerates build and packaging failures.

Check the CI run for the revision you intend to ship. A tolerated failure does not block the remaining jobs.

Earlier project records describe additional Matrix-client usage. Those external apps and shipping claims were not inspected in this repository-only review and are not validation evidence for the current checkout.

Development combinations

GTK and Qt on macOS and Windows support toolkit compatibility testing on a development machine. They do not have release packaging. The GTK combinations also lack an accessibility tree.

Windows GTK and Qt use MSYS2. Under CI’s x86-64 MinGW linker, external piece renderers fail to register and appear as placeholders; an MSYS2 environment using Clang and lld retains them. Windows GTK also lacks WebKitGTK 6. See the Windows toolkit setup for details.

Per-platform notes

Each primary target has a setup guide, known limitations, and a mapping from Day pieces to native controls, with links to the platform’s API documentation.

macOS (macos-appkit) — full page

Tier 1 · Supported Day drives AppKit directly through objc2, with a native menu bar, dialogs, and window management. Builds require full Xcode 27 or newer for the JSON5 host project. Packaging produces a signed, notarized .dmg when credentials are configured (packaging).

iOS (ios-uikit) — full page

Tier 1 · Supported Day derives a JSON5 Xcode project under build/day/xcode/, requiring Xcode 27 or newer. A checked-in project remains an optional customization override. Its build phase calls back into day for the Rust static library, so Xcode, day launch, and CI all build the same way. Day-to-day development targets the Simulator; App Store .ipa export exists in day pack and needs your Apple credentials. Without signing.ios configuration, the output is an unsigned device archive with an -unsigned.ipa filename. Physical-device debugging gets less use than the Simulator.

Android (android-mdc) — full page

Tier 1 · Supported Day renders Material Components widgets over JNI, with a generated Gradle project and the same callback-build pattern. day launch installs on every connected device/emulator at once, each with the right ABI. Accessibility annotations are partial (details), and process-death restoration is a cold start unless your app persists its own state.

Linux (linux-gtk, linux-qt) — full pages: GTK, Qt

Tier 2 · Demi-supported Day renders GTK 4 + libadwaita via gtk4-rs, and Qt 6 Widgets via a small compiled C++ shim. The configured walkthrough uses a headless display. Flatpak packages both. The runtime supplies the toolkit, so bundles stay app-sized. Pick GTK by default; pick Qt for its cross-OS accessibility bridge or for the Qt library set. The webview piece is functional on GTK/Linux (WebKitGTK) and Qt (QtWebEngine).

Windows (windows-winui) — full page

Tier 2 · Demi-supported Day renders WinUI 3 controls from the Windows App SDK 2.5.1, hosted in a Win32 window through the SDK’s DesktopWindowXamlSource. It builds with MSVC, and its C++/WinRT shim follows the same pattern as Qt’s. Development builds need the Windows App Runtime installed; day pack ships the runtime inside the .msix and installer, so users install nothing extra. Fewer applications have shipped on it than on the Apple, Linux, and Android targets.

Windows, system XAML (windows-xaml) — full page

Tier 5 · Deprecated The same XAML backend built against the system XAML that ships with Windows, hosted through XAML Islands. It still builds, packs and runs for existing projects, but new apps should use windows-winui; move a project with day project add-target windows-winui.

HarmonyOS (harmony-arkui) — full page

Tier 3 · Experimental The newest backend drives ArkUI via the NDK C API, packaged as a .hap by hvigor with an ArkTS host project. The toolchain requires the OpenHarmony SDK and command-line tools, which take the most setup steps of the supported platforms; day doctor --toolkit harmonyos and the HarmonyOS notes cover the install. CI allows failures in the emulator checks.

Web (web-dom) — full page

Tier 3 · Experimental The same Rust compiled to WebAssembly drives DOM elements (<button>, <dialog>, <input type="range">) that the browser lays out and draws; the build runs through cargo and the day CLI alone. day build -t web-dom emits a self-contained static dist/ you can host anywhere; there is no day pack step because dist/ is already the artifact. It is experimental. The DOM backend now reports native file-dialog support and emulated list, tree, toolbar, and app-menu capabilities. External-piece coverage varies; inspect the coverage matrix and enable the piece’s DOM feature where present. Browser permissions, user-activation requirements, and accessibility behavior still need runtime checks; neither API presence nor an emulated capability proves desktop-equivalent behavior. The live build is deployed by the showcase’s CI.

Cross-cutting gaps

Framework-level features that don’t vary by platform but aren’t done, kept here so there’s one list:

• Animation: partial. with_animation(spec, || …) ships, and five of the eight backends execute opacity, transform, and frame changes natively: AppKit, UIKit, Android, web, and ArkUI (where frames move instantly). On GTK, Qt, and XAML the changes apply at commit with no animation (Cap::Animation reports unsupported), because Day never ticks its own frames for native widgets. An animated background color interpolates on UIKit and ArkUI only, and the enter/exit .transition surface is not implemented.
• Multi-window: secondary windows work on every backend — native windows on AppKit, GTK, Qt, XAML, and Android, UIScenes on iPad, a multiton ability on HarmonyOS; iPhone and web present them as a fullscreen cover in the primary window. Probe Cap::MultiWindow to adapt chrome.
• Semantic color tokens: custom colors have no automatic dark-mode variant (styling).
• Keyboard input: Decorate::on_key exists and has a focused-event conformance case. Menu accelerators remain a separate surface; delivery depends on focus and the backend.
• Gestures: Decorate::on_pinch exists with a conformance case. Do not infer every gesture or target from it; inspect the decorator and backend implementation for the needed gesture.
• Forms: no validation framework; roll your own with signals and memos.
• Hot reload: not present; see the tradeoffs page.

Check this list before you adopt the framework; if something you need is missing from it and doesn’t work, report it as a bug.

Interpret compatibility evidence

Support::Native, Emulated, and Unsupported describe one runtime capability, not a support tier. A source-generated coverage row records implementation branches; it cannot establish native interaction, accessibility quality, screenshots, or release readiness. Query capabilities for the operation you use and handle its return/error contract.

Evidence: Toolkit and Cap, DOM capability implementation, key and pinch decorators, and target registry. HarmonyOS emulator acceptance belongs in CI; local validation must stop at compile/lint checks.