Termy

I’m building Termy, a desktop language-learning app for Windows and macOS.

I wanted three things from its UI:

• A small, self-contained download

• An interface that belongs on each operating system

• Direct access to platform features

When I tested WinUI for Termy’s self-contained direct-download build, it added roughly 200 MB to the deployment. That was several times larger than I wanted the complete installer to be.

I also considered cross-platform frameworks. They save code, but their controls often feel slightly foreign on every operating system. You can fix that with platform-specific styling and behavior, but eventually you’re maintaining two interfaces inside one abstraction.

So Termy uses Swift and native Apple frameworks on macOS, and C++ with Win32, Direct2D, and DirectWrite on Windows.

The Windows controls eventually became a small framework called Slim UI. It started as shared code for the installer and settings. It now handles layout, controls, animations, DPI scaling, tooltips, keyboard input, and accessibility.

“Small” may no longer be the right word: it has grown to around 15,000 lines across 30 headers, with roughly 150 regression tests.

The tradeoff worked for Termy. Its compressed Windows installer is currently about 41 MB, including local OCR models and the rest of the application. The UI needs no separate third-party runtime, and I can integrate it directly with Termy’s overlays and other Windows-specific behavior.

But I definitely didn’t save development time. I traded development time for control over binary size, resource use, rendering, and platform integration.