flutter-webrtc: real peer connections in Flutter, and the platform gaps you inherit

What the platform table actually commits to

The README leads with a feature matrix, and it is the most useful thing in the document because it tells you where the plugin stops. Audio and video, data channel, screen capture, Unified Plan, and simulcast are all checked for Android, iOS, web, macOS, Windows, Linux, and the Embedded column that points at Sony's flutter-elinux project.

Then the gaps. MediaRecorder is marked with a warning symbol on Android and iOS and checked only on the web, which is the opposite of what you might expect and is worth knowing before you plan offline recording on a phone. End to end encryption is checked across all seven targets, including desktop. Insertable Streams is an empty row, meaning no platform supports it.

The Fuchsia column is blank in every row, so despite Fuchsia having its own link in the table header, there is no support to speak of. Additional platform coverage comes from the community rather than this repository: flutter-tizen carries a fork of the plugin in its plugins tree, and flutter-elinux is marked work in progress.

Screen capture on iOS carries a footnote link to a dedicated wiki page, which signals that iOS screen sharing is the least uniform of the seven.

Two details about the native layer explain why the matrix looks the way it does. The plugin is written in C++, with a common directory for shared Dart-facing code and per-platform directories for android, ios, macos, linux, windows, elinux, and third_party, where the prebuilt libwebrtc binaries live.

Adding the dependency is one line, everything else is native configuration

Adding flutter_webrtc to pubspec.yaml is the easy part, and then the README becomes a platform checklist. On iOS and macOS you add camera and microphone usage strings to Info.plist:

<key>NSCameraUsageDescription</key>
<string>$(PRODUCT_NAME) Camera Usage!</string>
<key>NSMicrophoneUsageDescription</key>
<string>$(PRODUCT_NAME) Microphone Usage!</string>

Android needs a longer list in AndroidManifest.xml, and this is the part that catches people moving from another plugin:

<uses-feature android:name="android.hardware.camera" />
<uses-feature android:name="android.hardware.camera.autofocus" />
<uses-permission android:name="android.permission.CAMERA" />
<uses-permission android:name="android.permission.RECORD_AUDIO" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" />
<uses-permission android:name="android.permission.MODIFY_AUDIO_SETTINGS" />

If you route audio through a Bluetooth headset, two more permissions are needed, both capped at API level 30 with maxSdkVersion set on them.

There are also two build settings that will fail the build if you miss them. Java 8 is required because the official WebRTC jar uses static methods in the EglBase interface:

android {
    //...
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

And you may need to raise minSdkVersion in defaultConfig from the Flutter default of 16 to 23. For release builds there is one more step: apply the ProGuard rules the repository ships, since without them the release APK can break in ways a debug build will not show you.

Swift Package Manager on Apple platforms, CocoaPods as the fallback

The plugin supports both Swift Package Manager and CocoaPods on iOS and macOS, and the README is clear about how that resolves. With Flutter 3.44 or later, Swift Package Manager is enabled by default and the plugin is consumed as a Swift package automatically, with no project changes needed.

CocoaPods stays fully supported and is used when Swift Package Manager is off or when you are on an older Flutter version. That distinction matters because the remaining CocoaPods instructions apply only to those projects, and following them unnecessarily on a current setup is a common source of confusion.

The one CocoaPods-specific requirement is a workaround for iOS arm devices. The README states that the WebRTC.xframework compiled after the m104 release no longer supports iOS arm devices, so the Podfile needs ONLY_ACTIVE_ARCH set to YES:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)
     target.build_configurations.each do |config|
      # Workaround for https://github.com/flutter/flutter/issues/64502
      config.build_settings['ONLY_ACTIVE_ARCH'] = 'YES' # <= this line
     end
  end
end

That is a legacy device constraint, not a choice the plugin makes, so if you are shipping to the App Store today it mostly matters for older hardware and for verifying your build still resolves.

Three releases in eight days, all about letting things go

The three most recent releases tell you more about the state of this plugin than any feature list. Version 1.6.2+hotfix.1 on 2026-09-08, +hotfix.2 on 2026-09-14, and +hotfix.3 on 2026-09-15 all fix the same category of problem, and it is disposal.

The first hotfix guards a null cameraName before a reuse check in getUserMedia on Android, fixes a resource leak on Darwin by releasing event channel stream handlers, and adds a check that the WebRTC API is not accessed before calling EnsureWebRTCInitialized. Two contributors made their first contributions in that release.

The second hotfix is almost entirely lifecycle. It keeps the PeerConnection observer alive during disposal on desktop, releases event channel handlers on dispose on Darwin, releases data channel event handlers on Android, and closes data channels when disposing a peer connection.

The third stops leaking every platform view that is disposed on Darwin and bumps libwebrtc for Windows and Linux to fix WARP.

Read together, that is a plugin whose users were finding that video calls, especially repeated ones, accumulated leaked views and unreleased handlers. For a library that wraps native peer connections across seven platforms, disposal bugs are the failure mode you cannot patch from Dart, so these fixes required native changes on Darwin, Android, and desktop. The repository's last push was on 2026-09-22, a week after the last hotfix.

A plugin with 706 open issues and a very active contributor base

The open issue count is 706, which is large next to the release cadence, and it deserves a direct reading rather than a reassuring one. A plugin that spans Android, iOS, web, macOS, Windows, Linux, and an embedded target accumulates issues faster than any single maintainer can close them, and each upstream libwebrtc bump can reopen behaviour that used to work.

What the releases show is that contributions are landing from outside the core team. The September 2026 hotfixes credit contributors including realdev-fr, dev-ahmedhany, hiroshihorie, gfx, and cloudwebrtc, with two first-time contributors in a single release. The README says the project is inseparable from the contributors of the community and names CloudWebRTC among the projects in that group.

The topic list includes sip and voip alongside the expected webrtc, flutter, and platform tags, which tells you what the plugin actually gets used for: SIP gateway and softphone work as much as video calling. That is a different and more demanding usage profile than a demo app, because a SIP stack has long lived calls and reconnection behaviour.

The repository also carries renovate.json for dependency updates, analysis_options.yaml for linting, a format.sh script, a Documentation directory, and a NOTICE file alongside the MIT LICENSE. The example directory has a full app with per-platform folders for android, elinux, ios, linux, macos, web, and windows, which is the fastest way to see a working getUserMedia and peer connection call before writing your own.

Where the plugin stops and your signalling server begins

The honest limit of this project is that it is a transport, not a call system. It gives you a peer connection, media tracks, data channels, and screen capture. It does not give you room assignment, identity, TURN credentials, or a place to exchange SDP offers and answers. That work lives in whatever signalling and SFU you pair the plugin with, and choosing that layer is usually the larger architectural decision.

The README gives you a hint about how the maintainers expect you to handle it, because the sponsor block points at LiveKit for open source WebRTC and realtime AI infrastructure, and Stream for enterprise chat and video APIs. Both are complete platforms that sit beside this plugin rather than inside it. Neither is required, and neither is endorsed as the only option, but they tell you the shape of a working integration.

That distinction also explains the release notes. Most of the recent work is native correctness inside libwebrtc bindings rather than feature additions, which is what you would expect from a layer whose job is to make a proven native stack behave correctly on every platform Flutter targets. The feature table, the platform-specific setup, and the hotfix history all point the same way: this is plumbing, and its value is in being dependable.

Before you commit, read the feature matrix for your target platform specifically, since the MediaRecorder and Insertable Streams rows already tell you that the matrix is not uniformly green. Then work through the native setup for that platform, since the plugin cannot configure your app's permissions for you.

Editorial conclusion

flutter-webrtc is what you reach for when a Flutter app needs a real peer connection rather than a video player, and the plugin earns that place: audio and video, data channels, simulcast, Unified Plan, and screen capture across Android, iOS, the web, macOS, Windows, and Linux. The catch is written into the README's own feature table, where MediaRecorder is marked as a warning on both mobile platforms and Insertable Streams is marked unsupported everywhere. You also have to do native setup work the pubspec dependency does not cover: camera and microphone keys in Info.plist, seven permissions in the Android manifest, Java 8 compile options, a minSdkVersion floor of 23, and ProGuard rules for release builds. Read the table for your target platform before planning the feature set, and pin a version deliberately, because three of the most recent releases are hotfixes for disposal leaks.

Frequently asked questions

Official sources

1. flutter-webrtc/flutter-webrtc on GitHub
2. Issues
3. License: MIT
4. README
5. Releases