Dear ImGui: a widget description you recompile into your build, not a UI you link against

Ten cpp files at the root, and no build system to install

Integration is a file copy. The core of Dear ImGui is self-contained in a handful of platform-agnostic files, and the instruction is to add every imgui*.cpp and imgui*.h from the repository root into an existing project. No specific build process is required, because there is no package to install and no tool to configure.

Concretely that means five translation units (imgui.cpp, imgui_draw.cpp, imgui_tables.cpp, imgui_widgets.cpp and imgui_demo.cpp), the public header imgui.h, an internal header imgui_internal.h, a configuration header called imconfig.h, and three bundled single-header libraries with stb in the name (imstb_rectpack.h, imstb_textedit.h, imstb_truetype.h). Nothing else at the root is needed at link time.

Your first widget looks like this, and the same calls work from anywhere in the program loop:

ImGui::Text("Hello, world %d", 123);
if (ImGui::Button("Save"))
    MySaveFunction();
ImGui::InputText("string", buf, IM_COUNTOF(buf));
ImGui::SliderFloat("float", &f, 0.0f, 1.0f);

Notice what is absent from that snippet: no handle, no pointer, no lifetime to manage. There is no widget object to keep alive, which is the point of the design and also the reason your UI code is your UI state. The price of the file copy is that upgrades are manual. There is no package manager to bump, so moving to a newer release means replacing files you may have edited..

You supply the renderer, which is where a custom backend takes its risk

The library emits optimized vertex buffers and command lists and leaves rendering entirely to you. The pitch puts it plainly: anywhere you can render textured triangles, you can render Dear ImGui. The core touches no graphics state and carries no graphics dependency, which is the reason it runs on console platforms where operating system features are non-standard.

Backends for a variety of graphics APIs live in backends/, and examples/ pairs those backends with complete applications. The example directory is effectively the compatibility list: GLFW against OpenGL, Vulkan, WebGPU and Metal, SDL2 and SDL3 against OpenGL, Vulkan, Metal, DirectX 11 and SDL_Renderer2, Apple against Metal and OpenGL, plus Allegro 5, Android, GLUT and QNX. There is also an example_null, which confirms the core can be exercised with no windowing system at all.

If none of those cover your renderer, the README says you may create your own backend. That is where the risk sits. A custom backend means you take on submitting the draw data to your renderer yourself, and the README leaves that work to you.

The pitch rules out end-user UI and names internationalization and accessibility as absent

Read the scope statement rather than the feature list. Dear ImGui is designed for content creation tools and visualization and debug tools, and the README puts it explicitly as opposed to UI for the average end-user. What it lacks is stated just as plainly: full internationalization, including right-to-left text, bidirectional text and text shaping, and accessibility features are not supported.

Those are not dormant plugins. There is no accessibility layer to switch on for part of your audience, and no locale mechanism waiting for a right-to-left language to arrive. The consequence is architectural rather than cosmetic. An internal tool for engineers never notices any of this. A product with end users in a right-to-left or bidirectional locale forces the decision before the first widget, because the interface you design against will not be the one you ship.

The same scoping choice explains the rest of the pitch: efficient runtime and memory consumption, portability onto consoles and phones, and support for both ad hoc short-lived tools and long-lived elaborate ones. Developer tooling is the design target, and the omissions follow from that target rather than from neglect. A team that reads the feature list without the scope paragraph will conclude the project is missing things it was never going to have.

The code between Begin and End is a description that runs again next frame

Everything about the paradigm follows from one property: your widget calls are not configuring a stored object, they are the description of one, and they execute again on the next frame. The README states the rationale in a line it attributes to ryg: give someone state and they will have a bug one day, but teach them to represent state in two locations that have to be kept in sync and they will have bugs for a lifetime.

The API is the argument. Here is a complete menu bar, and the only state involved is a boolean you already had:

ImGui::Begin("My First Tool", &my_tool_active, ImGuiWindowFlags_MenuBar);
if (ImGui::BeginMenuBar())
{
    if (ImGui::BeginMenu("File"))
    {
        ImGui::EndMenu();
    }
    ImGui::EndMenuBar();
}
ImGui::ColorEdit4("Color", my_color);

The payoff is a class of tool that would be absurd in a retained-mode library. Using the Edit&Continue hot code reload feature of modern compilers, you can add a few widgets to tweak variables while the application is running and delete the code a minute later. The README also points at tracing a running algorithm by emitting text commands, browsing your own reflection data live, exposing the internals of a subsystem, and building a logger, a profiler, a debugger or an entire editor framework. The same property is the hazard: any side effect placed inside a widget call fires once per frame..

v1.92.9b is a lettered build, and the branch is ahead of every tag

The newest release is v1.93.0, published 2026-10-14; before it came v1.92.9b on 2026-07-31, six days after v1.92.9 on 2026-07-25. The default branch is master, and the last push to it was on 2026-11-02.

Two consequences follow for anyone integrating by copying files. First, the letter is part of the version. A build script or version check written against a dotted-numeric pattern will reject 1.92.9b, or sort it out of order in a list of available releases, and you will spend an afternoon on a release that exists. Second, and more awkward, the newest tag (v1.93.0, 2026-10-14) is older than the branch head (last push 2026-11-02), so copying files from master is not the same act as installing a release.

The rule that follows is narrow. Take a tag, not the branch, and write the tag string into your own repository next to the copied files. Recording the tag next to the copied files saves you from having to work out which release your copy came from.

MIT is permissive, and the support request in the README is not a licence obligation

The licence is MIT, in a single LICENSE.txt at the root. The README sets a note above it saying the library is available under a free and permissive licence but needs financial support to sustain its continued improvements, and that there are many desirable features yet to be added.

Both support routes are spelled out. Businesses are asked to take invoiced sponsoring or support contracts, with an e-mail contact at dearimgui dot com; individuals are pointed at a PayPal link and a Funding page on the wiki. Nothing in the MIT terms obliges you to do either. Read the passage as a request that happens to have a commercial path attached, and notice that the commercial path is a contract with the author rather than a feature anyone can inspect.

What the passage does tell you is the shape of the project. The support routes are a contact e-mail address, a PayPal link and a Funding page, and the surrounding wiki collects pages for Useful Extensions, language bindings, and the software built with Dear ImGui. A permissive licence tells you what you may do with the code. It does not tell you who answers a question three years from now, and for a library you have copied into a product you ship, that is the part worth planning around.

C++20 module support lives in someone else's repository

Compiling the core means adding translation units to your build, which for a C++20 project means a build system that knows how to enumerate sources. The README routes module users elsewhere: C++20 users wishing to use a module may use the imgui-module third-party extension at stripe2933/imgui-module.

So there are two integration paths with different ongoing costs, and the project does not rank them. The core path costs a source list in your build files and a manual upgrade procedure, and it keeps you on code the author controls. The module path costs a dependency on a repository this project does not maintain, with its own release cadence, and it is the only one of the two that gives a C++20 project a module.

Choose based on how long you intend to own the integration. A tool you will delete next week should take the core files and never think about it again. A library you plan to keep for years deserves a deliberate decision about which of the two you are maintaining, because that decision determines who you file an issue against when the copy step stops working.

Editorial conclusion

Adopt Dear ImGui when the user is a developer looking at your program's internals, and decline it when the user is a customer who needs a screen reader, a right-to-left locale or bidirectional text, because the project states those are unsupported and there is no layer to add later. Take a release tag rather than the master branch, and record the tag string beside your copied files, since the newest tag is v1.93.0 from 2026-10-14 while the branch has moved since (last push 2026-11-02). If you are on C++20, decide now whether you are maintaining the core files or the third-party module, because that choice decides who you file an issue against when the copy step breaks.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes