System requirements

Building a Day app requires Rust and the SDK or development libraries for each target. The requirements below are grouped by development host and target platform. day doctor can check the installed tools and report what is missing.

Check with day doctor

day doctor checks your development host for installed toolchains and reports missing requirements with setup guidance. The sections below describe the tools needed by each target.

day doctor                       # every toolkit buildable on this host
day doctor --toolkit android     # focus one toolkit, with full setup instructions

Bare day doctor treats a missing toolkit as a warning and exits 0, because you only need the toolkits you build for. Naming a toolkit with --toolkit turns its misses into errors and prints that toolkit’s setup text. For a full check, day doctor verify scaffolds a throwaway app and builds (and packs) it for each target; see CLI & projects.

For build errors or device connection problems, see Troubleshooting.

Every host

WhatVersionWhere
Rust1.89 or newerrustup.rs
The day CLIcurrent releaseGetting started
Gitanygit-scm.com

Install Rust through rustup, not Homebrew or a distro package. Cross-compiled targets (iOS, Android, HarmonyOS, and the web) need rustup’s per-target standard library, which a system rustc does not carry. rustup update stable keeps you current.

Everything else depends on which targets you build.

Which targets build on which host

TargetmacOSLinuxWindows
macos-appkit
ios-uikit
windows-xaml
linux-gtk / windows-gtk / macos-gtk
linux-qt / windows-qt / macos-qt
android-mdc
harmony-arkui
web-dom

Apple’s toolkits build only on macOS, and XAML only on Windows, because both compile against SDKs that ship with the host OS. GTK and Qt are portable, so a macOS or Windows machine can build and run them for development even though you ship linux-gtk and linux-qt.

macOS

The required macOS version depends on Xcode: install the newest version your macOS supports, and check Apple’s minimum requirements if you are on an older release. Continuous integration builds on the current macos-latest runner (Apple silicon).

The GTK, Qt, Android, and web targets need Apple’s command-line development tools on macOS:

xcode-select --install

Full Xcode (App Store) is required for ios-uikit, whose build runs through xcodebuild. Point the command-line tools at it once installed:

sudo xcode-select -s /Applications/Xcode.app
rustup target add aarch64-apple-ios-sim

A scaffolded app carries platform/macos/DayApp.xcodeproj, and macos-appkit builds through xcodebuild, so it wants full Xcode too. (An app that predates the scaffold adopts it with day project add-target macos-appkit.)

Homebrew provides the rest:

brew install gtk4 libadwaita pkg-config    # macos-gtk
brew install qt pkg-config                 # macos-qt
brew install openjdk@21                    # android-mdc
brew install qemu                          # the HarmonyOS emulator

Swift is needed only when a dependency embeds SwiftUI (SwiftUI embedding); Xcode and the command-line tools both provide it.

Windows

On Windows 10 or 11, the windows-xaml target uses the XAML that ships inside those releases rather than WinUI 3, so there is no framework runtime for you or your users to install. See the Windows platform page for the details.

For windows-xaml, install the Visual Studio 2022 C++ Build Tools (MSVC plus the Windows 10/11 SDK) and the MSVC Rust toolchain:

rustup default stable-msvc

For windows-qt and windows-gtk, install MSYS2 and build with a GNU Rust toolchain, because MSVC cannot link MSYS2’s import libraries, and the C++ shims are built from pkg-config’s flags, which an online-installer Qt does not ship:

pacman -S mingw-w64-x86_64-qt6-base                              # Qt
pacman -S mingw-w64-x86_64-gtk4 mingw-w64-x86_64-libadwaita      # GTK
rustup toolchain install stable-x86_64-pc-windows-gnu

On ARM64 hosts, use the CLANGARM64 environment’s mingw-w64-clang-aarch64- packages and the stable-aarch64-pc-windows-gnullvm toolchain. Build with MSYS2’s bin on PATH and RUSTUP_TOOLCHAIN set to the GNU toolchain; the Windows page walks through it.

Linux

Day’s minimums are library versions: GTK 4.10 with libadwaita 1.5, and Qt 6. Any distribution whose repositories carry those development packages works. Continuous integration builds on Ubuntu 24.04.

# Debian / Ubuntu
sudo apt install libgtk-4-dev libadwaita-1-dev pkg-config     # linux-gtk
sudo apt install qt6-base-dev pkg-config                      # linux-qt

The GTK minimums are hard requirements. Day builds stack navigation on AdwNavigationView, and its file and alert dialogs on GtkFileDialog and GtkAlertDialog; none of those exist in earlier releases. Debian 12 ships GTK 4.8 and cannot build linux-gtk; run -p linux-qt there, which needs only Qt 6, or build against a newer runtime. day doctor reports the installed versions against these minimums, so run it first; a version miss otherwise surfaces as a build failure inside gdk4-sys.

Fedora, Arch, and openSUSE ship the same libraries under different package names; check GTK’s installation page and Qt’s for the equivalents.

Day finds both toolkits through pkg-config, so it is required.

Optional: web views

The web view piece needs one extra development package on the Linux desktop toolkits. Without it the piece compiles out and renders a placeholder; the rest of the app is unaffected.

ToolkitPackageEngine
GTKlibwebkitgtk-6.0-dev (Debian/Ubuntu), mingw-w64-x86_64-webkitgtk6 (MSYS2)WebKitGTK 6
Qtqt6-webengine-dev (Debian/Ubuntu)Qt WebEngine

Two toolkit combinations have no web view package. Homebrew’s webkitgtk vends the GTK 3 API and has no bottle, so macos-gtk builds without a web view. MSYS2 ships no Qt 6 WebEngine, so windows-qt does too.

Optional: packaging tools

These are needed only to produce an installable artifact with day pack. Packaging & distribution covers the formats themselves.

TargetToolInstall
linux-gtk, linux-qtflatpak-builderflatpak.org, plus the Flathub remote
linux-gtk, linux-qtlinuxdeploy and its GTK or Qt pluginlinuxdeploy releases
windows-xamlmakeappx, signtoolthe Windows 10/11 SDK (installed with the Build Tools)
windows-xamlmakensisNSIS, or choco install nsis

Without the linuxdeploy GTK or Qt plugin an AppImage still builds, but it will only run on a machine that already has the toolkit installed.

Android

Android cross-compiles the app to a JNI shared library and runs it inside a Gradle app, so it needs the Android SDK, an NDK, and a JDK regardless of which host you are on.

  1. Install the Android SDK, most easily through Android Studio, or the standalone command-line tools. Day finds it at the platform default (~/Library/Android/sdk on macOS, %LOCALAPPDATA%\Android\Sdk on Windows, ~/Android/Sdk on Linux); set ANDROID_HOME if yours is elsewhere.
  2. Install an NDK with sdkmanager --install "ndk;<version>", or from Android Studio’s SDK Manager under SDK Tools. Day uses the newest one under <sdk>/ndk unless ANDROID_NDK_HOME says otherwise.
  3. Install a JDK, version 17 or newer (brew install openjdk@21, or Adoptium). The Gradle build uses $JAVA_HOME, so set it if the java on your PATH is older.
  4. Add the Rust target and cargo-ndk:
rustup target add aarch64-linux-android    # arm64 device or emulator
rustup target add x86_64-linux-android     # x86_64 emulator
cargo install cargo-ndk

To open, build, or run the app from Android Studio, use Android Studio 2026.1.4 (Quail 4) or newer. Day’s Gradle plugin builds with the Android Gradle Plugin 9.4, and Android Studio syncs only the AGP versions it supports. day build and day launch run Gradle themselves, so they work with any Android Studio release.

Setting up an emulator

Create an AVD in Android Studio’s Device Manager, or with avdmanager create avd, then start it:

emulator -avd <name>
adb devices                 # confirm it is listed as `device`

Day can list existing AVDs with day devices list -p android-mdc and start one with day devices boot -p android-mdc AVD_NAME --wait. See Android troubleshooting if it is not detected. Match the emulator’s ABI to an installed Rust target; an x86_64 system image needs x86_64-linux-android. Set ANDROID_SERIAL when more than one device or emulator is attached, so day launch and day drive act on the one you mean.

A booted emulator is needed only to run an app.

iOS

ios-uikit builds on a macOS host with full Xcode, as covered above. Xcode installs one iOS simulator runtime; add others from Xcode’s settings under Platforms (or Components, depending on your Xcode version); Apple documents the flow in Installing additional simulator runtimes.

xcrun simctl list devices          # what exists, and what is booted
xcrun simctl boot "iPhone 16 Pro"  # or open Simulator.app

day launch -p ios-uikit installs into a booted simulator, so boot one first. Apps ship to a physical device through Xcode’s normal signing setup.

HarmonyOS

HarmonyOS has two halves with different tool needs, which is why a partial install is common. The HarmonyOS platform page has the detail.

  1. The Rust cross-compile needs the OpenHarmony SDK’s native component, which downloads without a Huawei account from repo.huaweicloud.com. Point OHOS_NDK_HOME at it, and add the targets:

    rustup target add aarch64-unknown-linux-ohos x86_64-unknown-linux-ohos
  2. Packaging the .hap needs hvigor and ohpm, which are not part of the public SDK. They ship with the OpenHarmony command-line-tools, bundled with DevEco Studio or downloadable on their own. Put their bin/ directories on PATH.

hdc, which installs and launches the app, sits in the SDK’s sibling toolchains/ directory; Day finds it there or on PATH.

Setting up an emulator

Day runs the Oniro OpenHarmony emulator directly under QEMU, from a public image download:

brew install qemu                        # or your distro's qemu-system-x86_64
# download oniro_emulator.zip and unpack its images, then:
export DAY_OHOS_EMULATOR=~/ohos/emulator/images
day devices boot -p harmony-arkui                 # --headless for CI

The image comes from the device_board_oniro releases (v6.1 is what Day’s CI runs). DAY_OHOS_EMULATOR defaults to ~/ohos/emulator/images, so you can skip the variable by unpacking there.

The x86_64 emulator image carries an arm64-only ArkWeb engine, so the web view piece does not render there. It works on a physical device.

Web

web-dom needs only the wasm target:

rustup target add wasm32-unknown-unknown

day build -p web-dom writes a self-contained static site, and day launch -p web-dom serves it and opens a browser.

What your apps require

These are the minimums your users need, which the scaffold sets and you can raise in your project’s platform configuration. They are unrelated to what your development machine needs.

TargetMinimum
macos-appkitmacOS 13
ios-uikitiOS 16
android-mdcAPI level 24 (Android 7.0), compiled against API 37
harmony-arkuiAPI level 18
windows-xamlWindows 10 or 11
linux-gtk / linux-qtGTK 4.10 with libadwaita 1.5 / Qt 6
web-doma current browser, served as static files