bevy_egui: Adding Egui Interfaces to Bevy Applications

Why bevy_egui Exists for Bevy Developers

Bevy provides an entity-component-system architecture, while Egui provides an immediate-mode interface toolkit. bevy_egui exists to connect those two models rather than asking developers to build every editor panel, settings window, or diagnostic control from lower-level UI primitives. It is intended for Rust developers working inside the Bevy game engine who need interactive interfaces alongside a Bevy application.

The README lists desktop and web platform support, clipboard handling, URL opening, multiple windows, split-screen layouts, paint callbacks, mobile web virtual keyboards, and AccessKit support. Those features place the crate between application state and user interaction. An application can register a Bevy system, open an Egui window, read input, and update game-related resources through ordinary Rust code. This is useful for tools and games where a permanent HUD is less suitable than an on-demand panel.

The crate does not replace Bevy's scene, entity, asset, input, or rendering systems. It provides an integration layer. That distinction matters when evaluating it: bevy_egui is not a standalone game UI editor, and it is not a separate visual design format. The application still owns its game logic and decides which Egui controls should affect that logic.

How bevy_egui Connects Egui to Bevy

The documented setup adds `EguiPlugin::default()` to a Bevy application. The example also creates a camera, schedules `ui_example_system` in `EguiPrimaryContextPass`, and passes `EguiContexts` into that system. The system obtains a context with `contexts.ctx_mut()`, then builds an Egui window and renders a label.

This arrangement shows the crate's basic data flow. Bevy schedules the system at an Egui-specific pass, the crate provides access to the relevant Egui context, and the system describes the interface for that frame. Since Egui is immediate mode, the system describes controls in code rather than building a retained widget hierarchy. The game state can then be read or changed from callbacks or control values, although the minimal README example only displays the word `world`.

The available examples expose more involved integrations. `two_windows.rs` assigns an Egui context to each window, `split_screen.rs` attaches multiple contexts to cameras targeting the same window, and `paint_callback.rs` demonstrates paint callbacks. `render_egui_to_image.rs` and `render_to_image_widget.rs` show two directions for combining Egui rendering with Bevy image or mesh materials. The feature list and Cargo features indicate that rendering, Bevy UI integration, picking, clipboard management, URL opening, default fonts, AccessKit, serialization, and logging are selectable pieces rather than one inseparable bundle.

The crate can also run Egui passes manually, as shown by `run_manually.rs`. That is a useful escape hatch when the default plugin schedule does not match an application's needs, but it also means pass ordering and context access can become application-level responsibilities.

Installing bevy_egui and Running the First Interface

The README presents Cargo as the installation path. On Linux, the crate also requires specific XCB development packages, so the system dependencies should be installed before building the project. The documented Debian-based command is:

sudo apt install libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev

After that, add `bevy` and `bevy_egui` to a Rust project's `Cargo.toml`. The README gives these dependency entries:

[dependencies]
bevy = "0.20.0"
bevy_egui = "0.43.1"

The following minimal Bevy application registers the plugin, creates a camera, and places a window containing a label into `EguiPrimaryContextPass`:

use bevy::prelude::*;
use bevy_egui::{EguiContexts, EguiPlugin, EguiPrimaryContextPass, egui};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(EguiPlugin::default())
        .add_systems(Startup, setup_camera_system)
        .add_systems(EguiPrimaryContextPass, ui_example_system)
        .run();
}

fn setup_camera_system(mut commands: Commands) {
    commands.spawn(Camera2d);
}

fn ui_example_system(mut contexts: EguiContexts) -> Result {
    egui::Window::new("Hello").show(contexts.ctx_mut()?, |ui| {
        ui.label("world");
    });
    Ok(())
}

A developer following the README should see a Bevy application with a camera and an Egui window titled `Hello`. To run the repository's basic example, use:

cargo run --example ui

The README says that `ui` can be replaced with another example name. It also links a live WASM page, but the README does not provide a separate build command for producing that web deployment.

Feature Flags and Platform Boundaries

The Cargo manifest makes the crate's dependency shape visible. The default feature set contains `manage_clipboard`, `open_url`, `default_fonts`, `render`, `bevy_ui`, and `picking`. Disabling defaults can therefore change much more than UI appearance. Rendering features pull in Bevy rendering and image, mesh, shader, asset, and color components. Clipboard support adds `arboard`, `thread_local`, `bytemuck`, and `smithay-clipboard`, while URL opening adds `webbrowser`. The `accesskit` feature maps to `bevy_a11y`, and `immutable_ctx` is also available.

This configuration is useful for controlling compile-time cost and platform behavior, but it creates a compatibility decision. The README documents desktop and web support without claiming that every feature works equally on every target. The mobile web virtual keyboard is explicitly described as rough and dependent on the `prevent_default_event_handling` setting in `WindowPlugin`. That is a concrete boundary for browser-based applications.

The repository manifest specifies Rust edition 2024 and `rust-version = "1.95.0"`. The examples have feature requirements in the manifest, so an application that disables rendering should not assume that all example targets are available. The README also points to a color rendering test and says the project does not fully pass it. That statement matters for teams evaluating pixel-level rendering compatibility.

Where bevy_egui Is the Wrong Choice

The clearest limitation is that this is an integration crate, not a complete application UI framework. If a project wants to author a large retained Bevy UI hierarchy entirely through Bevy-native resources and entities, this crate does not remove the need to understand those systems. It is also a poor fit when the target platform lacks the dependencies required by the selected features, or when a browser application cannot accept the documented virtual-keyboard constraint.

There is also a version boundary. The README's minimal example pairs `bevy_egui` v0.43.1 with Bevy 0.20.0. The repository metadata describes the crate as version 0.43.1 and lists Rust 1.95.0 as its minimum version. That makes this a version-sensitive integration for projects already on a different Bevy release. The README does not provide a broad compatibility table in the available content, so an engineer should not infer support for unrelated versions.

Rendering quality and behavior are not presented as universally identical across the full example set. The `color_test` example is specifically described as not fully passing, while `render_egui_to_image` requires the caller to connect rendered UI output to a texture or material. Applications with strict visual output requirements should inspect the relevant example and rendering path before deciding that the crate fits.

Alternatives and Maintenance Costs

The README lists `jakobhellermann/bevy-inspector-egui` as a related project. The stated difference is scope: bevy_egui provides a general Egui integration with examples for windows, split screens, paint callbacks, input absorption, and image rendering. An inspector-focused project may provide a narrower workflow for inspecting Bevy data, while this crate is the more general bridge described by its own examples. The README does not document a detailed feature comparison, so the relevant distinction here is the stated project purpose and the examples shipped by bevy_egui.

The repository is not archived, and its last push was on 2026-10-10. Release v0.43.1 was also published on 2026-10-10, following v0.43.0 and v0.43.0-rc.1 in the release list. That indicates recent project activity, but it does not establish compatibility with every Bevy release or eliminate upgrade work.

The crate uses the MIT license. The manifest also defines optional features and a Rust minimum version, so upgrades can involve dependency resolution, feature review, and changes to pass or input setup. The README does not document a migration guide for every release, nor does it specify a rollback procedure. The CHANGELOG file is present, so release-specific migration details should be read there.

Editorial conclusion

Adopt bevy_egui when a Bevy project needs an Egui interface and can accept the crate's rendering, input, platform, and version dependencies. Do not choose it for a project that requires a mature native Bevy UI flow without checking feature behavior first. Before adoption, verify the Bevy version, the selected Cargo features, Linux XCB packages, browser input configuration, and whether the intended example covers the required window and rendering setup. The repository's last push was on 2026-10-10 and release v0.43.1 was published on 2026-10-10, but the crate's feature boundaries remain more important than its release cadence.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vladbat00/bevy_egui on GitHub