Chrome moves to a 2 week release cycle. Where are you with your WebRTC app

Chrome is about to release every 2 weeks. If you are building on WebRTC, your testing window just got cut in half.

Chrome is switching to a 2 week release cycle. This will start taking place in September this year. This is from the current 4 week release cycle. Everything is speeding up, and if you’re building things with WebRTC – you should definitely take note and prepare.

Chrome is moving faster than your update cycle

Agile came, and we did once a month or continuously or something in between.

At rtcStats we started with every 2 weeks. Dialed down to 3 – it fits our schedules better and makes more sense at our size and target audience.

Chrome? It used to be 6 weeks, then four and now two. It is now running faster than most anyone else. Even Chromium integrators are complaining now about their need to keep pace. Ignore for a second the GenAI behemoths who likely release so fast they can’t keep up with their own work – we’ll get to them later from another angle.

At the time of writing this (not publishing), my Chrome runs version 147 and just started uploading an update. I couldn’t care less. It isn’t as if in the last 50 or 100 version updates of Chrome I felt anything. For users and most web developers this is invisible. There’s no need to care.

For WebRTC developers? That’s a totally different ballgame. WebRTC is a fairly large API surface and that is just the tip of the iceberg.

Just this month we’ve had our share of broken services and open source media servers due to a change in how libWebRTC implements the sending feedback – not because it wasn’t following the spec before or isn’t following it now – just because it changed certain minor behaviors. But other software implementations relied on the current behavior.

This one was caught on only stable – slipped through the beta process. Amazon Chime engineers caught the bug on their side in beta.

It got to the point that we sent a special out of schedule email to all of our WebRTC Insights clients so they can determine if they are affected as well.

Catching such things in beta makes everything stabler. But that 4-week window between one Chrome release and another is now shrinking to two.

Chrome is the window to the web

Chrome alone has an estimated 3.8 to 4.2 billion users worldwide, holding roughly 65% of all browser market share across devices. But Chrome is just the tip. Chromium, the open source engine underneath, powers close to 30 browsers: Edge, Samsung Internet, Opera, Brave, Vivaldi, Arc, and many others. Over 70% of all web browsing happens through Chromium’s engine.

Then there’s the app layer. Electron (built on Chromium) powers over 8,000 apps on the Mac App Store alone: VS Code, Slack, Discord, Spotify’s desktop client. CEF (Chromium Embedded Framework) runs inside Steam, Epic Games Launcher, and hundreds of enterprise tools. Android WebView, also Chromium-based, renders content inside virtually every Android app that shows a web page.

When a security researcher finds a vulnerability in Chromium, the blast radius isn’t one browser. It’s the majority of the internet’s rendering surface.

Having something like Chrome change its pace means the whole industry around it is going to feel it as well.

Why Google is accelerating

• Chrome/Chromium’s sheer scale makes it a magnet for security researchers and adversaries alike
• GenAI is now a force multiplier on both sides: defenders find CVEs faster, attackers craft exploits faster. The response? Ship fixes faster

The GenAI one is worth contemplating. In that laconic announcement by Google (likely drafted by Gemini), they hint as to how this was achieved. They don’t mention the why, but that one is obvious if you read this carefully:

“[…] thanks to recent process enhancements, we are confident this shift will maintain our high standards for stability.”

Let’s unpack the first part of this – “recent process enhancements” – that’s likely part due to the introduction of GenAI as part of the whole development process of Chromium. The more you automate, the faster you can be with quicker loops.

And while AI isn’t automation, AI does help quite heavily with automation these days – it enables doing that in more areas in a lot less time. I am using it these days to speed up my own internal processes, so I can easily see how this can be done at Chrome-scale.

The other part that isn’t written is the fact that this speed is also available to adversaries – those who wish to find and exploit vulnerabilities in Chrome for whatever reason.

In the past two WebRTC Insights issues, we commented on aggregate 12 security vulnerabilities reported.

In all of 2025 we had only 6.

We already passed our highest year (the first, in 2021 with 17) this year, and we’re not even half way there.

The reason is obvious – using GenAI to find security vulnerabilities and patching them. This became a priority in the security arms race where both sides now use GenAI. We will hopefully end with less vulnerabilities making it to the stable version.

And since this cat and mouse game will continue playing, Google had to speed up its pace – because it is obvious they can’t plug all the holes, so better be better and more efficient in how fast these holes get plugged.

The challenge? Google has the engineering muscle to sustain this cadence, and even then, only with GenAI and Gemini at their side. Most WebRTC vendors don’t.

Do you have that engineering muscle?

What breaks when chrome ships FASTER

A change in how RTP header extension numbering, what reports get bundled together in the same packet, what kind of SDP munging is allowed, …

You never know where and when WebRTC’s implementation in Chrome is coming to bite you. This month? Janus and Amazon Chime were all in the red because of an update. Microsoft Teams and Firefox had their own incident.

Seemingly innocuous – one of these that in hindsight you’d say – “obviously, Google should have known better and announced this, tested it before updating”. But they haven’t nor is it their responsibility. Google cannot think of all edge cases and eventualities – that’s your role as an application developer for your own use cases and requirements. And now you need to think and move faster, matching Chrome’s speed of release.

In our reality, Chrome will break WebRTC apps

It isn’t a question of if – just of when.

The window of time to mitigate an issue caught even early enough has just shrunk by two weeks.

And remember – Google isn’t going to rollback a browser version just for you. And users aren’t going to go back to a previous Chrome release for you either – these days, they’ll switch a supplier faster than they would wait for you.

Praying isn’t a solution

But the moment you need access for a regular web browser, you’re at the mercy of the Chrome release train. WebRTC is used by 0.3% of the Chrome page loads. Your application breaking is the equivalent of a fly getting hit by the train.

And that Electron app with a pinned version? Bought you stability but accumulates security debt. Release cycles moving faster means debt compounds faster as well.

A better solution is needed. And the ability to run faster is becoming more important and challenging at the same time.

Infrastructure teams need to get nimbler

When things fail for you on Chrome, you must be on top of things. Running on the beta releases of Chrome might not be enough – these graduate to GA and production within two weeks time, leaving you very little time to investigate, fix and deploy breakages due to behavior changes in the WebRTC implementation in Chrome.

For many, this means aiming for Canary releases as part of your continuous testing. Not fun at all, considering the amount of false positives you might be getting running on Canary.

You should also figure out how to speed up your own release cadence for anything in your infrastructure that relates to WebRTC – especially TURN and SFU servers – but also signaling and application logic that deals with WebRTC are good candidates here. Being able to remedy and deploy in less than a week is becoming more important than ever now for WebRTC application developers.

Are you up for it?

Build vs buy, the 2 week release cycle version

CPaaS and Video API vendors have the headache of needing to quickly update their SDKs AND entice their customers to upgrade the updated SDKs as well – not an easy feat in many cases.

Which gets us to those relying on a 3rd party vendor. If you are in this camp, are you sure it will act as needed here? And once they do, are you ready to quickly update and upgrade their SDK in your own codebase and application?

No simple answers here – just more questions you need to deal with earlier.

Browsers as moving parts

This isn’t just about Chrome. Chrome is just pointing the way here. How long will it take for other browser vendors to speed up their pace of releases? Firefox had its share of security patches in recent weeks. Is that a signal of things to come or a one off investment?

Chrome’s pace is setting the floor here for the others.

While WebRTC’s standardization and specification is mostly done and stable, the implementations keep moving: housecleaning, code optimizations, security patches, introduction of new codecs and algorithms. All are changing the behavior and implementation of WebRTC in the browser – things that are uninteresting to end users, but important to developers. The end result is destabilization and the need for more testing on your part.

For you? Browser compatibility is an ongoing operational concern and not a one-time integration task.