# NAppGUI and the stack of a native desktop UI written in C > NAppGUI is a C SDK for cross-platform desktop applications, wrapping GTK3, Win32 with GDI+, Cocoa with Quartz and Cairo behind one API, and shipping a demo folder with twenty sample programs. The interesting part is that it is a thin layer over each platform's native toolkit rather than a single rendering model, which is both its strength and its limit. **frang75/nappgui_src** — SDK for building cross-platform desktop apps in ANSI-C - Repository: https://github.com/frang75/nappgui_src - Website: https://www.nappgui.com - Stars: 713 · Forks: 70 - Language: C - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/frang75-nappgui-src ## What sits under the API on each platform NAppGUI is described as a cross-platform C SDK for building portable desktop applications for Windows, macOS and Linux, using just C. The repository topics name the stack: gtk3, win32, gdi-plus, quartz, cocoa and cairo. That list is the honest summary of the design. The library is a layer over each platform's own toolkit rather than a single renderer it ships itself. On Linux the underlying GUI toolkit is GTK3, on Windows it is Win32 with GDI+, and on macOS it is Cocoa with Quartz, with Cairo present in the stack as well. This has a direct consequence for what portability means in practice. A button drawn through NAppGUI on Linux is a GTK button, and on Windows it is a Win32 control, so the widgets look native on both rather than looking identical on both. The documentation has a dedicated page on portability, and a separate quick start guide, which suggests the answer to how things behave across platforms is written down somewhere beyond the README. The C constraint is what makes this library unusual. There is no C++ runtime to depend on, no object model to learn, and the whole thing is driven by CMake. For an existing C project, that is a much smaller integration than adopting a C++ GUI framework would be. ## The demo folder is the real API documentation The repository's demo directory lists twenty sample programs, and reading them is the fastest way to understand what the SDK covers. There is die, dice, casino and bricks, which are graphics and animation samples. drawhello, drawimg, drawbig, colorview and fractals cover drawing primitives, images and colour. hello and hellocpp are the minimal cases, with the C++ variant there to show the C API being called from C++. guihello and glhello cover widgets and OpenGL, and col2dhello covers the 2D drawing context. Then the ones that show the SDK doing work beyond pixels: stlcmp for standard library containers, htjson for JSON handling, urlimg for URLs and images, webhello for the WebView, and bode, which is a signal analysis example. Two of these names carry a lot of information. webhello and the Linux dependency on libwebkit2gtk-4.1-dev tell you that the WebView is a first-class feature rather than an afterthought, and the presence of htjson tells you the SDK has its own data-handling story rather than making you find a JSON library. The naming convention is worth noting too. Each demo has its own folder with a matching prj directory structure, and the prj directory at the repository root suggests there is a project template for creating a new application, which the documentation links to as a separate guide. ## Building on Linux and what the dependencies reveal The Linux quick start shows the dependency list explicitly, and it is the best inventory of what the SDK can do. The development tools are build-essential, git and cmake. The development libraries are the informative part: libgtk-3-dev for the GUI toolkit, libcurl4-openssl-dev for HTTP support, libwebkit2gtk-4.1-dev for WebView support, and the Mesa packages for OpenGL support. So HTTP and WebView are optional capabilities you opt into by installing a library, not things that always work. The build then follows the standard CMake two-step: ```bash git clone --depth 1 https://github.com/frang75/nappgui_src.git cd nappgui_src cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug cmake --build build -j 4 ``` The built examples land in a bin directory under the build tree: ```bash ./build/Debug/bin/Die ./build/Debug/bin/Bricks ./build/Debug/bin/Products ./build/Debug/bin/Col2dHello ./build/Debug/bin/GuiHello ``` Note that the executable names match the demo folder names, and that the Debug directory appears even though the build type was set through the cmake variable rather than a multi-config generator. The parallel build flag is a plain job count. ## Windows and macOS differ in one line each The Windows and macOS quick starts are the same three steps with two differences, and the differences are informative. On Windows the prerequisites are Visual Studio and CMake, and the build uses a config flag rather than a build type variable: ```bash git clone --depth 1 https://github.com/frang75/nappgui_src.git cd nappgui_src cmake -S . -B build cmake --build build --config Debug ``` The examples are then launched as Windows executables: ```bash .\build\Debug\bin\Die.exe .\build\Debug\bin\Bricks.exe .\build\Debug\bin\Products.exe ``` On macOS the prerequisite is Xcode, and the generator is selected with -G Xcode: ```bash git clone --depth 1 https://github.com/frang75/nappgui_src.git cd nappgui_src cmake -G Xcode -S . -B build cmake --build build --config Debug ``` On macOS the demo is a bundle, so you run the binary inside the .app directory: ```bash ./build/Debug/bin/Die.app/Contents/MacOS/Die ./build/Debug/bin/Bricks.app/Contents/MacOS/Bricks ``` The macOS .app bundle layout is what you would expect from a Cocoa application, which is a good sign that the library is using the platform properly rather than emulating it. The Windows path is the flat executable, again matching the platform convention. ## Where the abstraction leaks, and what the SDK will not give you A wrapper over three different toolkits has a predictable failure mode: the features that map cleanly are excellent, and the ones that do not are either absent or behave differently per platform. The Linux dependency list shows the shape of the problem. GTK3, Win32 and Cocoa do not have the same widget set, the same font handling, or the same notion of a menu. Anything in the SDK that has to be implemented per platform is a place where behaviour can diverge, and the fact that the documentation has an entire page on portability suggests the authors know it. There is also a scope question worth being clear about. This is a GUI SDK, not an application framework. The repository layout is src for the library, demo for the samples, prj for project templates, tools for tooling, plus CMakeLists.txt, CMakeTargets.cmake and a Changelog.md at the root. There is no sign of a build-pipeline layer, a plugin system, a data-binding layer, or a network service framework. The features you get are the ones the underlying toolkits give you, wrapped. The absence of a stated minimum compiler version or a list of supported C standards in the README is worth noting too. The project does publish a Changelog.md and the .clang-format file at the root, which tells you the code style is enforced, but the README is not where you will find the platform support matrix. That belongs in the documentation site. ## Release cadence and what the version number buys you The repository is not archived and the last push was on 2026-10-16, days before the most recent release, so work is current. The tagged releases are NAppGUI v1.6.3 from 2026-10-01, v1.6.2 from 2026-07-02 and v1.6.1 from 2026-04-02. That is roughly one release per quarter, which for a native toolkit is a sensible pace: the underlying platforms change slowly enough that quarterly maintenance is reasonable, and a project like this does not need to move weekly. The version numbering is worth reading carefully because the 1.x line does not promise a stable API in the way a semantic version number usually does. A minor bump in a GUI SDK of this kind often means new widgets or new platform capabilities appeared, and a patch bump frequently means a build fix for one platform. The Changelog.md at the repository root is where that is recorded, and it is the file to read before upgrading rather than after. The licence is MIT, which places no conditions on commercial use and no copyleft obligation on code that links against the library. That matters for a GUI SDK specifically, since a licence that required you to publish your application's source would make it unusable for closed-source desktop software, and MIT does not do that. No legal advice is offered here beyond naming the identifier. ## Conclusion NAppGUI is a good fit for a team that wants a native-looking desktop application in plain C, or for a C codebase that needs to add a window, a table or an OpenGL view without pulling in a C++ toolkit, since the demo folder doubles as a reference for every subsystem. It is the wrong choice if you need one identical rendering model on all three platforms, because the library sits on top of GTK3, Win32 and Cocoa rather than replacing them. Before adopting, build the demo folder on your target platform to see which subsystems are usable there, and read the portability documentation, because a feature that behaves one way on GTK3 may behave differently on Win32. ## FAQ ### How do I build NAppGUI on Linux? Install the development tools and libraries, including libgtk-3-dev, libcurl4-openssl-dev, libwebkit2gtk-4.1-dev and the Mesa packages, then clone the repository and run cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug followed by cmake --build build -j 4. The example programs are then in the build/Debug/bin directory. ### What GUI toolkits does NAppGUI sit on top of? The library wraps the native toolkits of each platform: GTK3 on Linux, Win32 with GDI+ on Windows, and Cocoa with Quartz on macOS, with Cairo also in the stack. The project topics list gtk3, win32, gdi-plus, quartz, cocoa and cairo. ### Does NAppGUI support WebView and HTTP? Yes, as optional capabilities. On Linux the WebView support comes from libwebkit2gtk-4.1-dev and HTTP support from libcurl4-openssl-dev, and the demo folder includes a webhello example and a urlimg example for URLs and images. ### How often is NAppGUI released? Roughly quarterly. The recent tags are v1.6.3 from 2026-10-01, v1.6.2 from 2026-07-02 and v1.6.1 from 2026-04-02, and the repository was last pushed on 2026-10-16. The Changelog.md in the repository root records what changed. ## Sources - [frang75/nappgui_src on GitHub](https://github.com/frang75/nappgui_src) - [License: MIT](https://github.com/frang75/nappgui_src/blob/main/LICENSE) - [Project website](https://www.nappgui.com) - [README](https://github.com/frang75/nappgui_src/blob/main/README.md) - [Releases](https://github.com/frang75/nappgui_src/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/frang75-nappgui-src