VNC vs SSH for Remote Mac: Which to Use Guide

The short answer

Use VNC for anything that needs the macOS display — Xcode's organiser, Simulator, Sketch, System Settings. Use SSH for command-line builds, file transfers, and CI agent registration. For a persistent developer workstation, run SSH as the transport and tunnel VNC through it. The two protocols serve different layers of the same job.

What VNC gives you that SSH cannot

VNC is the Remote Framebuffer protocol standardised in RFC 6143. It streams the host Mac's screen as a framebuffer and relays keyboard and mouse events back. You see the full macOS desktop — Finder, Dock, every GUI app — as the host renders it.

Capabilities that only work over VNC:

• GUI applications. Xcode's graphical scheme editor, Instruments, Simulator, Figma desktop, Sketch — anything that opens windows needs a display server. SSH does not expose one.
• System Settings navigation. Accessibility, display colour profiles, user account creation and TCC privacy prompts are not reliably driven by defaults write alone.
• Screen recording and client demos. QuickTime on the host captures the real display; the client needs nothing extra.

VNC listens on TCP 5900 by default, with additional displays on 5901, 5902, and so on. Its built-in authentication is a DES challenge-response with the password truncated to 8 characters. RFC 6143 states this method "is known to be cryptographically weak and is not intended for use on untrusted networks" and recommends running the session over IPsec or SSH. Never expose 5900 directly to the internet.

What SSH gives you that VNC cannot

SSH (see OpenBSD ssh(1)) opens an encrypted channel to a remote shell. Anything a terminal can do, SSH can do remotely with almost no overhead.

Capabilities that SSH does far better than VNC:

• Fast builds and automation. xcodebuild, fastlane, brew, and package installs run at line speed. A VNC session would add display rendering latency to every line of output.
• File transfer. scp, rsync -az, and SFTP all layer over SSH. Push a 2 GB asset or sync a font library with one command; VNC clipboard paste is not designed for binary payloads.
• CI agent registration. GitHub Actions self-hosted runners and Buildkite agents connect outbound over HTTPS. You register and start them in a terminal SSH session; no display is required.
• Port forwarding. The -L flag tunnels a local port to any port on the host through the encrypted channel, including VNC's 5900.

Latency and bandwidth compared

The numbers above are rough planning figures, not benchmarks. VNC uses demand-driven updates: the client requests a framebuffer update and the host returns only the changed rectangles. ZRLE and TRLE encodings compress those further. Even so, a 4K display during active design work is expensive — switch the client to 256-colour or grayscale mode on a slow link and close video-playing tabs on the host. SSH's overhead for text-only workloads is negligible; your network RTT dominates.

Security model: wrapping VNC inside an SSH tunnel

The safe production pattern is SSH for transport, VNC for display. Open the tunnel first, then point your VNC client at localhost:

# Replace USER, HOST with your rental credentials
# -N: do not execute a remote shell
# -L: forward local port 5901 to the host's port 5900
ssh -N -L 5901:localhost:5900 USER@HOST

Leave that terminal running and connect your VNC client to localhost:5901. All VNC traffic travels inside the encrypted SSH channel, and 5900 on the host does not need to be reachable from the internet.

Add -f to send the tunnel to the background:

ssh -f -N -L 5901:localhost:5900 USER@HOST

To close the background tunnel: kill $(lsof -ti tcp:5901).

For convenience, add a Host block to ~/.ssh/config:

Host mymac
    HostName HOST
    User USER
    LocalForward 5901 localhost:5900
    ServerAliveInterval 60

Then ssh -N mymac opens the tunnel in one command. Flag behaviour is documented in the OpenBSD ssh(1) manual.

Decision matrix: 7 workflow types

Quick-start clients on macOS, Windows, and Linux

macOS client (built-in):

1. In Terminal: ssh -N -L 5901:localhost:5900 USER@HOST
2. Finder → Go → Connect to Server → vnc://localhost:5901
3. Enter the Screen Sharing password set on the host.

Windows client:

1. Use the built-in OpenSSH (Windows 10 and later) or install PuTTY.
2. In PowerShell or Windows Terminal: ssh -N -L 5901:localhost:5900 USER@HOST
3. Open RealVNC Viewer or TigerVNC and connect to localhost:5901.

Linux client:

1. ssh -f -N -L 5901:localhost:5900 USER@HOST
2. vncviewer localhost:5901, or use Remmina with the address vnc://localhost:5901.

Picking the right Figment plan for this workflow

Access path matters more than protocol preference when you choose a plan at Figment Mac hosting:

• Virtual Intel macOS, $29/month. Reached through a browser console. It runs a real macOS desktop and compatible Intel toolchains, including Xcode 26 or earlier, so you can edit, build, and sign supported targets inside the console session. It does not currently publish an inbound SSH listener or a public VNC port, so the SSH-tunnelled VNC flow above does not apply to this tier. Pick it for lightweight Intel builds and ad-hoc GUI work inside the browser.
• Physical i3 Mac, $49/month, and M-series from $95/month. Request-based while we confirm supply. Confirm in the quote that inbound SSH and Screen Sharing are enabled on the delivered host, the exact macOS version, and — for M-series — the chip, RAM, and disk you need for ARM execution, Simulator fleets, or GPU work.

Start a request at /mac-hosting/start and mention which protocols you need enabled; we will match the host and OS image to your workflow before billing starts.

Related guides:

• macOS dev-class remote desktop setup
• Remote Mac contractor onboarding
• Self-hosted GitHub Actions runner on Mac