webview: WebKit and WebView2 behind one C++ API, pinned by tag because there are no releases

The copy and paste build fetches tag 0.12.0, and there are no releases

Both example projects pull the library in with CMake FetchContent, and both name a tag:

FetchContent_Declare(
    webview
    GIT_REPOSITORY https://github.com/webview/webview
    GIT_TAG 0.12.0)
FetchContent_MakeAvailable(webview)

That is the version a reader gets by following the getting started page. The repository has no GitHub releases at all, so tags are the only versioning there is The tip of master was last pushed on 2026-10-22.

The consequence is a gap between the documentation and the code. `MIGRATION.md` and `CHANGELOG.md` sit at the repository root, which is where you would look for what changed. Pin deliberately: either stay on the tag the example names, or move to master and read the migration notes first, and keep the tag you chose in your own lockstep record.

There is a related versioning split. The note about the Go binding says it has moved elsewhere, and that versions up to 0.1.1 remain available in this repository. So the C and C++ surface has one versioning story and the Go story has been cut off at a low version here.

Windows needs C++14 while everywhere else needs C++11

The stated floor is not uniform. Your compiler must support minimum C++11, which is the general prerequisite. Then the Windows section says your compiler must support C++14, and recommends pairing it with an up-to-date Windows 10 SDK. For Visual C++ the recommendation is Visual Studio 2022 or later, and there is a separate set of requirements when using MinGW-w64.

So a project that targets all three platforms cannot state one language floor in its own build configuration without lying on one of them. Your continuous integration has to carry a toolchain new enough for Windows regardless of what the other two need, and anyone reading only the first prerequisite line will build for Windows and find out otherwise.

The runtime requirement is the larger one. Developers and end-users must have the WebView2 runtime installed on their system for any version of Windows before Windows 11. That is two audiences, not one: the machine that compiles and the machine that runs.

The consequence for distribution is the important part. You cannot hand someone a self-contained executable and assume the window appears, because the browser engine that renders your HTML5 interface has to already be present on their machine. The prerequisites section states the requirement without describing a bootstrapper or a fallback, so plan how the runtime reaches Windows machines before 11.

Three WebKitGTK generations on Linux, and the choice is made at build time

Linux and BSD development needs GTK and WebKitGTK, and the project spells out three supported combinations rather than picking one for you. On Debian, WebKitGTK 6.0 with GTK 4 installs development packages with `apt install libgtk-4-dev libwebkitgtk-6.0-dev`, WebKitGTK 4.1 with GTK 3 and libsoup 3 uses `apt install libgtk-3-dev libwebkit2gtk-4.1-dev`, and WebKitGTK 4.0 with GTK 3 and libsoup 2 uses `apt install libgtk-3-dev libwebkit2gtk-4.0-dev`. Fedora has the matching `dnf` lines, and FreeBSD is two commands, `pkg install webkit2-gtk4` and `pkg install webkit2-gtk3`.

The linker side is discovered with `pkg-config` and three module sets: `gtk4 webkitgtk-6.0`, `gtk+-3.0 webkit2gtk-4.1`, and `gtk+-3.0 webkit2gtk-4.0`. On Linux you also link `dl`. macOS links the `WebKit` framework plus `dl`. Windows needs WebView2 from NuGet and the libraries `advapi32 ole32 shell32 shlwapi user32 version`.

Two consequences follow from that structure. The pairing is constrained: GTK 4 appears only with WebKitGTK 6.0, so an application already on GTK 3 cannot take the newest engine without moving toolkits. And the selection is compile-time, resolved by pkg-config during the build, so a binary you ship is bound to one engine generation and cannot be retargeted on the user's machine. Separate the development packages from the production ones in your packaging, since the two lists are named differently in every distribution.

On BSD the library may ask you to disable a memory protection first

There is one platform note in the prerequisites that is worth reading twice, because it asks for a security setting to be relaxed. Execution on BSD-based systems may require adding the `wxallowed` option, as described in mount(8), to your fstab, in order to bypass W^X memory protection for your executable. The advice that follows is to see whether it works without disabling the security feature first.

That instruction is correct in sequence and worth respecting literally. Try the build unmodified, because a program that runs without the option tells you nothing is wrong. If it fails, the change is a mount option in fstab rather than a setting inside your program.

The consequence is a security decision that has to be made deliberately and recorded. W^X exists to stop memory from being both writable and executable at once, and turning it off weakens that protection for what runs from the affected mount. If you are shipping to BSD targets, decide whether your application can live with that change or whether the platform is not viable for you, and say so in your own deployment documentation, because this project states the requirement without recommending a scope or a mitigation.

The OpenBSD mount(8) page is the reference for the option itself.

Two CMake targets, and a generated header for everyone not using CMake

The C++ example links a CMake target called `webview::core`, and the C example links a different one, `webview::core_static`, with the C API expressed as a handle and plain functions: `webview_create(0, NULL)`, `webview_set_title`, `webview_set_size`, `webview_set_html`, `webview_run` and `webview_destroy`. The C++ side wraps the same operations in an object with a constructor taking a debug flag and a parent pointer.

Which target you choose is the first packaging decision, and the examples do not explain when to pick the static one. The names imply a shared library for C++ and a static library for C, but the difference that matters to you, whether you must ship a runtime beside your executable, is left to your own judgement.

There is a second route for builds that do not use CMake at all. An amalgamated library can be produced by CMake itself, or by running the script directly:

python3 scripts/amalgamate/amalgamate.py --base core --search include --output webview_amalgamation.h src

Run it with `--help` for the full usage. The consequence is that the single-header form is generated output, not a checked-in file, so it has to be regenerated whenever you change version, and it is not covered by any release packaging since the project publishes no releases. CMake and Ninja are recommended but explicitly not required for using the library, so this generated header is one route for a hand-rolled build.

The documentation is the source, and there is no site to pin it against

The documentation section says the most up-to-date documentation is right in the source code, and that improving it is a continuous effort with contributions welcome. The project has no homepage and publishes no versioned reference site, so there is nothing stable to link a reader to.

For a library you vendor by adding a header, that has a specific cost. The reference you consult is whatever revision you happened to check out, and a search result pointing at a discussion will describe whichever commit it was written against. There is no way to ask the documentation which version a given signature belongs to. The root listing shows what the project does keep under version control: `docs/`, `examples/`, `test_driver/`, `CHANGELOG.md`, `MIGRATION.md`, `webview.i` for SWIG bindings, `packaging/`, `.clang-format` and `.clang-tidy`, plus coverage configuration in `gcovr.cfg` and `gcovr.ci.cfg`.

The examples are the other half of the readable surface, and they are deliberately small: `basic.cc`, `basic.c`, `bind.cc` and `bind.c` with a shared `resources/` directory and their own CMakeLists.txt. The bind examples are where the two-way JavaScript binding is demonstrated, which is the feature the project leads with, since it lets you call JavaScript from C and C++ and call C and C++ back from JavaScript. Read the header, those four files and the docs/ directory.

Editorial conclusion

Use webview when you want one HTML5 surface across the three desktop platforms and you can accept that the engine underneath differs per platform. Do not pick it for a single-binary distribution to Windows before Windows 11, because the WebView2 runtime requirement lands on your end users there, and do not build against the master branch expecting release notes, since the project publishes no releases and the copy-and-paste example pins tag 0.12.0. Before you commit, check which WebKitGTK generation your distribution ships, confirm your toolchain meets C++14 on Windows and C++11 elsewhere, and read MIGRATION.md before upgrading past the tag you started on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. webview/webview on GitHub