Building WebKit for OpenHarmony with vcpkg

A while back I wrote about WebKitView for OpenHarmony, an effort to bring a WebKit-based WebView to OpenHarmony using only the public SDK. That post covered the first milestone: getting WebKit to compile, render a basic web page, and integrate with an ArkTS application.

This is an update. Two things have changed since then. First, the way I build WebKit’s dependencies has moved from Cerbero to vcpkg. Second, WebKitView now has basic media playback.

Why move off Cerbero?

In the original post, all of WebKit’s dependencies were built with Cerbero. It worked, but it came with a cost. Cerbero is a build system aggregator with its own .recipe files, and adding OpenHarmony meant teaching it about a platform it had never heard of: SDK and toolchain support, Autotools and Meson patches, custom build script fixes, and unversioned shared libraries. That was a lot of platform-specific groundwork to carry and maintain, and Cerbero is used by a relatively small group of people.

In the meantime, the picture changed. The Qt Project added an OpenHarmony platform to vcpkg, which shipped in vcpkg 2026.06.01. They also wrote about it: Building libraries for HarmonyOS with vcpkg.

vcpkg enjoys much wider adoption than Cerbero, and with upstream OpenHarmony support now in place, switching is the reasonable move. It reduces the maintenance burden of carrying OpenHarmony patches in a Cerbero fork, and it leans on a build system that many more people understand and use.

There’s another reason: WebKit itself already uses vcpkg. The WebKit repository ships its own vcpkg.json, which the WebKit for Windows port builds against via WebKitRequirements. So vcpkg is not some external choice bolted onto WebKit; it’s already part of how WebKit is built on at least one platform. Aligning the OpenHarmony build with that makes it feel a lot less like swimming against the current.

For now I’m using vcpkg the same way I used Cerbero: take a release source tarball from WebKit, patch it, and build it with vcpkg. This keeps the build flow and bootstrapping close to what it used to be, so the move is mostly a swap of the dependency builder rather than a rewrite of everything around it. In the future I might go further and apply the OpenHarmony patches directly on top of WebKit, and create an OpenHarmony-specific vcpkg registry along the lines of what WebKitRequirements is for Windows. For now, the tarball-and-patch approach keeps things simple.

The practical difference is striking. With Cerbero, OpenHarmony support meant patching the build system itself and maintaining a large set of recipes. With vcpkg, the OpenHarmony-specific surface shrinks to a handful of overlay ports and overlay triplets layered on top of upstream vcpkg. Most dependencies build straight from upstream vcpkg ports; only a few need an OpenHarmony patch.

How the vcpkg build is composed

The new build lives in a separate repository, webkit-openharmony-vcpkg. It cross-compiles WPE WebKit and its full dependency tree for OpenHarmony (arm64-ohos) and packages the result as a portable SDK.

The whole thing is a few pieces wired together:

• A manifest (vcpkg.json) that depends on wpewebkit, pins a vcpkg baseline, and adds a small set of version overrides.
• Two overlay triplets: arm64-ohos (the primary one, static by default) and arm64-ohos-dynamic for development and debugging.
• A small set of overlay ports that override upstream: new ports for wpewebkit and libwpe, OpenHarmony patches for things like GLib, GStreamer, FFmpeg and OpenSSL, plus two helper overlays that teach Meson and libtool to emit unversioned shared libraries.

The result is laid out as a portable SDK that the webkitview-openharmony app pulls in directly:

# in the webkitview-openharmony checkout:
python3 tools/bootstrap.py -a arm64 install --vcpkg /path/to/webkit-openharmony-vcpkg/dist

In one line: pinned vcpkg, plus an OpenHarmony overlay triplet, plus OpenHarmony-patched overlay ports, cross-compiles WPE WebKit’s entire dependency tree. Most dependencies fold into a fat libWPEWebKit-2.0.so, a few stay dynamic for plugin resolution, and the whole thing is packaged as an SDK the WebKitView app slurps in.

Media playback

The other new piece is basic media playback. In the original post, media was on the “not yet supported” list. WPE WebKit uses GStreamer for media, so getting playback working was mostly about shipping the right plugins and pointing GStreamer at them on the device.

Concretely, the GStreamer plugins built by vcpkg are now deployed alongside the app, and the runtime environment is wired up so GStreamer can find and load them: GST_PLUGIN_SYSTEM_PATH and GST_PLUGIN_PATH point at the deployed plugin directory, and the plugin registry is given a writable location on device.

Current status

✔ WebKit compiles on OpenHarmony
✔ Basic web pages render correctly
✔ Dependencies built with vcpkg (Cerbero no longer needed)
✔ Integration with an ArkTS app works
✔ Basic media playback

Not yet supported:

✖ GPU accelerated rendering
✖ WebGL
✖ Deeper platform features like Bluetooth and Location services

The two repositories are on GitHub:

• webkit-openharmony-vcpkg — the vcpkg-based dependency build
• webkitview-openharmony — the WebView and ArkTS integration