winit

winit provides the foundational layer that almost every native Rust GUI toolkit and game engine builds on: creating OS windows, running the platform event loop, and delivering input events (keyboard, mouse, touch, resize, focus) through one unified EventLoop/Window API. It deliberately stops at window and event management — it does not draw anything to the window itself, leaving rendering to a separate graphics API (wgpu, OpenGL/glutin, Vulkan, or a 2D drawing library) layered on top of the raw window handle winit exposes.

The repository is a Cargo workspace split by platform backend — winit-win32, winit-x11, winit-wayland, winit-appkit (macOS), winit-uikit (iOS), winit-android, winit-web, winit-orbital — with winit-core and winit-common holding shared abstractions, and the top-level winit crate re-exporting the right backend per target. This design is what lets a single winit::Window call compile to native windowing code on Windows, macOS, Linux (X11/Wayland), iOS, Android, and WebAssembly. It is one of the most widely depended-upon crates in the Rust GUI/game ecosystem (used by wgpu-based renderers, egui, bevy, and many other projects) and is actively maintained by the rust-windowing organization.

What You Get

• EventLoop and Window types for creating and managing native windows across desktop, mobile, and web targets
• A unified input-event model covering keyboard, mouse, touch, resize, focus, and other window/OS events per platform
• Per-platform backend crates (winit-win32, winit-x11, winit-wayland, winit-appkit, winit-uikit, winit-android, winit-web, winit-orbital) hidden behind one top-level winit API
• Raw window/display handle access (raw-window-handle support) so external rendering libraries like wgpu, OpenGL/glutin, or Vulkan can draw into the window
• Optional serde and mint feature integrations for serializing event/window types and interop with math libraries

Common Use Cases

• Providing the window and input layer under a wgpu, OpenGL, or Vulkan-based renderer for a game or graphics application
• Building a native GUI toolkit or application framework (e.g. egui, iced) on top of winit’s window/event primitives
• Cross-compiling the same Rust application’s windowing code to desktop, mobile (iOS/Android), and WebAssembly targets
• Writing a minimal native application that needs a resizable window and keyboard/mouse input without a full GUI framework

Under The Hood

Architecture - The workspace splits shared abstractions (winit-core, winit-common) from per-platform backend crates (winit-win32, winit-x11, winit-wayland, winit-appkit, winit-uikit, winit-android, winit-web, winit-orbital), each implementing the same EventLoop/Window contract against native platform APIs (Win32, Xlib/XCB, Wayland protocols, AppKit, UIKit, NDK, and web Canvas/DOM events respectively); the top-level winit crate (winit/src/lib.rs, event_loop.rs, platform/, platform_impl/) conditionally re-exports the correct backend based on compile target.

Tech Stack - Pure Rust with per-platform system-API bindings (no C dependencies beyond what each OS API requires); MSRV is actively tracked (Rust 1.85 policy tied to Debian Sid/stable-3), and CI targets a wide matrix including Windows MSVC, macOS (Intel/ARM), Linux X11/Wayland, iOS, Android, and wasm32-unknown-unknown.

Code Quality - winit/tests/ covers thread-safety guarantees for event/window types (send_objects.rs, sync_object.rs) and serde round-tripping (serde_objects.rs); the project enforces clippy.toml/rustfmt.toml/typos.toml/deny.toml configs in CI, and maintains a CHANGELOG.md and FEATURES.md that document platform-support parity explicitly, reflecting the discipline needed to keep eight platform backends behaviorally consistent.

API Design - The single EventLoop/Window abstraction hides substantial per-platform complexity behind one API, and the crate explicitly scopes itself to windowing/events only (per the README, FEATURES.md, and “Are We GUI Yet” ecosystem docs) rather than drawing — keeping its surface small and composable with any rendering backend, at the cost of requiring users to bring their own graphics stack.