stasel/WebRTC keeps prebuilt Apple WebRTC frameworks coming after Google stopped

The gap Google left when it deprecated the mobile pod

The reason this repository exists is a specific deprecation. Since version M80, Google has deprecated their mobile binary library distributions, which were officially distributed through the GoogleWebRTD pod, and the project points at the upstream discussion. The consequence for the ecosystem was that Apple developers who needed WebRTC in an app had three options: compile it themselves from the upstream source, which is a large build, find a precompiled binary from another source, or use one of the community distributions. This repository is the third option, and the framing is deliberately modest. It is a community-driven distribution of WebRTC framework binaries for iOS and macOS. The audience is teams that need the framework to exist rather than teams that want to contribute to WebRTC itself. The upstream project is a research platform that is built daily for many platforms, and the Apple build in particular is heavy, so having somebody maintain a repeatable build and publish the artefact saves every downstream team from repeating it.

Unmodified source, open build, and releases that track Chromium

What the project commits to is stated as a list of things to know, and the list is short. All binaries in the repository are compiled from the official WebRTC source code, no modifications are made to the source code or the output binaries, and the build process is open source using GitHub Actions. The second of those is the one that matters most in practice. A community binary distribution is only useful if you can trust that the artefact corresponds to the upstream code, and the combination of a public build definition and an unmodified source tree is what makes that checkable. The release naming follows the Chromium convention, since the binary releases correspond with official Chromium releases and branches as specified in the Chromium dashboard, which is how you map a framework version back to an upstream point in time. The recent tags show the cadence: M155 on 2026-10-12, M154 on 2026-09-30 and M153 on 2026-09-11. The last push to the repository was on 2026-10-12 and it is not archived, so the distribution is being rebuilt as upstream moves.

What is in the box, and which platforms it covers

The artefact is a dynamic framework in the xcframework format, which contains multiple binaries for macOS and iOS, and the coverage table is explicit. For iOS on device, arm64 is provided and x86_64 does not apply. For the iOS simulator, both arm64 and x86_64 are provided, which matters because Apple Silicon simulators and Intel simulators are different architectures. For macOS and for macOS Catalyst, both arm64 and x86_64 are provided. The requirements are iOS 15 or later, macOS 12 or later, and macOS Catalyst 11.0 or later. One boundary is stated sharply: 32 bit binaries are only available in version M94 or lower. For a project that still has a 32 bit deployment target, that release is from a much older WebRTC and the support question is real rather than theoretical. The package also includes dSYM files, available from version M152, which matters more than it sounds, because a framework without symbols makes a crash report in a production build close to useless.

Codec coverage is the detail that bites

The framework includes support for extra encodings, specifically VP9, H264 and AV1, which are listed as additions on top of what WebRTC ships by default. The H.265 and HEVC case is described with unusual care and is worth reading closely. The SDP negotiation and the RTP packetization layer are compiled, but WebRTC ships no HEVC encoder or decoder for Apple platforms. So the machinery is present and the codec is not. That distinction matters when you are debugging a call that negotiates HEVC and then produces no media, and it explains why the project bothers to state it. The general shape of the feature is that the upstream framework, which has to run in browsers, does not necessarily carry the codecs that an Apple specific deployment would want, and this distribution adds the ones that are missing. The dSYM availability from M152 sits in the same paragraph, and both details are the kind of thing that is much better to read now than to discover during an incident.

Three package managers, and they are not equivalent

The installation options are the standard Apple three, and the difference between them is more than a matter of taste. Swift Package Manager has built-in support in Xcode, so you add the package through File > Swift Packages > Add Package Dependency, or you add it to your Package.swift file yourself. The versioned form pins a major version:

dependencies: [
    .package(url: "https://github.com/stasel/WebRTC.git", .upToNextMajor("155.0.0"))
]

And the branch form tracks the newest binary:

dependencies: [
    .package(url: "https://github.com/stasel/WebRTC.git", branch: "latest")
]

Those two choices are not equivalent in a release build, and the second one is the risk. The default branch of the repository is latest, and it is where new builds land, so tracking it means your app can pick up a new framework version without anyone changing your dependency. For a product you ship, the versioned form is the safer default, with the branch form reserved for testing a new build before you pin it. CocoaPods is the second option and it is a single line in the Podfile:

pod 'WebRTC-lib'

followed by pod install. Carthage is the third, and it needs a binary declaration in the Cartfile:

binary "https://raw.githubusercontent.com/stasel/WebRTC/latest/WebRTC.json"

then carthage update --use-xcframeworks, and finally the resulting WebRTC.xcframework in the Carthage/Build directory is added to your target's embedded frameworks. Whichever route you take, the import in your code is the same:

import WebRTC

Compiling it yourself, and where the licence actually applies

If the prebuilt binaries do not fit, the project points at the official guide for compiling your own WebRTC framework, and also at the build script in the scripts/ directory for more detail, which is a reasonable starting point since the upstream build for Apple platforms is documented but fiddly. The licence arrangement deserves careful reading, because it is split. The build scripts in this repository are under the BSD 3-Clause Licence, while WebRTC itself carries its own licence at webrtc.org/support/license. That means the scripts that produce the binaries are permissively licensed and the output of compiling WebRTC is governed by the WebRTC terms, which are not the same thing. For a team shipping a commercial app, that distinction is the one to settle with whoever owns licensing in your organisation, and it is not something to infer from the fact that the repository is public. The repository also carries a Package.swift, a WebRTC-lib.podspec, the WebRTC.json that Carthage consumes, and a scripts/ directory, which is a small surface area and a sign that the packaging is maintained rather than accumulated.

Editorial conclusion

Adopt stasel/WebRTC if you ship an iOS or macOS app that needs WebRTC and you want upstream binaries rather than maintaining your own build of the Chromium tree. Do not adopt it if your project needs a 32 bit target, because the binaries for those ended at version M94, and do not assume the framework carries every codec. Before you pin a version, check the extra encoding support your platform needs, since HEVC is compiled but no Apple encoder or decoder ships with WebRTC, and read the WebRTC licence separately from the BSD licence that covers only the build scripts in this repository.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. stasel/WebRTC on GitHub