WebKit ships no release to install, so you test through a preview build or your own compile

No release to install, only a moving tip on main

The repository publishes no GitHub releases, so there is no version string to fetch and no tag to pin from the GitHub interface. What you get is whatever main holds at clone time, and the last push is dated 2026-11-02. The clone itself is one command:

git clone https://github.com/WebKit/WebKit.git WebKit

The first build on Apple hardware is `Tools/Scripts/build-webkit --debug`, which produces a macOS debug build with debugging symbols and assertions, and `Tools/Scripts/build-webkit --release` is the performance-testing variant. After cloning you can make many git commands faster with `git config core.fsmonitor true`. The consequence for a reader is that reproducibility is entirely your problem: the documented flow contains no archived tarball of a known-good commit, so two engineers who clone on different days get different trees, and a regression you report may already have been fixed on the tip you tested against.

Preview channels cover macOS and Linux, Windows gets a sentence

To test the latest engine without compiling, the project names two preview channels and then stops. On macOS you download Safari Technology Preview from webkit.org/downloads, and on Linux you pick up Epiphany Technology Preview from the WebKitGTK site. For Windows the guidance is that you will have to build it yourself, with a pointer to the WebKit on Windows page at docs.webkit.org/Ports/WindowsPort.html rather than to any recipe. That asymmetry is the practical limit here: a Windows developer gets an external document and no binary, while a Linux developer gets a browser they can install today. It also means the preview channels double as an answer to a question the repository cannot answer with tags. If your goal is only to know whether a change landed, Safari Technology Preview is the shortest path, and the latest nightly is what a bug reporter may be asked to confirm a fix against.

The GTK and WPE ports ship build recipes, not packages

The Linux ports are given as commands rather than as downloads. Production builds for GTK are:

cmake -DPORT=GTK -DCMAKE_BUILD_TYPE=RelWithDebInfo -GNinja
ninja
sudo ninja install

Development builds take a different route, running `Tools/gtk/install-dependencies` and `Tools/Scripts/update-webkitgtk-libs` before `Tools/Scripts/build-webkit --gtk --debug`. The WPE port mirrors this exactly, swapping in `-DPORT=WPE` and `Tools/wpe/install-dependencies`. What you are owed as a reader is an honest picture of the cost: three commands produce a system-wide installation that ends in a sudo install step, and there is no documented rollback for an install that breaks a system browser.

DYLD_FRAMEWORK_PATH is how your build replaces the engine Safari loads

Launching macOS applications against a local build is done with `Tools/Scripts/run-safari --debug`, and the mechanism is a loader override rather than a copy. The script sets the `DYLD_FRAMEWORK_PATH` environment variable to point at your build products, which tells the system loader to prefer them over the frameworks installed in `/System/Library/Frameworks`, and then it launches `/Applications/Safari.app` itself. For anything else you use `Tools/Scripts/run-webkit-app <application-path>`, and the iOS simulator variant is `run-safari --debug --ios-simulator`. The consequence is a real one for anyone debugging on their daily machine: the override applies to the process the script starts, so a broken local build is not quarantined from your system applications, it simply becomes the engine those processes load. The scope is also narrow, which is the saving grace: a Safari you launch from the Dock is unaffected, so keep the debug build on a separate account or a scratch volume.

The Makefile switches between an Xcode scheme and a directory walk

The root Makefile has two personalities gated on one variable. When `USE_WORKSPACE` is anything other than `NO`, it sets `SCHEME = Everything up to WebKit + Tools`, points `SCRIPTS_PATH` at `Tools/Scripts`, and includes `Makefile.shared` so the build is driven through the Xcode workspace. The `analyze` target quietly overrides the scheme to `Everything up to WebKit`, dropping the Tools portion, so a static-analysis run does not build the same set of targets that a release build does. When `USE_WORKSPACE` is `NO`, the file instead defines `MODULES = Source Tools` and walks those directories, re-invoking make in each one for the `all`, `debug`, `release`, `release+assert`, `testing`, `analyze` and `clean` targets. The same target name therefore produces different work depending on the `USE_WORKSPACE` variable.

The Xcode workspace has to be pointed at WebKitBuild by hand

You can open `WebKit.xcworkspace` to build and debug inside Xcode, and the scheme to pick for the whole project is `Everything up to WebKit + Tools`. One manual step stands between a fresh clone and a working build. If you have not set a custom build location in Xcode preferences, you must open the workspace settings, choose File > Workspace Settings, click the Advanced button, select `Custom` and `Relative to Workspace`, and enter `WebKitBuild` for both Products and Intermediates. Apple platform builds also need two one-time tool steps: `xcode-select --install` for the command line tools, and `xcodebuild -downloadComponent MetalToolchain`, which is why the Metal component is called out separately from Xcode itself. The README says that without a custom build location in Xcode preferences you have to update the workspace settings to use the `WebKitBuild` directory.

Running JavaScript and layout tests

WebKit documents test runners for its different suites. Run `Tools/Scripts/run-javascriptcore-tests` for JavaScriptCore tests and `Tools/Scripts/run-webkit-tests` for layout tests. The layout runner accepts a file or directory, for example `Tools/Scripts/run-webkit-tests fast/dom/Element/element-traversal.html`, as well as `--debug` or `--release`; use `--help` for the available options.

Failed layout results are written beneath `WebKitBuild/Debug/layout-test-results/` for a debug build, including a results page. The project recommends running the subset relevant to a change during development and broader tests or its Early Warning System before landing it.

The root has no LICENSE file and a marker telling GitHub not to index it

Two things about the repository root matter before you build on this code. The top-level entries include a `.metadata_never_index` file. And there is no `LICENSE` file among those entries, but that does not mean the source lacks licence notices. WebKit’s licensing page states that portions use LGPL and BSD terms; inspect the relevant source files and licence notices for the components you distribute. The root also carries configuration for three assistant tools, with `.claude/`, `.codex/` and `.gemini/` sitting alongside `.clang-format`, `.swift-format`, `.ccls` and `.dir-locals.el`, plus two overview documents, `Introduction.md` and `ReadMe.md`.

Editorial conclusion

WebKit suits a developer who specifically needs Safari engine behavior, either to test a preview build before it ships or to patch the source and launch a local build inside Safari. It is the wrong tool if you need a versioned dependency, an installable package on Windows, or a single prebuilt package covering every port. Before you start, confirm the licensing terms on webkit.org since the repository root carries no LICENSE file, and budget for Xcode plus the Metal toolchain on Apple platforms.

Frequently asked questions

Official sources

1. Issues
2. README
3. WebKit/WebKit on GitHub