# How to Add Screen Sharing to Your App (Copy-Paste Prompts Included) - Tool: App Features - Last updated: July 2026 ## TL;DR Screen sharing requires three pieces: the browser Screen Capture API (getDisplayMedia) to capture the display, WebRTC (RTCPeerConnection) to stream it peer-to-peer, and a signaling channel (Supabase Realtime) to coordinate the handshake. With Lovable or V0 you can get a working prototype in 1-3 days, but the WebRTC peer logic always needs manual review. Running costs range from $0 at small scale to $200-600/mo at 10,000 users when a managed WebRTC service becomes mandatory. ## What Screen Sharing Actually Requires Screen sharing in a web app is not a single API — it is a chain of four cooperating systems. The browser's Screen Capture API (getDisplayMedia) captures a MediaStream of the user's display. WebRTC's RTCPeerConnection negotiates and streams that video to one or more viewers via STUN/TURN-mediated peer connections. A signaling channel (typically Supabase Realtime Broadcast) shuttles the SDP offer/answer and ICE candidates between peers during the handshake. And a session management layer tracks who is sharing, who is watching, and when the session ends. AI tools generate the UI shell and Supabase signaling reliably; the RTCPeerConnection wiring is where every first build breaks. ## Anatomy of the Feature Six components in total. The signaling channel and session UI generate reliably with AI tools. The WebRTC peer connection and screen capture layer are where builds consistently break on first attempt. - **Screen capture layer** (ui): Calls the browser-native MediaDevices.getDisplayMedia() API with video constraints ({ video: { cursor: 'always' }, audio: false }) to produce a MediaStream of the selected display surface. Must be triggered inside a direct user gesture (onClick), not in a useEffect or timer. - **WebRTC peer connection** (backend): RTCPeerConnection manages the peer-to-peer video channel. The sharer creates an RTCPeerConnection, adds the MediaStream tracks, and creates an SDP offer. The viewer creates its own RTCPeerConnection, receives the offer, creates an answer, and both sides exchange ICE candidates. Uses public STUN servers (stun.l.google.com:19302) for NAT traversal and Twilio TURN for users behind corporate firewalls. - **Signaling channel** (backend): Supabase Realtime Broadcast channel (named by room_id) exchanges SDP offers/answers and ICE candidates between sharer and viewer during the WebRTC handshake. Broadcast is used (not INSERT) because signaling messages are ephemeral and do not need persistence. - **Session management UI** (ui): React component built with shadcn/ui Dialog (for pre-share confirmation) and Badge (sharing status indicator). Manages the UI state machine: idle → requesting-permission → sharing → stopped. Shows active viewer count sourced from Supabase Realtime presence or the viewers table. - **Recording layer (optional)** (service): The MediaRecorder API can capture the MediaStream locally to a Blob, then upload to Supabase Storage for cloud persistence. For managed cloud recording, Daily.co and Livekit Cloud both offer built-in record features at approximately $0.004/min recorded. - **Permissions guard** (ui): Checks MediaDevices.getDisplayMedia support before showing the share button. On permission denial, catches the NotAllowedError and surfaces a friendly explainer with a retry button rather than letting the error propagate to a blank state. ## Data model Screen sharing needs two tables: sessions tracks active and past sharing sessions, and viewers records who joined each session. Run this SQL in the Supabase SQL editor (Dashboard → SQL Editor): ```sql create table public.screen_sessions ( id uuid primary key default gen_random_uuid(), host_user_id uuid references auth.users(id) on delete cascade not null, room_id text not null unique default gen_random_uuid()::text, started_at timestamptz not null default now(), ended_at timestamptz, viewer_count integer not null default 0, status text not null default 'active' check (status in ('active', 'ended')) ); create table public.screen_session_viewers ( id uuid primary key default gen_random_uuid(), session_id uuid references public.screen_sessions(id) on delete cascade not null, user_id uuid references auth.users(id) on delete cascade not null, joined_at timestamptz not null default now(), left_at timestamptz, unique (session_id, user_id) ); alter table public.screen_sessions enable row level security; alter table public.screen_session_viewers enable row level security; create policy "Host can manage own sessions" on public.screen_sessions for all using (auth.uid() = host_user_id) with check (auth.uid() = host_user_id); create policy "Any authenticated user can view active sessions" on public.screen_sessions for select using (auth.role() = 'authenticated'); create policy "Viewers can insert own join record" on public.screen_session_viewers for insert with check (auth.uid() = user_id); create policy "Viewers can see participants in a session" on public.screen_session_viewers for select using (auth.role() = 'authenticated'); create policy "Viewers can update own leave record" on public.screen_session_viewers for update using (auth.uid() = user_id); create index screen_sessions_room_id_idx on public.screen_sessions (room_id); create index screen_session_viewers_session_idx on public.screen_session_viewers (session_id, joined_at desc); ``` The room_id column is what both peers subscribe to on the Supabase Realtime Broadcast channel. Generate it server-side when the host starts a session and share it with viewers via an invite link or in-app notification. ## Build paths ### Lovable — fit 2/10, 1-2 days + manual wiring Lovable handles the UI shell, Supabase session tables, and the Realtime signaling channel setup. The RTCPeerConnection logic must be written manually in a client-side component because AI frequently generates async/await patterns that violate the trusted-gesture requirement for getDisplayMedia. 1. Create a new Lovable project with Lovable Cloud enabled so Supabase auth and the sessions table are provisioned automatically 2. Paste the prompt below; Lovable will generate the session UI, the Supabase schema, and the Realtime Broadcast channel subscription 3. After generation, manually review the getDisplayMedia call — move it into an explicit onClick handler if Lovable placed it in a useEffect 4. Publish the project (do not test in preview — getDisplayMedia is blocked in the preview iframe) 5. Open the published HTTPS URL in two browser tabs and verify the signaling handshake completes Starter prompt: ``` Build a screen sharing feature for a web app. Schema: create a screen_sessions table (id, host_user_id, room_id, started_at, ended_at, viewer_count, status) and a screen_session_viewers table (session_id, user_id, joined_at, left_at) in Supabase with RLS — host manages own sessions, authenticated users can read active sessions and insert their own viewer row. UI: A 'Share Screen' button that calls navigator.mediaDevices.getDisplayMedia({ video: { cursor: 'always' }, audio: false }) inside an async onClick handler (never in useEffect). Show a state machine: idle state shows share button, requesting-permission state shows spinner, sharing state shows a red 'Sharing active' banner with viewer count and a 'Stop sharing' button, stopped state returns to idle. Stop sharing by calling stream.getTracks().forEach(t => t.stop()) and updating session status to 'ended'. Signaling: use a Supabase Realtime Broadcast channel named by room_id to exchange JSON messages of type 'sdp-offer', 'sdp-answer', and 'ice-candidate'. RTCPeerConnection iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]. Viewer page: subscribes to the room's Broadcast channel, receives the SDP offer, creates an answer, attaches the remote stream to a