LCUI: a C GUI library that borrows its development model from the web

What LCUI actually solves for a C developer

Writing a desktop GUI in C usually means binding to a platform toolkit and then writing the same layout code twice, once for Windows and once for Linux. LCUI takes a different route: it draws its own widgets instead of wrapping native controls, so a button looks and behaves the same on both platforms. The README lists cross-platform support for Windows and Linux, fully custom-drawn components, DPI awareness for high-resolution screens, and a built-in CSS engine.

The intended user is not someone who wants a thin wrapper over Win32 or GTK. It is someone who wants to describe a UI in CSS and JSX and have the result run as a native process. The README is direct about where this came from: the author moved into web front-end work, and the library consequently leans toward web front-end technology. That origin explains the feature list more than any abstract design goal does.

The architecture: a small core over a stack of internal libraries

LCUI is not one monolithic file. The repository splits into lib/ and src/. Under lib/ the README names yutil for data structures, pandagl for font management, text layout, image processing and rendering, css for the CSS parser and selector engine, ptk for message loops, window management, timers, worker threads and input methods, thread for cross-platform multithreading, ui-router for routing and navigation, worker for worker-thread communication, ui for component management, event queues, style computation and drawing, ui-xml for building components from XML, ui-cursor for cursor rendering, and ui-server for mapping components onto system windows.

The src/ tree is divided by concern: app for lifecycle, event and UI management, fonts for default font settings, settings for global switches, ui for UI and window management, widgets for the predefined components, and worker for asynchronous tasks. If you are evaluating the library before writing code, that layout is the fastest way to see how much machinery sits between your application and the window. The CSS engine is a real parser and selector engine in lib/css, not a styling convention layered on top of native widgets.

Installing LCUI and creating a first application

The README's Quick Start lists three prerequisites: Git to download the example project source, XMake as the build tool, and Node.js to run the LCUI command-line development tool. The CLI itself installs through npm, and project creation goes through the lcui create command. The README says to follow the prompts provided by the commands afterward.

npm install -g @lcui/cli
lcui create my-lcui-app

After the project exists, the README describes a second command, lcui build, which preprocesses configuration files inside the app directory and then generates the corresponding C source code and resource files. That generation step is the part worth understanding before you commit: the TypeScript and JSX files are inputs, and the C sources are outputs you build with XMake.

lcui build

The repository also ships examples you can build without the CLI, including examples/hello, examples/todolist, examples/fabric and examples/doc-viewer, alongside an examples/xmake.lua and an examples/xmake-requires.lock. The README links a tutorial that develops an image viewer, examples/kantu. If the CLI path gives you trouble, building examples/hello with XMake is the smaller first step, and the README does not document a rollback or uninstall procedure for the CLI.

Where LCUI is the wrong tool

The most concrete limitation is release maturity. The latest release listed is v3.0.0-alpha.0, published on 2025-01-10. Before that, v2.2.0 dates to 2021-06-01 and v2.1.0 to 2020-07-05. An alpha on the default develop branch is not the same as a frozen API, and the package.json version field reads 3.0.0-alpha.0, matching the tag.

Platform coverage is the second constraint. The README states Windows and Linux. macOS is not in that list, and nothing in the repository layout suggests a Cocoa or AppKit backend. If your product ships on macOS, this is not a substitute for a native toolkit.

The third issue is conceptual weight. LCUI renders its own components, which is what buys you identical appearance across platforms, but it also means you inherit its renderer, its font pipeline through pandagl, its input method handling through ptk, and its CSS subset. Developers who want native accessibility behavior, native file dialogs, or the platform's own text rendering will find custom drawing works against them. The README does not claim accessibility support, and none of the listed libraries covers it.

How LCUI differs from GuiLite and other small C GUI libraries

GuiLite is the closest comparison in the related searches, and the difference is the programming model rather than the footprint. GuiLite is a compact C/C++ GUI library aimed at embedding a UI into constrained environments. LCUI keeps a C core but puts a web-shaped toolchain in front of it: TypeScript with JSX through the LCUI React library, stylesheets written as Tailwind CSS, CSS Modules, Sass or plain global CSS, and a file-system based router where each directory under the app becomes a page route.

The README also mentions a user-friendly icon library sourced from microsoft/fluentui-system-icons with partial customization. So the comparison is not "small library versus large library". It is a C drawing layer with a JavaScript build step versus a C drawing layer you drive directly from C. If your team has no Node.js in its build pipeline, LCUI's headline workflow is the part you would be discarding, and at that point the CSS engine and the custom renderer are what remain.

Maintenance, licence and what a 3.0.0 alpha costs you

The repository is not archived, and the last push was on 2026-08-10, so work is happening. The gap between v2.2.0 in 2021 and v3.0.0-alpha.0 in 2025 is the number that matters for planning: this is a project with long stretches between releases, and the current line is pre-release. The CHANGELOG.md and CHANGELOG.zh-cn.md files at the repository root are where release history is tracked, and the README points to an RFC directory in the online documentation, which suggests API decisions are still open for discussion.

Licensing is MIT, stated in package.json and in LICENSE.TXT. MIT permits commercial and closed-source use with attribution and no warranty, which is the usual arrangement for a GUI library, but this is a description of the licence text, not legal advice for your product.

The upgrade cost is the real one. Because the CLI generates C source from TypeScript and JSX inputs, an API change in the runtime can invalidate generated code, and you may need to regenerate rather than patch. The repository pins toolchain expectations in xmake-requires.lock and examples/xmake-requires.lock; those lock files are what you would compare when moving between versions. There is also a debian/ directory, which indicates Debian packaging exists in-tree, though the README does not describe a distribution package as an install path.

What to check before you build on it

Read the online documentation at lcui-dev.github.io/docs/next/guides/base/ rather than the README alone, because the README stops at project creation and does not document the generated file layout, the C API surface, or what lcui build emits. The RFC section of that documentation is where you can see which parts of the API are settled.

Then build examples/hello with XMake and inspect the output. That tells you whether the generated C is something your team is willing to maintain, and whether the build works on your target platform without the CLI in the loop. The preview.png image in the repository root and the example screenshots (examples/kantu.jpg, examples/todolist.jpg, examples/browser.jpg, examples/fabric.jpg) show what the custom-drawn components look like before you invest in a prototype. If those screenshots do not match the visual quality your product needs, the CSS engine will not close the gap for you.

Editorial conclusion

LCUI fits developers who already think in CSS and JSX and want a small C runtime underneath, especially on Windows and Linux where its fully custom-drawn widgets keep the appearance identical. It is a poor fit if you need a stable API today, since the current release line is v3.0.0-alpha.0 from 2025-01-10, or if you need macOS, which the README does not list. Before committing, build the examples/hello project from the repository and confirm the lcui build step produces C source on your toolchain.

Frequently asked questions

Official sources

1. lc-soft/LCUI on GitHub
2. License: MIT
3. Project website
4. README
5. Releases