# AUI: a declarative C++20 toolkit that imports itself over CMake

> AUI is a module based C++20 framework for hardware accelerated desktop applications, with a declarative UI layer written in ordinary C++ and a dependency import step driven by aui.boot. It is still iterating through 8.0.0 release candidates, and the README's own example pins an older candidate than the newest tag.

**aui-framework/aui** — Declarative UI toolkit for modern C++20

- Repository: https://github.com/aui-framework/aui
- Stars: 603 · Forks: 44
- Language: C++
- License: MPL-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/aui-framework-aui

## A Qt alternative written in plain C++20

AUI, the Advanced Universal Interface, describes itself as a cross platform, module based framework for developing and deploying hardware accelerated graphical desktop applications using modern C++20. The topics it carries include cmake, opengl, cross-platform-gui and gui-toolkit.

The positioning line that matters is the second paragraph of the README. The project is inspired by Qt and aims to give developers a comparable experience across dependency management, packaging, UI building, styling and debugger visualizing, but with pure C++, without custom programming languages and external compilers. That is the whole bet. A toolkit that asks you to write your UI in a language the compiler does not understand, or that requires its own compiler in your toolchain, imposes a cost that shows up in hiring, in CI and in every debugging session. AUI removes that cost by staying inside standard C++.

The framework is opinionated about what a GUI application needs. The key feature list covers extended common types, the declarative UI tooling, a resource compiler for assets, internationalization, DPI support, CMake deployment scripts, model binding, encryption, IO streams, networking with http(s) requests, and support for both asynchronous and synchronous application architectures.

## Linux builds start with a long apt line

Before any CMake work, the Linux system needs its libraries. The README gives separate commands for Debian and Ubuntu, and for Fedora.

```bash
sudo apt update
sudo apt install pkg-config libglew-dev zlib1g-dev libssl-dev libcurl4-openssl-dev libgtk-3-dev libdbus-1-dev libfontconfig-dev ninja-build libpulse-dev git cmake g++ libxcursor-dev libxi-dev libxrandr-dev libstdc++-static libpulse-dev libdbus-1-dev libepoxy-dev
```

```bash
sudo dnf install fontconfig-devel libXi libglvnd-devel libstdc++-static glew-devel pulseaudio-libs-devel libepoxy-devel
```

Two things in those lines are worth noticing. The GLEW, Epoxy and OpenGL related packages point at the hardware accelerated rendering path, and the PulseAudio and Fontconfig packages point at the desktop integration side. The GTK 3 development package appears on Debian and Ubuntu, which is a reminder that a cross platform toolkit still inherits platform conventions.

The repository itself is not just a library directory. It carries a .clang-format and a .clang-tidy configuration, CMakePresets.json, a CMakeLists.txt, a conanfile.py, a pixi.toml, gdb.py and lldb.py for debugger integration, and valgrind_suppressions.supp, so the project expects to be inspected with debuggers and checked with sanitising tools rather than only compiled.

## aui.boot imports the framework into an existing project

The integration story is one download and one CMake function. You fetch the boot script once.

```bash
curl https://raw.githubusercontent.com/aui-framework/aui/refs/heads/master/aui.boot.cmake -o aui.boot.cmake
```

Then you include it in your CMakeLists.txt and declare which components you want. The README states that this script is self sufficient and does not require additional setup, because AUI is imported through AUI.Boot.

```cmake
cmake_minimum_required(VERSION 3.16)
project(aui_app)

include(aui.boot.cmake)
set(AUI_VERSION v8.0.0-rc.21)

# import AUI
auib_import(aui https://github.com/aui-framework/aui
        COMPONENTS core views
        VERSION ${AUI_VERSION})
```

The executable and the link step follow, and aui_executable creates the CMake target and places the resulting executable in the bin/ folder.

```cmake
# Create the executable. This function automatically links all sources from the src/ folder,
# creates CMake target and places the resulting executable to bin/ folder.
aui_executable(${PROJECT_NAME})

# Link required libs
aui_link(${PROJECT_NAME} PRIVATE aui::core aui::views)
```

Note that the version the README pins, v8.0.0-rc.21, is not the newest published tag. The release list shows v8.0.0-rc.33 dated 2026-10-14, with rc.32 on 2026-10-02 and rc.31 on 2026-09-29. Pinning a candidate is reasonable, but pin deliberately.

## The declarative UI is compiled C++ expressions

There is no markup language and no designer file. The window and its contents are ordinary C++ expressions in a namespace called declarative, and the entry point is a macro called AUI_ENTRY that takes a block.

```cpp
AUI_ENTRY {
    auto w = _new<AWindow>("Window title", 300_dp, 200_dp);
    w->setContents(Centered {
      Vertical {
        Centered { Label { "Hello world from AUI!" } },
        Centered {
          Button { "Visit GitHub page" }.clicked(w, [] {
              APlatform::openUrl("https://github.com/aui-framework/aui");
          }),
        },
      },
    });
    w->show();
    return 0;
}
```

The composition reads like markup: Centered wraps a Vertical, the Vertical holds a Label and a Button, and the Button takes a click handler as a lambda that opens a URL through APlatform. Sizes use a dp suffix, so the window is declared as 300_dp by 200_dp.

The headers the README includes for that file show the shape of the API: AUI/Platform/Entry.h, AUI/Platform/AWindow.h, AUI/Util/UIBuildingHelpers.h, AUI/View/ALabel.h, AUI/View/AButton.h and AUI/Platform/APlatform.h. AUI.Platform is where windowing and platform services live, AUI.View holds the widgets and AUI.Util the helpers that make the expressions work.

## Modules split the toolkit by capability

The module list in the README is small and deliberate. aui.core holds the basic types, containers, strings and streams. aui.crypt is a wrapper around OpenSSL for encryption, aui.curl a wrapper around libcurl for http and https requests, aui.image a loader for popular image formats, aui.json a JSON parser and aui.xml an XML parser. aui.network is the networking module, aui.toolbox the resource compiler, aui.uitests the UI testing layer built on GTest, and aui.views the UI toolkit itself.

The repository tree tells you that this list is not the whole story. Alongside the documented modules there are aui.audio/, aui.data/, aui.mysql/, aui.remote_tools/, aui.sqlite/ and aui.updater/ directories, so the codebase carries more capability than the module table documents.

The distinction between the documented modules and the extra directories matters for a reader building a dependency list. The auib_import call in the README asks for COMPONENTS core views, and the link step names aui::core and aui::views, so a minimal application imports two targets. Pulling in aui.crypt means OpenSSL in your build, aui.curl means libcurl, and aui.uitests means a GoogleTest dependency.

## The support table marks where the implementation is naive

The feature support table is the most honest part of the README, and it should be read before any of the rest. The legend explains the symbols: a blank means the feature is unusable on that platform, a minus means unsupported, a question mark means planned, a plus means there is a naive implementation that may contain issues, and a hash means fully supported.

Against that legend, the picture is uneven. aui.core, aui.crypt, aui.curl, aui.image, aui.json, aui.xml, assets, app packaging and HiDPI are marked fully supported on Windows Vista or later, Linux, macOS and iOS, while filesystem is only naively implemented on macOS and iOS and AUI Devtools is unsupported on iOS. aui.network is fully supported on Windows and Linux but only naive on macOS and iOS. aui.toolbox has no Android or iOS entry at all, and prebuilt binaries are unsupported on Windows XP and only planned on Android, macOS and iOS.

The row that should stop a careful adopter is aui.views, the UI toolkit itself. It is fully supported on Windows Vista and later, planned rather than implemented on Windows XP, and marked as a naive implementation on Linux, Android, macOS and iOS. The framework's headline feature is the one with the weakest guarantee outside Windows, which is not what most desktop framework comparisons look like.

## Templates, release candidates and the MPL-2.0 licence

Getting started does not require writing a CMake file by hand. The README points at three templates: a Minimal UI example described as an absolute minimum to start a graphical UI application without any boilerplate, a Minimal UI with assets example, and a full fledged App Template for creating a GitHub hosted app project with CI and CD building, testing, releasing, auto updating and code quality checking.

The release cadence is worth reading as a signal. The three most recent tags are v8.0.0-rc.31 on 2026-09-29, v8.0.0-rc.32 on 2026-10-02 and v8.0.0-rc.33 on 2026-10-14, so the 8.0.0 line is still in release candidate form and moving quickly, with the last push on 2026-10-22. There is no stable 8.0.0 in the list to point at, which means a team depending on it should expect to track candidates and rebase their pin.

The licence is MPL-2.0, and the repository root carries a LICENSE file. MPL-2.0 is a file level copyleft licence, so the practical question for a team is whether modifications to the framework files themselves, as opposed to your own application code, need to be published when you ship. That is a question for whoever handles licensing at your organisation, not something this article can answer, and the answer also depends on how you link the modules in.

## Conclusion

AUI fits a team writing a hardware accelerated desktop application in modern C++ who wants a declarative UI layer and a dependency import step, and who can accept a framework that is still publishing release candidates. It does not fit a project that needs Windows XP support or prebuilt binaries on Android, and the support table marks aui.views as only naively implemented on Linux, macOS and mobile. Verify first that the candidate you pin matches the one you develop against, because the README example still references v8.0.0-rc.21 while the newest published tag is v8.0.0-rc.33.

## FAQ

### How do I add AUI to an existing CMake project?

Download aui.boot.cmake once with curl, include it in your CMakeLists.txt, then call auib_import with the components you need and the version you want. The README states the script is self sufficient and requires no additional setup.

### Which AUI module provides HTTP and HTTPS requests?

aui.curl, which the README describes as a wrapper around libcurl for http and https requests. Encryption comes from aui.crypt, a wrapper around OpenSSL.

### Does AUI support UI testing?

Yes. The module list includes aui.uitests, described as UI testing based on GTest, and the AUI Devtools feature is listed in the platform support table.

### Which platforms is the AUI UI toolkit fully supported on?

In the feature support table, aui.views is marked fully supported on Windows Vista and later, planned on Windows XP, and marked as having a naive implementation on Linux, Android, macOS and iOS.

## Sources

- [aui-framework/aui on GitHub](https://github.com/aui-framework/aui)
- [Issues](https://github.com/aui-framework/aui/issues)
- [License: MPL-2.0](https://github.com/aui-framework/aui/blob/master/LICENSE)
- [README](https://github.com/aui-framework/aui/blob/master/README.md)
- [Releases](https://github.com/aui-framework/aui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aui-framework-aui