Remote clients | MoreDisplays

MoreDisplays does not stream anything. It makes the display your client streams from. What your client can do with it varies a lot, and this page is what we know from testing.

Screen Sharing Built into macOS

Always there, always works

Handles any display size and scales to the client window. Negotiates a conservative frame rate, so expect 30 to 60 whatever the display is set to. The client to reach for when something else is broken.

Nothing to change.
Jump Desktop Fluid mode

The fast one on a local network

The client most likely to make a high refresh rate worth setting. Fluid mode genuinely reaches high rates over a local network, which is where a 120 Hz display stops being theoretical.

Turn off automatic resolution, or it fights protection.
VNC Any standard viewer

Works from anything

Point any VNC viewer at the built in server. Low frame rate and poor colour, but it needs nothing installed on the machine you are sitting at, which is exactly what you want when something else has gone wrong.

Nothing to change.
Screens Edovia

Leaves the display alone

Respects whatever the display already is and never requests a change, which makes the whole setup easy to reason about. Frame rate is similar to Screen Sharing, since it rides the same transport on macOS.

Nothing to change.
Apple Remote Desktop Apple

Administering a fleet

Same underlying transport as Screen Sharing, aimed at watching many machines rather than working on one. A launch group at a modest resolution is what makes a rack of Macs actually observable from it.

Give every machine the same launch group.
Parsec Low latency streaming

The lowest latency tested

Built for input latency rather than colour accuracy. The highest frame rates of anything tested on a good local link, and worth its own group at a size it can carry comfortably.

Turn off automatic resolution, same as Jump Desktop.

MoreDisplays does not know your client

Worth saying plainly, because it shapes everything below: the app has no idea which client is connected, or from where. There is no rule engine, nothing watches for a connection, and no group is chosen automatically on your behalf.

What that means in practice is that the pairing between a client and a group is something you make: a keyboard shortcut you press, a URL a Stream Deck key opens, or one mdctl command your client runs over SSH as it starts.

The one that is already there and needs no licence.

Resolution. Handles any size. It scales to the client window rather than changing the display, so pick a display size close to the window you will use it in.
Refresh. Negotiates conservatively. Expect 30 to 60 in practice, whatever the display is set to. It is not a client for high refresh work.
Colour. No colour management worth relying on. Fine for administration, not for grading.

Best for: administering the machine, and as the client that always works.

It is also the one to test with first. If Screen Sharing cannot see the display, no other client will either, and the problem is the display rather than the client.

Jump Desktop

Fluid mode is the reason to use it.

Resolution. Can request a display size on connect. Turn off automatic resolution in the client and let the group own the display.
Refresh. Genuinely reaches high rates on a local network. This is the client most likely to make 120 Hz worth setting.
Colour. Better than Screen Sharing. Still not a reference path.

Best for: everyday remote work where responsiveness matters.

Screens

Resolution. Respects whatever the display is. Does not request changes.
Refresh. Similar to Screen Sharing, since it uses the same underlying transport on macOS.
Colour. As Screen Sharing.

Best for: a well behaved client that leaves the display alone, which makes it easy to reason about.

Plain VNC

Any standard VNC viewer against the built in server.

Resolution. Whatever the display is. No negotiation.
Refresh. Low. VNC is not a high frame rate protocol.
Colour. Depends entirely on the viewer, and usually poor.

Best for: emergency access from a machine where you cannot install anything.

Apple Remote Desktop

Apple’s own fleet management tool, on the same underlying transport as Screen Sharing.

Resolution. Whatever the display is. It does not negotiate.
Refresh. As Screen Sharing. It is built for administering machines, not for working on one.
Colour. As Screen Sharing.

Best for: watching over a rack of Macs. The thing that makes a fleet actually observable from it is giving every machine the same boot group at a modest resolution, so the thumbnails are readable and the login window is always somewhere.

Parsec

Resolution. Requests a display size on connect. Same conflict as Jump Desktop, same fix.
Refresh. The highest of anything tested, on a good local link.
Colour. Tuned for latency, not accuracy.

Best for: anything where input latency is the thing you care about.

A pattern that works

One group per desk, and one shortcut per group.

$ mdctl list
Home
Office
MacBook Air 13-inch (M1)

Give each group a shortcut you can press from inside a screen sharing session, and keep one that is deliberately boring: a single display at 1920 by 1080 and 60 Hz, with HiDPI off. That is the setup most likely to render on any client you own, and it is what you fall back to when something else goes wrong.

For the clients that can run a command as they connect, have them do it:

$ ssh -o BatchMode=yes rack-mini.local mdctl activate Office
Activated "Office".

Over a VPN or an overlay network

Tailscale, WireGuard and a traditional VPN all work, and none of them are visible to MoreDisplays at all. The app makes a display; how your client reached the machine is between your client and your network.

The one thing worth knowing is that mdctl over SSH behaves identically over any of them, so the “run a command as you connect” pattern above needs nothing special. Tailscale in particular is a good fit here, because it gives the machine a stable name to SSH to whichever network you happen to be on.

Switching without the window for shortcuts, the URL scheme and the CLI.
Troubleshooting when a client connects to a black screen.