WebRTCnative

WebRTCnative

The bottom of the stack, and a separate repository: melihercan/WebRTCnative. It builds Google's WebRTC native libraries for every platform and publishes them as GitHub Actions artifacts. WebRTCme consumes the results.

You do not need it to use WebRTCme. The native binaries are already committed here and already inside the published packages. This page exists for the two cases where it matters: you want to know which WebRTC version you are shipping, or you want to build it yourself.

Its own wiki is the reference. This page is a summary and a set of pointers.

Why it is a separate repository

Building WebRTC needs depot_tools, a checkout of roughly 30 GB, and a long compile on a machine with the right platform SDK. None of that belongs in an application repository, and nobody wants it on their laptop. Keeping it elsewhere means the expensive part happens on GitHub's runners, on demand, and WebRTCme consumes prebuilt binaries.

What it produces, and who eats it

flowchart LR
  src["webrtc.googlesource.com<br/>+ chromiumdash — which milestone is stable?"]
  gha["WebRTCnative<br/>GitHub Actions"]

  and2["libwebrtc.aar"]
  ios["WebRTC.xcframework"]
  mac["WebRTC.framework"]
  win["WebRtcInterop.dll<br/>+ its import closure"]

  ba["Bindings.Maui.Android"]
  bi["Bindings.Maui.iOS"]
  bm["Bindings.Maui.MacCatalyst"]
  bw["Bindings.Maui.Windows"]

  src --> gha
  gha --> and2 --> ba
  gha --> ios --> bi
  gha --> mac --> bm
  gha --> win --> bw

Loading

Blazor is absent from that picture on purpose: there is no native payload on the web, because the browser already ships WebRTC. See Bindings.

Windows is the odd one. The other three artifacts are the platform SDKs Google itself publishes — a Java SDK, an Objective-C framework. There is no such SDK for Windows, so WebRTCnative builds one: WebRtcInterop.dll, a flat C ABI over libwebrtc, designed to be P/Invoked. Its contract is the Interop ABI page.

Which WebRTC version is in here?

It is a property of the build, not of this repository, and that is deliberate. Nothing in WebRTCme pins a WebRTC version. Each WebRTCnative run resolves one: given a branch number it uses that, and given nothing it asks the Chromium dashboard for the newest milestone that has reached stable and takes that milestone's branch head.

Two consequences:

• The answer lives in the artifact name of the run a binary came from — webrtc-<platform>-m<milestone>-<branch>.
• Two artifacts built on different days can be different WebRTC versions from identical inputs, because "newest stable milestone" moves.

WebRTCme.Bindings/README_NativeSdkVersions.txt records when each artifact was committed here, which is the closest thing to a version this repository honestly knows. It used to record version numbers and they were four years stale and believed, which is why it no longer does.

Refreshing a native binary

Summarised; the detail is in Consuming the artifacts.

1. Run the workflow for the platform from WebRTCnative's Actions tab. Leave the inputs blank for the current stable milestone, or set webrtc_branch to pin one. Expect about an hour.

2. Download the artifact and copy the payload into the matching binding project:

   	lands in
   Android	WebRTCme.Bindings/Maui/WebRTCme.Bindings.Maui.Android/Jars/libwebrtc.aar
   iOS	WebRTCme.Bindings/Maui/WebRTCme.Bindings.Maui.iOS/WebRTC.xcframework
   Mac Catalyst	WebRTCme.Bindings/Maui/WebRTCme.Bindings.Maui.MacCatalyst/WebRTC.framework
   Windows	WebRTCme.Bindings/Maui/WebRTCme.Bindings.Maui.Windows/native/win-x64/

3. On Windows, take only the files that folder's README.md lists — the artifact also carries the build machine's debugger tooling, which nothing imports.

4. Rebuild the bindings. An Objective-C or Java SDK that has changed shape may need its binding definitions regenerated; see Bindings.

Two things that are easy to get wrong and fail late rather than loudly:

• Mac Catalyst's WebRTC.framework must be a versioned bundle — Versions/A plus symlinks — or macOS refuses to codesign an app embedding it. Windows can neither check those symlinks out of git nor write them into a zip, which is why CI builds that slice on a Mac.
• The Windows payload is a component build: WebRtcInterop.dll is not statically linked and needs its four sibling DLLs plus the MSVC runtime beside it.

Where to read more

WebRTCnative wiki home	Everything below
Running a build	Dispatching a workflow, the inputs, where the artifact lands
Branch selection	How a WebRTC branch is chosen, and why nothing is hard-coded
Interop ABI	The C contract the Windows binding P/Invokes
Platform layers	What is actually inside each artifact, and what is missing
Shared library patch	Turning WebRTC's static-only build into a DLL / .so / .dylib
Troubleshooting	Build failures seen in practice

Next layer up: Bindings.