oficina / meet Public

Share a screen from the Mac app

The browser has shared screens since slice 4. The Mac app now does too,
and sends one exactly as the browser does, because the browser is who
receives most of them: one sendonly transceiver per connection, in a
stream of its own, added last so it takes an m-line of its own after the
camera's, and announced with `share {on:true}` once it is on every
connection. Stopping stops the transceiver and renegotiates, so the far
side's track ends rather than freezing on its last frame, and then says
`share {on:false}`.

The framework's transceiver stop is the immediate kind: it stops, and
unlike the browser's stop() it does not raise negotiation-needed. So the
offer that tells the far side is asked for by hand, and owed until the
connection is next stable if it is mid-exchange when asked. A screen
transceiver is only ever added to a stable connection, and the deferred
ones are added when it settles, for the reason the browser's mutualshare
gate found: added mid-negotiation, it is unassociated when the far
side's offer arrives and gets handed an m-line meant for something else.

The picker is SCContentSharingPicker, which is macOS 14 and the app's
floor. What a person picks there is content they have agreed to share,
so the app asks for no Screen Recording permission, needs no Info.plist
key (there is no usage string for screen capture), sends nobody to
System Settings, and keeps working in the sandbox the App Store build
will need. Calls' own windows are kept out of the picker, and out of a
shared display too on macOS 14.4 and later: the display is rebuilt as
the same display excluding this application, found through the current
process's own shareable content — the one query that needs no
permission. Excluding the application rather than a list of windows
keeps out the ones that open later, the floating mini window on
feat/mac-mini-window among them. Before 14.4 the display is shared as
picked, and says so.

The menu bar's stop control and a shared window closing end the share
through the same path as the button. The source is marked a screencast,
so WebRTC gives up frame rate before resolution; frames are capped at
1920 on the long side and thirty a second.

The native gate now shares both ways against a real browser: the app
shares a synthetic screen, the browser must caption it with the app's
name and decode it beside the app's camera, and then see its received
track *end* — once by the button and once by the capture ending on its
own. Its timeout goes from three minutes to five, the interop's lifetime
and the test's context with it; chat moved ahead of the screen
scenarios, because it is not replayed across the ten-second renewals
and a minute of screens put it among them.

`make native-pair` is new: two apps in one call and no browser, with a
screen shared before the other app joined, both endings, and both apps
sharing at once. It is not in native-browser because two apps on one Mac
do not reliably connect at all, before anything is shared and with
main's binary as well as this one's: about two runs in five fail with
signalling complete and in order, every candidate added on both sides,
and no connectivity check answered. The macOS firewall is on here and
the interop binary is unsigned, which fits; allowing it through needs an
administrator, so that is a reading and not a proof. Every run that
connected passed.

Gates: swift test (41), make native-mac, the iPhone simulator build,
make native-browser (all three tests pass), make native-pair (3 of 4
full passes, the fourth the connection failure above).

Not verified: the real picker, a real display or window, the menu bar's
stop control, and the exclusion of Calls' windows from a real display —
none of which a headless gate can reach.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>