Share the interface and the logic.
Define screens, layout, state, and event handlers in Rust. Day connects that code to each platform’s UI toolkit, so a new screen can become part of every build.
See how a Day app is built →Day — the universal app development framework.
One app.
Every platform.
All Day.
Build for the people who need your app, across phones and desktops. Share your interface and app logic in Rust, while Day connects them to each platform’s UI toolkit. Keep translations, UI tests, and packaging in the same project.
macOS, iOS, and Android are Tier 1; Windows and Linux are Tier 2. HarmonyOS is experimental. See current platform support →
For independent app makers
Take your app beyond its first platform.
A useful app shouldn’t stop at the device you happen to own. Day lets you reuse screens and app logic across desktop and mobile targets, then handle the differences in one project. Choose the platforms your audience needs.
Distribute it where people need it.
Build desktop installers and mobile packages, translate your store listings, and automate submissions to the major app stores from the same project.
Publish your app →Highest uncommon denominator
Your app can share its foundations and still have features that belong to one platform. Add native controls and services through extensions, with a fallback where that feature isn’t available.
Make Day your own →For Rust developers
Give your Rust code
a native interface.
Connect your data models and libraries directly to UI code without crossing language barriers. Compose controls with ordinary functions and attach them to reactive signals that update the interface when data changes.
Day uses AppKit on macOS, UIKit on iOS, Material Components on Android, and desktop toolkits on Windows and Linux. Standard controls use toolkit widgets; composed controls and custom drawing have their own implementations. Appearance and capabilities vary by target.
Explore the Rust API →Reuse your libraries
Keep parsing, storage, and other app logic in conventional Cargo crates. Use the same code from your UI wherever those crates support the target.
Update individual controls
Bindings update existing controls when their signals change. Adding or replacing a screen can create new controls; ordinary value updates do not require rebuilding the whole interface.
Compile to native machine code
Your Rust code compiles to machine code for each desktop and mobile target, alongside Day’s native toolkit integrations.
For small teams maintaining several builds
Reuse the tests
along with the app.
Every platform adds builds to check and packages to prepare. Day gives you a common CLI and UI test format: the same walkthrough can exercise a feature on several targets and capture its translated screens.
Edit →
Use the VS Code extension to choose targets, build, and launch your app from the editor.
Set up →
Generate the Rust project and platform host files with day new app. Use day doctor to identify missing SDKs and build tools.
Test →
Write a DayScript walkthrough that finds controls by stable IDs. Reuse it across targets to check the same behavior.
Capture →
Use screenshot steps in that walkthrough to capture the same screens in different languages and themes.
Package →
Build installers and mobile packages with day pack. Check the reported signing status before distributing them.
Diagnose →
Add Day’s crash-reporting extension to collect reports on the device. People can choose to send them by email, GitHub issue, or HTTP.
Builds still require the platform SDKs. Distribution requires the signing credentials and store accounts applicable to your chosen platforms.
For developers bringing an existing Rust library to people
Your library can have an app.
Give a command-line tool, parser, or local database a native interface without moving its logic into another language. Keep the library in a Cargo crate and build the screens around it. Check the library’s dependencies on each target you want to reach.
See how a Day project fits together →For apps serving multilingual communities
The world doesn’t all speak a single language.
Or use a mouse.
Keep your app’s meaning across languages.
Keep translations in Fluent catalogs. Day generates typed Rust accessors so the UI and its message arguments are checked together at build time. Use the same UI walkthrough in several languages to check translated screens.
See how localization works →Connect to native accessibility.
Native controls supply accessibility roles and actions. Day’s shared API lets you annotate controls; on macOS and iOS, DayScript can verify their labels, roles, and values against the native accessibility tree.
See accessibility support and limits →For native developers and library authors
Package your platform expertise
as a reusable Day extension.
Native integrations in Cargo crates.
Wrap a native widget or platform service behind a Rust API. Your crate can include Swift, Java, ArkTS, or C++ code. Day’s build tools collect the declared sources and dependencies into the app’s platform builds.
Build an extension →Share components across apps.
Combine existing Day controls into reusable components using Rust alone. A composed component uses the backends of its underlying controls, so you can publish it as a crate without writing a renderer for each platform.
Build a reusable component →For open-source maintainers
Inspect and change the framework you depend on.
Day’s framework and build tools are open source under MPL-2.0. If a platform bug blocks your app, you can trace it into the backend, test a fix locally, and contribute it upstream.
Browse the source →Read the license →Build something people can use.
Start with a working tutorial, then try the screen or platform feature your own app depends on.