Snow Apps: Snow Shot and Snow Image Viewer under one C++ monorepo

What Snow Apps actually contains

The repository is not one application. It is a workspace that produces two end-user programs, Snow Shot and Snow Image Viewer, plus the shared code they sit on. The top level shows the split: snow_shot/ and snow_image_viewer/ are the applications, snow_image/ is the image handling layer, and snow-crates/, snow_rust_ffi/ and snow_draw_engine_qt/ are supporting pieces. ant_design_qt/ is a Qt port of Ant Design. The README describes the repo as "providing source code for Snow Shot and Snow Image Viewer" and nothing more, so anyone expecting a product landing page with feature bullets will not find one here.

The audience is narrow and that is fine. This is for people who want to compile a screenshot and image-viewing toolset themselves, read how it is structured, or reuse the Apache-licensed libraries inside it. The topics list gives the intended capability set: screenshot, screen recorder, OCR, image viewer. Those are the four things the codebase is organised around, and they explain why an image layer, a draw engine and a Rust FFI crate all live in the same tree. If you only want a binary, the repository points you at snowshot.top instead.

How the C++, Rust and Qt layers fit together

The architecture is visible from the directory names rather than from the README, which does not include a diagram or an architecture section. What the layout supports is a reading: the Qt-facing applications in snow_shot/ and snow_image_viewer/ call into snow_image/ for image operations, into snow_draw_engine_qt/ for drawing and annotation, and across an FFI boundary into Rust through snow_rust_ffi/ and snow-crates/. The presence of rust-toolchain.toml and .cargo/ at the top level confirms the Rust side is pinned and built as part of the same workflow, not vendored as an opaque blob.

Dependency management is vcpkg: vcpkg.json and vcpkg-configuration.json sit at the root, with a cmake/ directory and CMakePresets.json driving configuration. That combination means the build is reproducible in the sense that the dependency set is declared in the repository, but it also means a first build pulls and compiles a vcpkg tree, which is the slowest part of getting started. The .clang-format, .clang-tidy and .editorconfig files indicate the C++ side is expected to be formatted and linted consistently, and AGENTS.md and .cursor/ suggest the maintainers also drive AI coding tools against the same conventions.

One thing the repository does not give you is a written data flow. There is no document explaining how a captured frame moves from the screen-capture layer through OCR and into the editor. You reconstruct that by reading snow_shot/ and snow_image/ directly. For a project at this stage that is acceptable, but it raises the cost of contributing a change that crosses the FFI boundary.

Building Snow Apps on macOS: the documented path

The README only documents one platform. It says to see the Snow Shot macOS build guide for prerequisites, Apple Silicon and Intel presets, shell scripts, targeted tests, and DMG packaging. That guide is docs-macos-build.md in the repository root. There is no equivalent Windows or Linux guide at the top level, so treat macOS as the supported build host.

That guide is the only build documentation the repository points at, and it is where the preset names, the shell scripts, the targeted test commands and the DMG packaging steps are written down. The README does not reproduce any of them, so the guide is the file to open before you configure anything. CMakePresets.json and the scripts/ directory are the files it works through, and test-support/ is where the test scaffolding lives.

Nothing in the README gives a command to copy, which is itself a signal about the project's stage. A build that is documented as a guide rather than as a short command sequence assumes you are comfortable reading CMake presets and shell scripts and adapting them to your machine. If you want a one-line install, this is not it yet.

Licence layout is the first thing to check

This is a multi-licence repository and the split does not fall where people usually expect. The shared, reusable parts are permissive: ant_design_qt/, snow-crates/, snow_draw_engine_qt/ and snow_rust_ffi/ are Apache License 2.0. The parts you would actually ship as an application are not: snow_image/, snow_image_viewer/ and snow_shot/ are GNU GPL v3.0 or later, with the terms in each directory's COPYRIGHT file.

The practical consequence is that lifting the screenshot application into a proprietary product is not something the licence permits without dealing with GPL obligations, while reusing the draw engine or the Rust crates is far less constrained. The README also states that synchronized and bundled third-party materials retain their upstream licences, and points at ant_design_qt/THIRD_PARTY_NOTICES.md and snow_shot/THIRD_PARTY_NOTICES.md. Those notices are where a compliance review should start, because a GPL application that bundles permissively licensed third-party code still has to satisfy both sets of terms. The README does not resolve questions about which files fall under which scope; it defers that to LICENSE.md, which is the document to read in full. Nothing here is legal advice, and the repository's own scope rules are the authority.

Beta releases and what they mean for adoption

Every release listed for this repository carries the -beta suffix: v1.1.0-beta, v1.0.9-beta, v1.0.8-beta, with the newest published on 2026-09-22. The README reinforces the point with a large construction sign graphic. Taken together, the project is telling you that the interfaces and the packaging are not settled.

For a screenshot tool this matters in a specific way. The feature surface touches the operating system's screen capture, window management and clipboard behaviour, all of which are the parts most likely to break between OS updates and the parts least likely to be covered by unit tests. A beta label on a tool that reads your screen is a reasonable reason to keep it off a machine where you cannot afford a capture failure. The repository also does not document a rollback path or a downgrade procedure, and the README is silent on migration between releases, so pinning a known-good tag and building from it is the only version control the documentation supports.

On the other hand, the last push to the default branch was on 2026-09-22, the same day as the newest release. Whatever else is uncertain, the tree is not abandoned.

Where Snow Apps is the wrong choice

If you need to build on Windows or Linux, the repository does not currently help you. The README documents macOS only, and the single build guide in the root is docs-macos-build.md. The presence of vcpkg and CMake suggests other platforms are technically reachable, but there is no documented preset set, no packaging story, and no stated support for them. Treating an undocumented port as supported is how you end up maintaining a fork.

If you want a library rather than an application, the split is also awkward. The permissively licensed pieces (snow-crates/, snow_draw_engine_qt/, snow_rust_ffi/) are the ones most likely to be reusable, but the README does not describe their public APIs, their stability, or whether they are meant to be consumed outside this tree. There is no published package name for any of them in the README.

And if you need documentation before code, this is not the project for you yet. There is no architecture document, no contributor guide beyond AGENTS.md, and no description of how OCR or screen recording are wired. The code is the specification.

How it compares with Flameshot and ShareX

The obvious comparison for the screenshot half is Flameshot, which is a Qt-based screenshot and annotation tool distributed primarily for Linux with builds for other platforms. The difference in approach is packaging and scope. Flameshot ships installable packages and its build system is oriented around distribution maintainers; Snow Apps is a source-first monorepo where you configure through CMakePresets.json and vcpkg and build the applications yourself, with DMG packaging as the documented output. Flameshot also does not bundle an image viewer or a Rust FFI layer.

ShareX is the other reference point, and the contrast is sharper. ShareX is a Windows-only .NET application with a very wide feature set around capture, upload destinations and automation. Snow Apps is C++ and Qt, documents macOS as its build target, and its topic list is narrower: screenshot, screen recorder, OCR, image viewer. If your requirement is upload workflows and a plugin ecosystem on Windows, ShareX is the closer fit and Snow Apps is not competing there. If your requirement is a Qt codebase you can read and rebuild, Snow Apps is the one with the source layout you can walk through.

Editorial conclusion

Adopt Snow Apps if you want to build Snow Shot or Snow Image Viewer from source on macOS, or if you are reading the code to see how a Qt screenshot tool is split across C++, Rust and vcpkg. Do not adopt it if you need a documented Windows or Linux build path, a stable release, or a licence you can absorb into a closed product: snow_shot, snow_image and snow_image_viewer are GPL v3.0 or later, while only the shared libraries are Apache 2.0. Before anything else, read LICENSE.md for the repository-level scope rules and snow_shot/THIRD_PARTY_NOTICES.md, then run the Snow Shot macOS build guide end to end on the platform you actually target.

Frequently asked questions

Official sources

1. Issues
2. mg-chao/snow-apps on GitHub
3. Project website
4. README
5. Releases