Hey Andy, I get why you're confused—there's a lot of conflicting chatter about mobile screen sharing with WebRTC out there. Let's clear this up and walk through exactly what's possible, and how to pull it off.

First, Why the Conflicting Info? #

The core split in what you've read comes down to two distinct mobile screen sharing scenarios:

• Sharing content within a mobile browser tab (like Chrome for Android): This is straightforward and well-supported, which is what the "it's possible" articles are referring to.
• Sharing the entire mobile system screen (all apps, home screen, etc.): This had strict platform limitations in the past (leading to the "can't do it" takes), but there are now workable paths—though they require some platform-specific setup.

Workable Implementation Paths #

1. Mobile Chrome Tab/Window Sharing (Most Mature) #

If your goal is to share content from a web app running in Chrome for Android, this is your easiest win:

• Use the standard navigator.mediaDevices.getDisplayMedia() API. On mobile Chrome, this prompts users to share either the current tab or the entire Chrome window.
• Pipe that media stream to your desktop browser via a WebRTC peer connection (you'll need a basic signaling server to handle peer discovery).
• For remote control: Use WebRTC's Data Channel to send control commands (like tap coordinates or swipe gestures) from the desktop to the mobile tab. The mobile web app can then listen for these commands and simulate the corresponding touch events (you'll need to add event listeners to your mobile page to handle this).

2. System-Level Mobile Screen Sharing (Requires Native Help) #

If you need to share the full mobile screen (not just a browser tab), you'll need to pair WebRTC with a lightweight native app for each platform:

Android

• Android 5.0+ has the MediaProjection API, which lets a native app capture the entire system screen. Build a simple Android app that uses this API to grab the screen stream, then push it to your browser via WebRTC.
• For control: The native app can listen for commands sent over the WebRTC Data Channel, then use Android's AccessibilityService or InputManager APIs to simulate touch events system-wide. Note: Users will need to grant your app screen capture and accessibility permissions, and some custom Android ROMs might add extra hoops.

iOS

• iOS restricts system-level screen capture to the ReplayKit framework, so you'll need a basic iOS native app to capture the screen stream and send it via WebRTC to the browser.
• Remote control is trickier here: iOS blocks third-party apps from simulating system-wide touch events. You can only implement control if you're sharing a custom app you built (add logic to listen for WebRTC commands and trigger actions within the app), or use limited workarounds like Shortcuts (which aren't ideal for smooth control).

Browser-Side Handling #

No matter which mobile sharing method you pick, the browser side works similarly:

• Receive the WebRTC media stream and render it in a <video> element.
• Capture mouse/touch events on the desktop, convert the coordinates to match the mobile screen's resolution, and send those commands over the WebRTC Data Channel to the mobile side.
• For desktop browsers, you can use Chrome extensions or Firefox's media.getDisplayMedia.enabled flag (set via about:config) to optimize stream reception, but the core WebRTC logic stays the same.

Key Misconceptions to Avoid #

• Don't mix up browser tab sharing vs. system screen sharing: The former needs no native code, the latter requires it (web APIs can't access system-level screen permissions).
• Older "can't do it" claims are out of date: WebRTC and mobile platform APIs have evolved, making system-level sharing (with native help) feasible now.

内容的提问来源于stack exchange，提问作者Andy Galway