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
| What | Version | Where |
|---|---|---|
| Rust | 1.89 or newer | rustup.rs |
The day CLI | current release | Getting started |
| Git | any | git-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
| Target | macOS | Linux | Windows |
|---|---|---|---|
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.
| Toolkit | Package | Engine |
|---|---|---|
| GTK | libwebkitgtk-6.0-dev (Debian/Ubuntu), mingw-w64-x86_64-webkitgtk6 (MSYS2) | WebKitGTK 6 |
| Qt | qt6-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.
| Target | Tool | Install |
|---|---|---|
linux-gtk, linux-qt | flatpak-builder | flatpak.org, plus the Flathub remote |
linux-gtk, linux-qt | linuxdeploy and its GTK or Qt plugin | linuxdeploy releases |
windows-xaml | makeappx, signtool | the Windows 10/11 SDK (installed with the Build Tools) |
windows-xaml | makensis | NSIS, 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.
- Install the Android SDK, most easily through
Android Studio, or the standalone
command-line tools. Day finds it at the platform default
(
~/Library/Android/sdkon macOS,%LOCALAPPDATA%\Android\Sdkon Windows,~/Android/Sdkon Linux); setANDROID_HOMEif yours is elsewhere. - 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>/ndkunlessANDROID_NDK_HOMEsays otherwise. - Install a JDK, version 17 or newer (
brew install openjdk@21, or Adoptium). The Gradle build uses$JAVA_HOME, so set it if thejavaon yourPATHis older. - 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.
-
The Rust cross-compile needs the OpenHarmony SDK’s
nativecomponent, which downloads without a Huawei account from repo.huaweicloud.com. PointOHOS_NDK_HOMEat it, and add the targets:rustup target add aarch64-unknown-linux-ohos x86_64-unknown-linux-ohos -
Packaging the
.hapneedshvigorandohpm, 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 theirbin/directories onPATH.
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.
| Target | Minimum |
|---|---|
macos-appkit | macOS 13 |
ios-uikit | iOS 16 |
android-mdc | API level 24 (Android 7.0), compiled against API 37 |
harmony-arkui | API level 18 |
windows-xaml | Windows 10 or 11 |
linux-gtk / linux-qt | GTK 4.10 with libadwaita 1.5 / Qt 6 |
web-dom | a current browser, served as static files |