Targets
Every targetThe full list of platforms idealyst runs on, plus the path to teach it about a new one. If you can drive it from code, you can ship to it.
Phones
iOSUIKit driven via objc2. Native UIView hierarchy, native back gestures, native scroll physics. iOS 13+. The standard pattern for shipping an idealyst app to the App Store.
AndroidAndroid Views over JNI. Native View hierarchy, native FragmentManager, system back-button handling. API 24+. Same shape as iOS, different toolchain. Distributable via Play Store / sideload / closed beta.
Desktops
macOSAppKit via objc2. Native NSWindow + NSView hierarchy. Today: window shell, buttons, text, scroll. Animation + media still being filled in.
Windows (in progress)Win32 host. Evaluation in progress — the goal is the same "native widgets driven by the framework" shape that iOS and Android already have.
Linux (in progress)GTK host. Same goals as the Windows target. Both desktop targets share the wgpu render path as a fallback for surfaces the native toolkit can't reach.
Browsers
Web (WASM + DOM)Reference backend, most complete primitive coverage. Compiles to a WASM bundle (typically a few hundred KB gzipped) and mounts into a div. No JavaScript framework dependency — the app is the wasm.
Native GPU rendering
wgpu rendererA second-implementation backend that drives the framework over wgpu. Same Backend trait, but rendering goes through a GPU pipeline instead of a native toolkit. Useful when you want pixel-perfect control of the render output (custom widgets, novel visual styles, embedded devices with a GPU).
Phone / tablet / TV skinsPre-wired wgpu hosts that ship with iOS-sim and Android-sim skins so the wgpu output visually matches the native toolkit it would normally run against. Useful for development, screenshots, simulator-style demos.
Embedded & custom
Microcontrollers (planned)A CPU-based graphics backend targeting `embedded-graphics`-compatible devices: ESP32, Arduino with an LCD shield, Raspberry Pi Pico, etc. The same `app()` function compiles into a `no_std`-friendly binary that drives a tiny display.
Custom renderingIf your target is none of the above — a pixel buffer you draw yourself, a proprietary embedded surface, a server-side renderer — implement the Backend trait. There's no architectural assumption that the target has a windowing system or a GPU or anything else.
Terminal
Terminal (TTY)crossterm-backed text-cell renderer. The framework treats the terminal grid as a backend like any other — you write the same `ui!` tree and it paints into the cell buffer. Useful for CLI tools that want richer UI than a sequence of prompts.
Television
RokuBrightScript / SceneGraph transpile. The framework's `ui!` tree is rewritten into Roku's native scene format. Less polished than the mobile backends — theme switching is currently disabled pending a token-system refactor.
iOS TV / Android TVBoth iOS and Android have TV variant crates scaffolded. They share the primitive layer with their phone counterparts; the diff is layout defaults and the input model (focus + d-pad instead of touch). Phone targets are the priority right now, TV is a known follow-up.
Adding your own targetAdding a new target is implementing the Backend trait. A trait. One file's worth of contract.The trait surface is moderately large — one method per primitive (create / update / insert / remove), plus a handful of cross-cutting hooks (style apply, animated values, layout, refs). But it's a fixed surface; the framework doesn't ask the backend to know about routing, theming, components, or any higher-level concept. Get the primitive surface right and everything else just works.
Implementation statusPer-backend implementation status — which primitives work where, what's in progress, what's planned — lives on the Backends page.See the Backends matrix →
On this page
Phones
Desktops
Browsers
Native GPU rendering
Embedded & custom
Terminal
Television
Adding your own target
Implementation status
IdealystOne codebase, native everywhere.
© Idealyst 2026