WebKit is an engine project, not a drop-in webview
The 5,173 MB repository contains the engine beneath Safari, Mail, Apple Books, and other applications on Apple platforms. It also carries GTK and WPE ports for Linux, plus a Windows path. That makes it the right source tree when you need to change page layout, JavaScriptCore, networking, media, accessibility, or standards behavior in WebKit itself. It is a poor starting point when all you need is a browser-shaped component with a small dependency surface.
Scale changes the decision immediately. Our commit a982196 checkout contained 465,540 files and about 23,469,224 lines of source. Those measurements describe the repository before a full engine build. A contributor is taking on a browser engine and several platform ports, not installing a normal JavaScript library. The root README reflects that reality by splitting build instructions across Apple platforms, GTK, WPE, and Windows.
The 12-second install covered IonGraph, not the engine
Our 12-second Bun install added 3 packages for Tools/IonGraph, a control-flow graph viewer for JavaScriptCore adapted from Mozilla's IonGraph work. WebKit's version computes loop information in the viewer and can produce a local HTML build that opens without a server. Its documented development loop is short: install with Bun, then run the local viewer.
That small package can create a misleading first impression. IonGraph has two development dependencies and scripts named build-all, build-package, build-www, and serve. It is one tool inside a 5,173 MB checkout. Passing its dependency installation says nothing about whether WebCore, JavaScriptCore, or a platform port compiles on the same machine. This distinction is the most important fact in our run.
What happened when we ran it
Our sandbox used 3 CPUs, 8 GB of RAM, Node 22, and commit a982196. Inside Tools/IonGraph, bun install succeeded in 12 seconds, added 3 packages, and occupied 33 MB on disk. The harness found no standard build script or target, so it skipped the build. It also found no standard test script or target and skipped tests.
The repository scan reported 0 CI workflow files, no Dockerfile, and no tests directory. That does not mean WebKit lacks testing. Current pull requests display WebKit's external Early Warning System matrix across style checks, bindings, Apple platforms, GTK, WPE, Windows, and JavaScriptCore jobs. It means the familiar GitHub Actions, root Dockerfile, and root tests-folder signals were absent from the checkout our lab classified.
No vulnerability count belongs here because the supplied run did not report one for this repository. The honest result is narrow: one 3-package tool installed cleanly, while no engine build or test suite ran. Anybody estimating contributor setup should use the port documentation and provision a machine for that port rather than extrapolating from IonGraph.
Four platform routes require different build machines
The README divides setup across 4 routes: Apple platforms, GTK, WPE, and Windows. Apple development starts with Xcode, its command line tools, and a separately downloaded Metal toolchain. The default command produces a macOS debug build with symbols and assertions. Running that build in Safari relies on DYLD_FRAMEWORK_PATH, while iOS work uses simulator or device targets.
Linux is a separate track. GTK and WPE production builds use CMake and Ninja, and development builds call port-specific dependency and library update scripts. The mini browser runner also needs an explicit port such as GTK or WPE. Windows contributors are sent to dedicated documentation and told they must build the engine themselves. There is no single container recipe that erases those differences.
Bugzilla and external builders replace GitHub's usual signals
The last push recorded by GitHub was September 17, 2026, and new pull requests on that date were already running through a wide platform matrix. GitHub showed 10,181 stars and a combined 2,685 open issues and pull requests, although repository issues are disabled and that field should not be read as a bug total. The README sends bug reports to WebKit Bugzilla and explains its separate bug life cycle.
There is no latest GitHub release to use as a health marker. WebKit instead points users toward Safari Technology Preview on macOS, Epiphany Technology Preview on Linux, and nightly builds for confirming fixes. That workflow is less convenient for teams centered on GitHub Releases, but daily source activity and live review jobs are much better evidence of maintenance than a missing tag.
Choose WebKit only when WebKit behavior is the requirement
A 5,173 MB checkout is justified when your work must land in Safari, fix a WebKit standards gap, or support a product built on its GTK or WPE ports. The documentation names real build and run commands, and the review system shows that changes face many platform checks. The cost includes platform-specific dependencies and an engine-scale test surface that our package probe did not exercise.
For Chromium compatibility, Chromium is the more direct codebase. Servo offers a Rust engine and an embedding API, while Ladybird is useful for studying an independent implementation. WebKit is the sensible choice when substituting another engine would miss the problem you are trying to solve.