Which app goes on which Mac?
Install Screen Ferry Host on the Mac you want to reach. Install Screen Ferry—the Client—on the Mac in front of you. Sign in on both and select the remote Mac from the Client.
Frequently asked questions
Start with the practical questions or go directly into display geometry, transport, performance, and endpoint security.
Getting started
Install Screen Ferry Host on the Mac you want to reach. Install Screen Ferry—the Client—on the Mac in front of you. Sign in on both and select the remote Mac from the Client.
No. Screen Ferry installs nothing privileged, places no drivers in /Library, and adds no always-on background service.
Screen Recording lets Host capture the desktop and system audio. Accessibility lets it apply authenticated remote keyboard, pointer, and scrolling input. macOS keeps both permissions under Privacy & Security.
Display and headless Macs
No. Host creates a Virtual Display for every connection. On a headless Mac, that display operates independently and gives macOS a complete desktop to lay out, capture, and control.
The connection's Virtual Display mirrors the connected monitor. This preserves the relationship with the visible desktop while giving Screen Ferry a controlled display surface for the session.
The Client communicates its viewport to Host. Host creates or selects the served display mode so macOS authors the desktop at an appropriate size before Screen Ferry captures it.
Screen Ferry can create the display at the viewer's resolution and capture it 1:1. The pixels begin at the right geometry, so sharpness does not depend on downscaling a stub or physical-monitor resolution and filtering the result.
Host disposes the connection's Virtual Display when the session disconnects. The display belongs to the connection lifecycle; it is created for the session and removed when that session ends.
Yes. Keep the remote Mac beside local work in a Client window or take it full screen. The viewport-aware display path supports both ways of working.
Connectivity and P2P
No. Host and Client both dial outward. Screen Ferry's transport opens no listening port, so the connection does not depend on control of either router.
The relay authenticates and connects the two outward-facing legs, provides immediate reachability, and carries opaque encrypted application datagrams. It also remains available as a fallback route when P2P mode is active.
Turn it on at the Host to let Screen Ferry discover, authenticate, measure, and qualify a direct path between the Macs. When direct wins, the existing session moves onto it.
No. The session is established over the relay before direct qualification begins, and the validated relay stays refreshed as fallback after a direct route activates.
No. Direct-path discovery starts outward from both ends. Screen Ferry uses simultaneous-open behavior and authenticated path challenges instead of publishing an inbound service.
The logical session lives above the carrier. A network viability change triggers new candidate gathering and route validation while the session retains its encryption and channel state. Current media continues on the viable path.
Performance
Yes. Host uses ScreenCaptureKit with a configured 60 fps cap, real-time VideoToolbox H.264 encoding, bounded media queues, hardware decode, and direct Metal presentation.
It is Screen Ferry's interactive remote-audio latency. AAC-ELD uses approximately 10.67 ms frames at 48 kHz, followed by bounded adaptive jitter handling and a real-time-safe Core Audio playback path.
A pointer should not wait for screen capture, video encode, transport, decode, and presentation. Host sends cursor state independently; Client draws and predicts it locally, then reconciles with authoritative Host state.
It favors the newest useful state. Stale video work and incomplete assemblies expire under strict bounds instead of forming a playback queue. Input, cursor, and audio also receive higher transport priority than bulk work.
Receiver reports expose RTT, loss, decode time, render pressure, freezes, and delivered bitrate. Host adjusts the running encoder without restarting it, while audio follows its own tiered link budget.
Yes. Host and Client expose stage-level signals covering capture, encode, transport, decode, rendering, audio, loss, queues, freezes, P2P qualification, and the active route.
Security and privacy
Yes. Host and Client mutually authenticate and derive application traffic keys at the endpoints. Every application datagram is sealed with ChaCha20-Poly1305 above both relay and P2P carriers.
No. The relay forwards opaque application datagrams. It does not decode Screen Ferry video, audio, input, cursor, clipboard, or control messages.
Each Mac has a Curve25519 device identity. The endpoints perform a mutually authenticated, X25519-based exchange and bind its transcript to the brokered relay session ID.
No. Application encryption lives above the carrier. The same authenticated sequence numbers, replay defense, traffic keys, and ratchet protect the session when its route changes.
ChaCha20-Poly1305 rejects altered headers or payloads. A sliding 1,024-datagram replay window accepts legitimate reordering while rejecting duplicates and packets that are too old.
No. Host-to-Client and Client-to-Host use separate direction keys, and each direction advances to new key material every 2²⁰ datagrams.
Product details
Yes. Both Host and Client are native macOS applications designed around Apple's display, capture, codec, graphics, audio, input, networking, and cryptography frameworks.
The media path uses ScreenCaptureKit, VideoToolbox, Metal, and Core Audio. Networking and cryptographic work use native Apple frameworks alongside Screen Ferry's session protocol.
Yes. Screen Ferry captures system audio at Host, carries it on its low-latency media path, and plays it through the selected Client output device.
Clipboard synchronization works in both directions for UTF-8 text, rich text, PNG, and TIFF, with size bounds and echo-loop suppression.
Install Host on the remote Mac and Screen Ferry on the Mac in front of you.