wry puts the platform webview into a window you already own, and splits Linux in two

wry creates a webview inside a window you already own

wry is a Rust library that puts a webview inside a window handle you already have. It does not create windows and it does not run an application lifecycle. The README is explicit about the caller side of the contract: the webview requires a running event loop and a window type that implements HasWindowHandle, or a gtk container widget if you need to support X11 and Wayland. Making windows is the job of a windowing library such as tao or winit. That division is why wry belongs under Tauri rather than beside it. Tauri is the framework that builds the shell, wry is the piece that hands that shell a browser view. The first sample in the README shows the whole shape of what you write yourself: an ApplicationHandler whose resumed callback creates a window through the event loop, then builds a webview with WebViewBuilder::new(), with_url and build, and stores both on your state struct. Nothing in that block is scaffolding the library insists on, so it also serves as the order of operations.

Two default features decide which engine gets compiled in

What gets built is settled by two default features, os-webview and x11. os-webview is the platform engine, and on Linux it pulls in javascriptcore-rs pinned to 1.1.2 with the v2_28 feature, webkit2gtk and webkit2gtk-sys pinned to 2.0.2 with v2_38, gtk 0.18 and soup3 0.5. The x11 feature adds x11-dl, gdkx11 and tao/x11. A third feature, linux-body, asks for webkit2gtk's v2_40 feature, so anything built on that flag needs a newer web engine than the default path does. The manifest also fixes the toolchain floor at rust-version 1.85 and writes the source in edition 2024. docs.rs is configured separately, with no-default-features and only the os-webview feature across x86_64-unknown-linux-gnu, x86_64-pc-windows-msvc and x86_64-apple-darwin, which means the hosted documentation describes a narrower build than a plain dependency entry gives you.

On Linux the GTK path is the price of X11 and Wayland together

Linux is where wry's platform surface forks. WebKitGTK provides the webview there, and it needs GTK. When the windowing library does not support GTK, and the README names winit as an example, you must call gtk::init before creating the webview and then call gtk::main_iteration_do alongside your windowing library's event loop. The Linux sample carries an inline comment marking that event loop advance as the important line. Supporting X11 and Wayland at the same time takes a different route. The README recommends WebViewBuilderExtUnix::build_gtk on Linux, and for a child webview on both protocols it points at WebViewExtUnix::new_gtk or build_gtk with gtk::Fixed. More setup, both display servers, and a GTK dependency in the build graph whether or not the windowing library had one.

A first build is a web engine package, then a compile

Building wry means installing the web engine first, because the packages are named per distribution. On Debian or Ubuntu:

sudo apt install libwebkit2gtk-4.1-dev

On Arch Linux or Manjaro:

sudo pacman -S webkit2gtk-4.1

On Fedora:

sudo dnf install gtk3-devel webkit2gtk4.1-devel

The Nix and Guix routes are reproducible shells rather than one-liners. The Nix example is a shell.nix that imports the nixpkgs-unstable channel and puts pkg-config and webkitgtk_4_1 in buildInputs, entered with `nix-shell shell.nix`. The Guix example is a manifest.scm listing "pkg-config" and "webkitgtk", entered with `guix shell -m manifest.scm`. With the engine present, the shortest complete first run in the README is the tao sample:

let event_loop = EventLoop::new();
let window = WindowBuilder::new().build(&event_loop).unwrap();

let builder = WebViewBuilder::new().with_url("https://tauri.app");

#[cfg(not(target_os = "linux"))]
let webview = builder.build(&window).unwrap();
#[cfg(target_os = "linux")]
let webview = builder.build_gtk(window.gtk_window()).unwrap();

The two cfg branches are the whole platform story in eight lines. Off Linux you hand build a window reference, on Linux you hand build_gtk the GTK window.

winit or tao decides which Linux path you can take

Two windowing libraries are named in the README, and for this library they are not interchangeable. The winit example is described as supporting Windows, macOS, iOS, Android and Linux, with Linux marked X11 only. The tao sample exists for the remaining case, Wayland on Linux, reached through build_gtk and the GTK window. tao also adds a gtk::Box to the window by default, which the child webview sample uses through window.default_vbox() before packing a gtk::Fixed into it. The choice is not stylistic. winit gives you the widest platform list in the README and, on Linux, a window type that cannot satisfy the GTK requirement, so gtk::init and gtk::main_iteration_do move into your code. tao gives you the container handle wry asks for and ties the Linux build to GTK. The examples directory shows the same split in filenames: gtk_multiwebview.rs and gtk_opengl.rs sit beside winit.rs, with multiwebview.rs, multiwindow.rs, transparent.rs and permission_handler.rs covering the engine itself.

Android wants generated Kotlin in your repository

Android is the platform where wry asks you to change your project before it asks you to change your code. Three environment variables drive code generation. WRY_ANDROID_PACKAGE takes the reversed domain name plus the app name in snake_case, for example com.wry.example.wry_app. WRY_ANDROID_LIBRARY takes the Cargo lib name, so a lib called wry_app produces libwry_app.so. WRY_ANDROID_KOTLIN_FILES_OUT_DIR points at a path such as path/to/app/src/main/kotlin/com/wry/example, which is where the Kotlin files are written and therefore where your application has to pick them up. Two requirements sit on top of the variables: the main Android activity must inherit AppCompatActivity, preferably the generated WryActivity, and the Rust side must call wry::android_setup and the wry::android_binding! macro to set up the JNI functions WryActivity invokes. MOBILE.md sits at the repository root for this part of the project. The consequence is blunt: the crate alone does not produce an Android application, it generates host-language glue it expects you to keep.

macOS is native until osxcross, and Windows needs nothing

macOS is the platform the README treats as settled: WebKit is native there, so everything should be fine. The one documented failure is specific to cross-compiling. If you build for macOS with osxcross and hit a runtime panic reading Class with name WKWebViewConfiguration could not be found, the explanation offered is that WebKit.framework has not been linked, and the fix is an environment variable rather than code:

RUSTFLAGS="-l framework=WebKit" cargo build --target=x86_64-apple-darwin --release

A link-time mistake showing up as a runtime panic is the kind of thing worth having read in advance. Windows gets the shortest section in the README: the webview comes from WebView2, provided by Microsoft Edge Chromium, and wry supports Windows 7, 8, 10 and 11. No configuration is offered for it, and the feature list in Cargo.toml has no Windows entry either, which is the clearest sign that this platform is considered done. The difference in consequence is worth keeping straight: on Linux the README hands you package names and event loop calls, on macOS one linker flag, on Windows nothing at all.

Pinning matters because the web engine is a system library

Release cadence matters differently here than in a pure-Rust crate, because the engine underneath wry lives in the operating system rather than in the dependency graph. Three recent tags are wry v0.57.1 on 2026-10-23, wry v0.57.0 on 2026-09-08 and wry v0.56.1 on 2026-08-13, and the Cargo.toml in the tree sits at version 0.57.1. The last push to the repository is dated 2026-10-28, after that tag, and the default branch is dev rather than main, so work lands on a branch that carries no release name. Two practical consequences. Decide deliberately whether you track a tag or the default branch, because the features you depend on can differ. And keep the rust-version 1.85 floor in view when you pick a Rust toolchain. Licensing is the permissive dual Apache-2.0 OR MIT declared in the manifest, with LICENSE-APACHE, LICENSE-MIT and LICENSE.spdx at the root, and the authors field credits the Tauri Programme within The Commons Conservancy. SECURITY.md is the place a report goes; CHANGELOG.md and a .changes directory sit beside it.

Editorial conclusion

wry is the right dependency when you are writing a Rust application, want the platform's own webview inside a window you create, and are willing to own the GTK path on Linux. It is the wrong choice if you were expecting windows, menus or a bundler, because those come from tao or winit, or from Tauri, the framework this library was written for. Before you pin a version, check two things on the machine you ship from: that the web engine packages named for your distribution install cleanly at the 4.1 generation the examples assume, and whether your Linux target can use build_gtk if you need Wayland.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tauri-apps/wry on GitHub