xtd: a .NET shaped C++ framework for forms, console and unit tests

The API is deliberately .NET, not idiomatic C++

xtd is pronounced extend, and the name says what it does. The framework is a collection of native C++ class libraries meant to extend std, and the API is described as close to the .NET API with a modern C++ approach and full integration with the standard library. That is the central design decision and it cuts both ways. For a team with .NET muscle memory or with .NET code to port, the value is immediate: a familiar set of types, familiar naming, familiar idioms, expressed in C++ with RAII and value semantics rather than garbage collection. For a team that wants idiomatic modern C++, the framework is deliberately the other thing, an alternative vocabulary layered over the standard library rather than a replacement for it. The features list states the intent plainly, with a collection of native C++ classes libraries to extend std, an API close to .net, and code written in efficient modern C++20/23 with the RAII programming idiom. The project maintains a reference guide, a wiki, a Discord channel and a website, and the repository carries a Doxyfile, a .codedocs configuration and a .cppcheck configuration, so the documentation and static analysis are part of the project rather than an afterthought.

Four libraries, each with a job

The architecture is a layered set of four libraries, and the documentation shows them as an onion diagram. xtd.core is the foundation, modern C++20/23 libraries of classes, interfaces and value types that provide access to system functionality, and it is what the applications, components and controls are built on. xtd.drawing sits above it and contains types supporting basic GDI+ graphics functionality, with child namespaces for advanced two dimensional and vector graphics, advanced imaging, and print related and typographical services, plus a namespace that extends design time user interface logic and drawing. xtd.forms is the GUI layer, classes for creating applications that take advantage of the rich user interface features of Windows, macOS and Linux based operating systems. xtd.tunit is the test framework, a unit testing framework for modern C++20 inspired by Microsoft.VisualStudio.TestTools.Cpp. The forms layer is where the project makes a distinctive choice, because the documentation says xtd is designed to manage GUI controls and dialogs in pure native mode or with CSS styles. The style sheet option is unusual for a C++ framework and is the feature that separates it from a straight WinForms clone, since a control can be styled with CSS rather than only through platform look and feel.

Writing a console app and a test in the same style

The framework covers three application shapes, and the examples directory is organised by library, with separate trees for xtd.core.examples, xtd.drawing.examples, xtd.forms.examples and xtd.tunit.examples, each with its own CMakeLists.txt and a .cppcheck file. That layout is a practical hint about how the project is built, since everything is CMake driven, and the top level CMakeLists.txt is the entry point for the whole thing. A console application and its test suite therefore live in the same idiom, which is the practical payoff of the .NET shaped API: the test framework is not a separate world with its own conventions, it is the same style as the code under test. The project also ships a console application of its own, since the xtd.tunit library has its own test runner, and the repository has a tests/ directory at the top level for the framework's own tests, with codecov configuration for coverage reporting. The examples tree is documented separately in its own README, which is the fastest way to see working code for each library before committing to the framework.

Portability is a claim with a documentation page behind it

The platform list is long, and it covers Windows, macOS, Linux, iOS, Android, FreeBSD, Haiku and SerenityOS. The README links each platform badge to a portability page in the documentation rather than asserting the support in the README itself, which is the right way to do it, since a platform name on a badge is a claim and a portability page is evidence. The claim is plausible for the console and core layers, since those are ordinary standard library plus platform code. The forms layer is the harder case, because a native GUI with a consistent API across eight operating systems means either per platform backends or a compatibility layer over each platform toolkit, and the documentation describes the forms library as taking full advantage of the rich user interface features available in Microsoft Windows, Apple macOS and Linux based operating systems. The mobile platforms and the two BSD and hobby operating systems at the end of the list are where a forms back end is least likely to be complete, so the portability page is the document to read for a specific target rather than the badge list. The repository also carries install and uninstall scripts at the top level, with install for Unix like systems and install.cmd for Windows, alongside an uninstall and uninstall.cmd, and a locale/ directory and a themes/ directory for the style sheets and translations.

Releases are still beta, and 1.0.0 has a C++20 requirement

The release history is short and marked as beta throughout. v0.1.0-beta was tagged on 2021-10-09, v0.1.1-beta on 2023-07-17 and v0.1.2-beta on 2024-03-12, and the last push to master was on 2026-10-19. So the most recent tagged artifact is more than two years older than the branch tip, and the version numbers make the maturity level unambiguous. The news entries on the project site give the roadmap. A post from 2023-11-12 describes the 1.0.0 as growing, a post from 2024-03-12 announces the 0.1.2 beta release, and a post from 2025-06-15 states that xtd 1.0.0 will require C++20 as the minimum standard. That last one is a change in kind rather than degree, because the earlier betas could be built with the compilers of their era and now the floor moves. For a team considering the framework, the practical reading is that master is where the work is and no stable release exists yet, so the version you adopt is a moving target unless you pin a commit. The licence is MIT, so nothing in the terms stands in the way of using it, and the repository carries the usual governance files with AUTHORS.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md.

Where xtd is the wrong choice

The first and bluntest case is a team that wants idiomatic modern C++ with the standard library as the vocabulary. xtd exists to offer a .NET shaped alternative, so adopting it means accepting a second idiom alongside std, with two ways to express string handling, collections, threading and file access, and a learning curve on top of the standard library rather than instead of it. That is a fine trade for a port or for a .NET experienced team and a poor one for a team that already has working modern C++ conventions. The second case is a project that needs a stable, supported release, because there is no 1.0.0 and the newest tag is a beta from 2024, so the upgrade path is the master branch and the API can change under you. The third case is a team that needs the forms layer on a platform at the far end of the list, where the portability page is likely to be less optimistic than the badge, and a console only project gains nothing from carrying the whole framework. The fourth is licensing of a different kind, in the sense of ecosystem. The framework is native C++ with no runtime dependency and the MIT licence is permissive, but the community around it is small compared with the established cross platform C++ toolkits, so the practical cost is that answers, examples and third party extensions are scarce. The fifth is the C++20 requirement that 1.0.0 will impose, which is a real constraint for a team still on C++17 toolchains because the whole framework is written in the newer standard.

Editorial conclusion

xtd suits a C++ team that wants to port.NET style code, or that needs a forms and unit testing layer without writing its own, on a platform where no such layer exists. It does not suit a project that wants idiomatic modern C++ with the standard library as the primary idiom, since the whole point is to extend std with a.NET shaped API, and it does not suit a production release yet, because the published releases are all beta and 1.0.0 has not shipped. Before you depend on it, read the news entry about 1.0.0 requiring C++20 as the minimum standard, check the portability page for the platform you target, and note that the last push was on 2026-10-19 while the newest tagged release is v0.1.2-beta from 2024-03-12.

Frequently asked questions

Official sources

1. gammasoft71/xtd on GitHub
2. License: MIT
3. Project website
4. README
5. Releases