Resolving dependencies... Because livekit_client >=2.6.2 depends on flutter_webrtc 1.3.0 and livekit_components >=1.2.3 depends on flutter_webrtc 1.2.1, livekit_client >=2.6.2 is incompatible with livekit_components >=1.2.3.

Thanks for reaching out, Ahmed. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

now getting this error

livekit_client: 2.6.1
         livekit_components: 1.2.3

Thanks — I can help get this unstuck. You mentioned you switched to: •

livekit_client: 2.6.1

•

livekit_components: 1.2.3

I need a bit more detail to diagnose the new error. Please share the following: 1. The exact error text or full output from

flutter pub get

(or the build log) — paste the whole block if possible. 2. Your Flutter SDK version (

flutter --version

). 3. Your

pubspec.yaml

dependencies section (so I can see any other packages or overrides). 4. Which platforms you're targeting (iOS, Android, web). 5. Whether you added any

dependency_overrides

previously. With those I can recommend the safest fix (specific version combos, whether an override is appropriate, or other workarounds) and give exact

pubspec.yaml

edits to try.

Now I'm getting this error

Process 1490 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    frame #0: 0x00000001017434d0 Runner.debug.dylib`__postEvent_block_invoke(.block_descriptor=0x0000000134081bf0) at FlutterWebRTCPlugin.m:96:7
   93  	
   94  	void postEvent(FlutterEventSink _Nonnull sink, id _Nullable event) {
   95  	    dispatch_async(dispatch_get_main_queue(), ^{
-> 96  	      sink(event);
    	      ^
   97  	    });
   98  	}

Thanks — I can see you’re now hitting an iOS runtime crash (EXC_BAD_ACCESS) inside the FlutterWebRTC plugin at

FlutterWebRTCPlugin.m

while delivering an event to the Flutter event sink. I know that’s frustrating; let’s walk through focused troubleshooting steps so we can pinpoint the cause and get you running again. What I’m responding to • The crash happens at

postEvent(...){ dispatch_async(dispatch_get_main_queue(), ^{ sink(event); }); }

in

FlutterWebRTCPlugin.m

, which indicates a bad access when the plugin tries to call the Flutter event sink on the main thread. Quick checklist — please confirm these items • Your Flutter SDK version (

flutter --version

). • iOS deployment target in Xcode /

ios/Podfile

(e.g., 12.0, 13.0). • The exact

pubspec.yaml

dependencies (you already listed

livekit_client: 2.6.1

and

livekit_components: 1.2.3

— include any

dependency_overrides

). • Whether this crash happens immediately at app launch or after joining a room / using camera or microphone. • Whether you’re running on simulator or a physical device, and iOS version. Immediate things to try (in order) 1. Clean and rebuild (clears stale native artifacts) a. Close Xcode and the simulator/device. b. From your project root run: ▪︎

flutter clean

▪︎

rm -rf ios/Pods ios/Podfile.lock

▪︎

flutter pub get

▪︎

cd ios && pod install && cd ..

▪︎ Rebuild:

flutter run

This often fixes crashes caused by leftover native code from prior plugin versions. 1. Confirm plugin versions are consistent ◦ You’re using

livekit_client: 2.6.1

with

livekit_components: 1.2.3

.

livekit_components 1.2.3

depends on an older

flutter_webrtc

while

livekit_client

(2.6.x) expects a newer one. If you previously tried dependency overrides, they can result in native runtime mismatches. If you used an override, remove it and try a clean install (step 1). 1. If you used

dependency_overrides

to force

flutter_webrtc: 1.3.0

◦ Remove the override and try the combination that doesn’t require forcing native plugin versions. Forcing can leave native Objective-C/Swift code compiled against an API that doesn’t match runtime expectations and cause EXC_BAD_ACCESS. 1. Reproduce with a minimal app ◦ Create a new Flutter project and add only

flutter_webrtc

+

livekit_client

(or only

livekit_components

) to see whether the crash reproduces. This narrows whether the problem is interaction between packages or your app code. 1. Inspect usage of EventSink and plugin lifecycle ◦ The crash indicates

sink

is being called after it has been deallocated or when the channel is closed. If you have custom native code or are disposing LiveKit or WebRTC objects, ensure you’re not calling or holding references to an

EventSink

after the Flutter side has been destroyed. ◦ Typical cause: plugin dispatches an event after the Flutter event channel has been canceled (for example, view controller disposed). Verify that event callbacks are removed when leaving rooms or when widgets are disposed. Collect these logs if the above doesn't fix it • Full Xcode crash backtrace (open the run console in Xcode when it crashes and copy the full stack trace). • The output of

flutter run -v

up to the crash. • Any logs printed by LiveKit or flutter_webrtc before the crash. Next steps I can do for you • If you share your Flutter version, Podfile iOS target,

pubspec.yaml

, and the crash backtrace, I’ll: ◦ Check for known incompatibilities between

livekit_client 2.6.1

,

livekit_components 1.2.3

, and

flutter_webrtc

versions. ◦ Recommend an exact package version combination or Podfile changes that avoid native mismatch. ◦ Point out any lifecycle/disposal code patterns to check in your app that commonly cause

EventSink

EXC_BAD_ACCESS crashes. If you want, paste: •

flutter --version

•

pubspec.yaml

dependencies block • The full Xcode backtrace (from the Xcode debug console) I’ll analyze those and give concrete edits to your

pubspec.yaml

or code to fix this quickly.

Flutter 3.38.3 • channel stable • https://github.com/flutter/flutter.git Framework • revision 19074d12f7 (3 months ago) • 2025-11-20 175313 -0500 Engine • hash 8bf2090718fea3655f466049a757f823898f0ad1 (revision 13e658725d) (2 months ago) • 2025-11-20 201923.000Z Tools • Dart 3.10.1 • DevTools 2.51.1

Thanks — this is helpful. You're on Flutter 3.38.3 (stable), and the crash is an iOS EXC_BAD_ACCESS inside

FlutterWebRTCPlugin.m

when the plugin calls the event sink. That strongly points to a native/runtime mismatch (often caused by mixed plugin versions or calling an

EventSink

after the channel is closed). I'll help narrow this down and give exact fixes, but I need a few more pieces so I can recommend the safest change. Please paste the following: • Your

pubspec.yaml

dependencies block (exact text for the dependencies, dev_dependencies, and any

dependency_overrides

). • The iOS deployment target in

ios/Podfile

(the

platform :ios, '...'

line). • The full Xcode backtrace from the debug console (copy everything around the crash, not just the top frame). • Does the crash happen immediately on app launch, or after a specific action (joining a room, turning camera/mic on, backgrounding, etc.)? • Are you running on a simulator or a physical device? If device, which iOS version? While you collect that, try this (safe checks that often resolve EXC_BAD_ACCESS from plugin mismatches): 1. Clean native artifacts and reinstall pods: ◦ Close Xcode and any running simulator/device sessions. ◦ From your project root: i.

flutter clean

ii.

rm -rf ios/Pods ios/Podfile.lock ios/Flutter/Flutter.framework

iii.

flutter pub get

iv.

cd ios && pod install --repo-update && cd ..

v.

flutter run

1. Remove any

dependency_overrides

you added to force

flutter_webrtc

. Overrides can compile but leave mismatched native code that causes EXC_BAD_ACCESS at runtime. 2. If you used an override and need a quick repro: ◦ Create a minimal new Flutter app and add only: ▪︎

livekit_client: 2.6.1

▪︎

flutter_webrtc: 1.3.0

(or the version you forced) ◦ Run on iOS to see whether the crash reproduces; this isolates whether the issue is your app or the plugin combination. Once you paste the requested files/logs I’ll: • Check for a known version incompatibility between

livekit_client 2.6.1

,

livekit_components 1.2.3

, and

flutter_webrtc

. • Recommend a specific package-version combination (or whether to downgrade

livekit_client

or

livekit_components

) that avoids native mismatches. • Point out any lifecycle/disposal code to inspect if the crash is caused by sending events after channel cancelation. Paste the

pubspec.yaml

snippet, Podfile platform line, and the full Xcode stack trace when ready and I’ll provide exact edits and next steps.

how to add two different dependencies per platform ?

Good question — Flutter’s

pubspec.yaml

does not support declaring different package versions per platform directly. You can’t tell pub to install one dependency for iOS and a different one for Android from the same

pubspec.yaml

block. However, there are several practical workarounds you can use depending on your goal (resolve native plugin mismatches, avoid including platform-only code, or provide alternate implementations). Below are options with pros/cons and examples so you can pick the best approach for your situation. 1) Use dependency_overrides (temporary, risky) • What it does: Forces a specific version of a package for all platforms. • When to use: Short-term to test whether a particular

flutter_webrtc

version resolves your crash. • Risk: If the API or native code differs between versions, this can compile but cause runtime crashes (EXC_BAD_ACCESS). Use only for quick debugging, not as a permanent solution. • Example:

dependency_overrides:
    flutter_webrtc: 1.3.0

2) Create platform-specific packages / conditional implementations (recommended long-term) • What it does: Implement a thin abstraction in your app and provide two different platform implementations using platform channels or federation packages. • When to use: You need different native behavior or plugin versions per platform and want safe isolation. • How to do it: ◦ Create a Dart interface in your app (e.g.,

lib/webrtc_interface.dart

). ◦ Create two implementations under

lib/src/android_impl.dart

and

lib/src/ios_impl.dart

. ◦ Use conditional imports:

import 'src/impl_stub.dart'
      if (<http://dart.library.io|dart.library.io>) 'src/impl_io.dart'
      if (dart.library.html) 'src/impl_web.dart';

• Inside your iOS/Android implementations, import and call the respective plugin API. Each implementation can depend on platform-specific code via platform channels or by only referencing the plugin APIs where supported. • Pros: Clean separation, no pub dependency leak. Works robustly in production. 3) Use federated plugin or platform-aware plugin pattern • What it does: Split functionality into multiple packages (common interface + platform-specific implementations). This is how many official plugins handle platform differences. • When to use: If you are maintaining a plugin or want to upstream a robust solution. • Pros: Clean, scalable, matches community standards. • Note: Requires more setup and publishing packages if you share them. 4) Conditional imports + build-time checks (for non-plugin code) • What it does: Use

dart:io

vs

dart:html

or

kIsWeb

to pick platform-specific code paths when the same dependency is safe to include but only used on one platform. • When to use: The dependency is multi-platform but you only want to call certain APIs on one platform. • Example:

import 'package:flutter/foundation.dart' show kIsWeb;

  if (kIsWeb) {
    // web-specific code
  } else {
    // mobile-specific code
  }

• Limitation: The package still needs to be resolvable by pub for all targets. 5) Use separate Flutter apps or flavors (heavy-handed) • What it does: Maintain separate targets / flavors (e.g., iOS-only and Android-only apps) with different

pubspec.yaml

files. • When to use: Last resort for very different platform dependency needs. • Cons: Hard to maintain, duplicates project config. Practical recommendation for your current situation • Short-term: Avoid

dependency_overrides

unless you are only testing. Instead, pick a compatible pair of LiveKit packages: ◦ Downgrade

livekit_client

to the last version compatible with

livekit_components 1.2.3

, or ◦ Downgrade

livekit_components

to a version compatible with

livekit_client 2.6.1

. I can check exact compatible versions if you want — paste your full

pubspec.yaml

dependencies block and I’ll propose concrete versions. • Medium-term: If iOS-specific native behavior requires a different plugin version, implement a platform-specific abstraction in Dart and use platform channels or separate implementations to isolate iOS-only code. That avoids forcing mismatched native binaries into a single build. If you want, tell me: • Whether you need different versions only to avoid the crash on iOS, or you actually need different features per platform. • Your current

pubspec.yaml

dependencies block (so I can propose exact package versions). • Whether you tried

dependency_overrides

and what happened. I’ll then recommend the exact change (safe version pins or an abstraction pattern) and provide the snippet to apply.