Remote access to your Mac: every method, compared

Every method here answers one of two questions: do you want the Mac’s screen, or a shell on it? Screen methods ship pixels — they need a desktop session to capture, spend bandwidth on every frame, and on a phone hand you a 27-inch display through a keyhole. Shell methods ship text: a few kilobytes a second, fine on hotel Wi-Fi, native to a Mac mini that has never had a monitor. Most people want the screen once a month and the shell every day.

The second question is where you are. On the same Wi-Fi, every built-in method works with a switch in System Settings; from anywhere else a router stands in the way, and getting through it is its own section below.

Every built-in method assumes you can reach the Mac’s address, and on your own Wi-Fi you can. From a café, the Mac sits behind your router with a private address nobody outside can route to, and the router passes nothing in unless you tell it to. That is port forwarding: TCP 22 or 5900 from the router’s public side to the Mac, and from that moment your Mac is answering the whole internet. sshd with keys only is defensible there; VNC with a password is not.

Two more problems come with forwarding. Home connections change public address, so you need dynamic DNS to find the router at all, and a growing share of ISPs use carrier-grade NAT, where there is no public address to forward from and no setting fixes it. Apple’s answer used to be Back to My Mac, which found your Mac through iCloud from anywhere; Apple switched it off on 1 July 2019. Nothing in macOS has replaced it — the Screen Sharing app can address a Mac by Apple Account, but Apple’s guide says nothing about reaching one on another network, so do not plan a trip around it.

The honest fixes come in two families. A private network — Tailscale is the best known — puts the Mac and your other devices on a WireGuard mesh that crosses NAT without forwarding, for the price of a client on every device. Or a service in the middle — RustDesk, Chrome Remote Desktop, Jump Desktop — has the Mac dial out to a rendezvous server that brokers the connection; the router never learns, and the service becomes a party to the arrangement, which RustDesk lets you fix by running the server yourself.

If the Mac is a mini under the desk running builds, a media server, or a coding agent through the night, you do not need its pixels, and shipping them to a phone is the heaviest way to move text. Remote Login gives you the shell for free, and with keys and a named user it is safe at home. What SSH does not give you is a session that survives you: background the SSH app on the phone and the shell, and whatever was running in it, is gone unless you started it inside tmux. And it still needs a path in — the forward, the VPN, the client on every device.

spawnd is that route with the network problem and the persistence problem removed. One daemon runs on the Mac — it runs on macOS and Linux — and dials out, so nothing listens on the Mac, no port is forwarded, and no VPN is needed. Each session’s PTY is owned by a worker process on the Mac, so a session survives the closed tab, the dropped connection, the laptop lid, and a daemon restart, scrollback intact. Any browser is the console; on a phone it installs to the home screen as a web app — no client app, no keys on the device. A new device is approved once against a short code, and revoking it is one click every host honors. Your browser talks to each daemon peer-to-peer, end-to-end encrypted, and the server that introduces them never sees session content. It is open source, MIT/Apache-2.0.

It is not screen sharing and does not pretend to be — for the monthly GUI job keep Screen Sharing or RustDesk beside it. For the daily shell the Mac stops needing a hole in the router or a client on every device; if you keep Tailscale for the rest, Tailscale stuck on Starting… is the fix page for the day it hangs.