Questions

Yes. There is a signed, notarised disk image on the download page, and the app works: groups, the catalogue, activation, protection, HDR, iCloud sync and the menu bar are all there.

What is worth knowing is which parts have been proven on a real Mac rather than only against test fakes.

Checked by hand on hardware. Activating a group, with the displays appearing at the requested resolution and position. Switching straight to a second group, with no moment where the machine has none. Deactivating. Creating and releasing a real 5120 by 1440 virtual display through the private interface.

Not yet. A cold boot with activate-on-launch, sleep and wake, hotplugging a monitor while a group is active, and a crash with virtual displays alive.

None of those stop the app launching or leave you without a screen: a failed switch rolls back, and a failed rollback releases every virtual display and puts a physical one back as main. But if you are about to put a Mac somewhere you cannot walk to, try a sleep cycle and a reboot yourself first.

One thing genuinely missing from the build: the mdctl command line tool is a separate binary and is not inside the disk image yet. The CLI reference documents it because it exists and works, and the download page says plainly that you cannot have it from this download.

A dummy plug advertises one fixed set of modes, chosen by whoever made the plug, forever. To change what your Mac offers you walk to it and swap the plug, which is the one thing you cannot do with a machine in another building.

MoreDisplays makes the display in software, so the resolution, the refresh rate, the rotation and the arrangement are all things you change from a menu, a keyboard shortcut or one SSH command. It also frees the port, and it lets you keep several complete setups and switch between them.

The honest comparison: a plug is cheaper, needs no software, cannot be broken by a macOS update, and works before you log in. This app does none of those, and does everything else. Plenty of people end up using both, with the plug covering the login window and the app covering the rest.

Not in version 1.6. Keep a dummy plug for that window if your Mac must be reachable there after a cold boot with nothing attached.

The reason is structural: MoreDisplays is an ordinary app in your user session. It creates its displays when it launches and releases them when it quits, and before you log in it is not running.

Covering that window needs a service running as root from boot, and the app now ships one. It installs from a switch in Settings, macOS asks you to approve it, and mdctl status reports what state it is in from the far end of an SSH session. What it does not do yet is the last step: actually presenting a display at the login window. Until it does, there is nothing to gain from switching it on.

In practice this matters less than it sounds, because most machines like this either log in automatically or stay logged in and only the screen sharing session comes and goes.

Displays at the login window has the detail.

Not by itself. There is no rule engine: nothing watches for a client connecting, from a network or with a particular piece of software, and picks a group in response.

Build it from the outside instead. The client is the thing that knows it is connecting, so have it run one command as it starts:

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

Or give the group a keyboard shortcut and press it once you are in. A shortcut arrives through a screen sharing session, which is the one way to switch from a client with no terminal.

The recipes page has the script.

You can do all the switching, and none of the editing.

mdctl has ten commands. status, list, displays and edid inspect. activate and deactivate switch. capture writes the live arrangement back into a group, and protect marks a display whose resolution should be put back. help and docs describe the tool itself.

Creating a group, adding a display or choosing a resolution happens in the window, on purpose: those are choices, and the tool exists to apply choices rather than make them.

There is no --json. The output is plain text: list prints one name per line, which is the only shape a shell needs, and status prints four labelled lines in a fixed order. Parse those with sed, and branch on the exit code rather than on the success sentences, which are written for people and may be reworded.

The CLI reference has every command, and the recipes page has complete scripts.

There is no installer, so there is not much to undo: quit the app, delete the bundle, remove the mdctl symlink if you made one, and delete the support directory. If you switched the login window service on, turn it off first, while the switch that installed it is still there.

The two parts people miss are the support directory, which holds your groups and every dated backup, and the copy of the library in your iCloud if sharing was on. Turn sharing off before you delete anything, or the deletion is a local absence with nothing to record it.

The uninstall guide lists each step with the command and what a clean result looks like.

Start from the client’s own panel, in pixels, and let the catalogue do the work: pick the iPad Pro or the MacBook from the template picker and the numbers arrive correct.

Typing them yourself, the field that catches people is HiDPI. The Pixel Size field is the native framebuffer, and the HiDPI toggle decides whether macOS also offers the 2x modes derived from it. Define a 2560 by 1440 panel with HiDPI off and you get a 1440p desktop; define 5120 by 2880 with HiDPI on and you get the same desktop, sharp.

This is the opposite way round from how System Settings presents resolutions, which describes a Retina display as “looks like 2560 x 1440” while the panel is 5120 x 2880. MoreDisplays asks for the panel.

Virtual displays has a table of starting points.

Yes, and it will not fight the monitor unless you ask it to.

Each group has an Include physical displays switch. With it off, the group is about its virtual displays only and a connected monitor is left exactly where it is. With it on, the monitor takes part in the arrangement and can even be the group’s main display.

Whether it is worth it is a different question. If you sit in front of a physical monitor and never connect remotely, this app solves a problem you do not have. Its reason to exist is machines you reach from somewhere else.

There is no hard limit in the app. The practical limit is what the machine can composite and what your client can stream.

A handful is comfortable. A dozen is not, and the failure looks like stutter rather than an error message, which makes it easy to talk yourself into thinking it is working.

High refresh rates multiply the cost per display, and a very large panel costs more than a small one at the same rate. Build up rather than down: add a display, connect, check it feels right, then add another.

A bundled list of 38 real panels, so a display can be defined by naming the thing it is meant to be rather than by typing numbers.

It covers Apple’s external displays, MacBook and iMac panels, iPads, and the common formats nobody sells under one name, such as 21:9 and 32:9 ultrawides. Each entry carries the vendor, the year, the diagonal, the native pixel size, the refresh rates the panel offers and whether it does HiDPI. 28 of the 38 are marked verified, meaning the numbers were checked against the real panel rather than a specification sheet.

Picking an entry copies its numbers into a new display and records where they came from. It is a copy, not a link, so editing afterwards does not fight the catalogue.

For a panel that is not in it, the app asks three questions instead: what shape (a ratio), how many pixels, and how big on the desk. Templates and the catalogue covers both.

Sometimes, and three things have to line up. Only the first is up to this app.

1. The display has to run at that rate. That part is easy.
2. The compositor has to produce frames that fast. macOS will, when something is actually drawing. An idle desktop does not, and that is not a fault.
3. The client and the link have to carry them. This is where it usually stops. Screen Sharing rarely commits to 120. Jump Desktop and Parsec do reach it on a good local network. Over the public internet, plan for 60.

Setting a high rate costs nothing when the client cannot use it. It only means the display is not the ceiling.

23.976 is shorthand for 24000/1001, which is 23.976023976 and so on forever. 23.98 is that number rounded to two places, which is a different number.

Run a 23.976 timeline against a display genuinely at 24.000 and it drifts by one frame every 1001 frames, roughly three and a half seconds an hour. On a long session that is the difference between audio staying in sync and not.

The app keeps whatever fraction you give it and prints it back the same way: a display set to 59.94 says 59.94, and one set to 60 says 60. It does not round one into the other on your behalf.

Yes. A virtual display can be created standard, high dynamic range, or in reference mode.

Standard gives the ordinary 1.0 headroom above diffuse white. High gives 5.0, which is what an HDR-capable panel reports and what video and image pipelines look for. Reference gives 10.0 with a matching reference value: the Pro Display XDR behaviour, saying the display is calibrated to that range rather than merely capable of it.

It is standard unless you ask for something else, because macOS composites an HDR display differently and a display claiming headroom nothing feeds it costs power for nothing.

Two things to know. The interface has no HDR switch: this works through an undocumented transfer function, found by probing, and the framework accepts every value for it without complaint while only one produces headroom. So the app measures the result instead of trusting the call, and the hardware smoke test asserts the headroom. And there is still no colour profile assignment: displays use the system’s default colour handling.

HDR has the measurements and the caveat about macOS updates.

All of them, because MoreDisplays does not stream anything. It builds the display; your client streams from it. Any client that can attach to a Mac’s display works.

What varies is what each one does with it. Apple’s Screen Sharing handles any size and negotiates a conservative frame rate. Jump Desktop and Parsec reach genuinely high rates on a local network. Plain VNC works everywhere and is slow. Screens leaves the display alone, which makes it easy to reason about. Apple Remote Desktop is the same transport as Screen Sharing, aimed at watching many machines rather than working on one.

Two need one setting changed: Jump Desktop and Parsec both request a display resolution when they connect. Turn that off and let the group own the display.

Remote clients has the detail per client.

Yes, and none of them are visible to the app at all. MoreDisplays makes a display; how your client reached the machine is between your client and your network.

mdctl over SSH behaves identically over any of them, so the pattern of running one command as you connect needs nothing special. Tailscale suits this particularly well, because it gives the machine a stable name to reach whichever network you happen to be on.

They go away. Virtual displays belong to the app, and it releases them when it stops.

That is deliberate. A display that no running process owns cannot be reconfigured, cannot be removed and cannot be reported on. It would sit in the hierarchy until the next restart with nothing able to touch it, which is worse than not having it.

If the app crashes, displays can be left behind. Everything it creates carries the app’s own vendor identifier, so the next launch finds those orphans and releases them.

On a headless machine this matters: quitting the app removes the display your screen sharing session is looking at. Keep SSH working.

Once you are logged in, yes, if two things are set: Open at login in Settings, and activate on launch on the group you want.

The app then runs its launch sequence, cleans up any orphaned displays, checks the kill switch, registers hotkeys, opens the mdctl socket and activates the marked group.

Before you log in, no. See the login window answer.

A cold boot with activate-on-launch is one of the scenarios still on the manual test matrix, so treat it as untested rather than as working.

It can, if you ask it to per display.

Mark a display protected in its group and the app puts the arrangement back when that display drifts out of the mode the group asked for. It re-applies the whole arrangement rather than the one mode, because a resolution change moves everything to the right of it and restoring the size without the origins leaves a desk that is half correct.

It is off unless asked for, and it is per display rather than global: an app that fights you for control of your own screen is worse than one that lets go.

It also gives up rather than fighting. Five restores in twenty seconds is not a correction, it is two programs taking turns rewriting the framebuffer, so the engine concedes, logs it once, and waits until the group is activated again.

Worth protecting: attached monitors, because something else has an opinion about those. If a remote client keeps resizing a display, turning off its automatic resolution is the better fix than winning the argument five times and then stopping. Protection has the detail.

Yes, over your own iCloud, and it is on by default.

Only the library travels: the groups themselves and the record of which ones were deleted. Everything about the machine stays on the machine, including which group is currently active and every setting in Settings. A Mac in a rack and a laptop want the same groups and emphatically not the same active group.

Two machines agree by date: every group carries when it last changed, and the newer copy wins. Deletions are recorded rather than simply performed, because an absence cannot travel and a record can, otherwise a group deleted on one Mac reappears from the other forever.

The switch in Settings turns it off. It needs an entitlement, a signed build and a signed-in iCloud account, and when one of the three is missing Settings says which and everything else keeps working against the local file. Sync and backups has the detail.

There is no analytics, no crash reporting service, no account and no telemetry. There is no server belonging to this project, so there is nowhere for anything to go. A licence key is checked on your own Mac against a number inside the app, with no activation step and nothing sent anywhere.

The one thing that leaves the machine is the group library, to your own iCloud, when Share groups across my Macs is on. That setting is on by default, so it is worth knowing about. What goes up is the groups and the record of deletions; what stays is the active group and every setting. Nobody but you can read it, and turning the switch off stops it.

Support bundles are written to a file you choose and are never uploaded. They contain the configuration, the app’s own log entries and the display topology, and nothing from outside those three places.

The app asks this site whether there is a newer version. That is a request for one file, made at most once a day while the app is running and whenever you choose Check for Updates from the menu bar item. It carries no identifier and no cookie, it is the only outbound request the app makes, and Check for updates automatically in Settings stops the daily one. A copy that is never running never asks.

The app itself is one ordinary program running as you. mdctl is a client that hands it a request over a unix socket in your support directory, and nothing listens on a network port.

There is now also a privileged service, and it is off unless you ask for it. It exists for one thing the app cannot do: make displays before anybody has logged in. The app dies with your session, so the login window is the one screen it can never cover.

The service is deliberately tiny. It links the types, the display code and the virtual display code, and nothing else. Nothing that needs a window server is in it, which is not a style rule but a fact about the process. That boundary is what keeps a program running as root small enough to be worth trusting.

It ships inside the app bundle rather than in /Library, so uninstalling stays honest: drag the app to the trash, plus one unregister. There is no installer and no administrator password. macOS puts its own approval request in front of you, and the app warns you that it is coming.

It is not finished. In version 1.6 the service installs, starts, stays resident and reports its state, and does not yet present a display at the login window. The page about it says what it does today and what it does not.

macOS 14.0 Sonoma is the minimum. Below that the private interface differs enough that the app declines rather than guessing.

macOS 26 is the newest line the interface has been validated against. On anything newer the app logs a warning and carries on: refusing to run on a release nobody has tested is worse than trying and reporting what actually happened.

The released build is Apple silicon. The binary carries one architecture, arm64, so it needs a Mac with an Apple chip.

One macOS 26 behaviour worth knowing before you upgrade: a virtual display in the hierarchy can interfere with Spaces focus and Space switching, so switching Spaces sometimes moves focus to the wrong display. Any workaround would mean fighting the window server, and the app does not attempt one.

App Store apps must be sandboxed, and creating a display needs interfaces the sandbox forbids. A sandboxed MoreDisplays would be an app that cannot do the thing it exists to do.

Reconfiguring displays through undocumented interfaces would not survive review either, and it should not: that is exactly the kind of thing review exists to catch. The project’s answer is to be loud about it rather than to hide it. The private interface is confined to two modules, there is a kill switch that stops it entirely, and every other module compiles, runs and passes its tests with those two replaced by stubs reporting “unavailable”.

When there is a release it will be distributed the way most Mac utilities of this kind are: Developer ID signed, notarised, hardened runtime, in a disk image.

Ten euro, and it is asked for rather than collected. Nothing is locked, limited or switched off if you do not pay: nothing expires, no feature sits behind a key, and you can use it on as many Macs as you like.

Payment is voluntary and works like this: for the first thirty days the app says nothing at all. After that it asks, once every thirty days, whether it has been worth anything. A licence key stops the asking permanently, and stopping the asking is the only thing a key does.

The suggested amount is 10 euro, and it is a suggestion rather than a price. The Support tab in Settings carries the addresses a contribution can go to; send the transaction reference to support@moredisplays.com and a key comes back, for the same tab.

The key is checked on your own Mac against a number inside the app. No account, no activation, no server, and no way for anyone here to know whether you entered one.

The licence

Elastic License 2.0. You may use it, read the source, change it and pass it on. You may not offer it to other people as a hosted service, and you may not strip out the licence key handling or the reminder it silences. There is no warranty, which is worth reading twice for software that reconfigures displays through an undocumented interface.

That is source available rather than open source, and the distinction is worth stating rather than blurring: the Open Source Definition does not permit restrictions of this kind, so calling this open source would be wrong. The source is there to be read, checked and built, not to be repackaged with the request removed.

The licence page has the full text.

The app has no third party runtime dependencies at all.

MoreDisplays is much narrower. It exists for one job: saving a complete display arrangement under a name, and putting the whole machine into it in one action. Which displays exist, at what resolution and refresh rate, rotated how, positioned where, and which one owns the menu bar.

Everything it has is in service of that. Virtual displays because a Mac in a cupboard has no panel to arrange. A catalogue of real panels so the numbers are right. Protection because macOS undoes your work when a screen sharing client renegotiates. A shortcut, a URL scheme and a command line tool because the machine you are configuring often has no screen attached.

What it does not have: streaming a display into a window, colour management or calibration, rules that pick a setup for you, and anything at all before you log in.

It costs 10 euro, on trust. Nothing expires and no feature is behind a key: after thirty days it asks once a month whether it has been worth anything, and a key stops the asking. That is the whole of the money side.

The BetterDisplay alternative page is the longer answer, including the parts where the answer is no.

The Support tab in Settings has everything: the suggested amount, the addresses a contribution can go to, each with a button that copies it, and the field a key is typed into.

Ten euro is the suggestion. It is a suggestion and not a price, because nothing checks whether anything arrived and nothing can. Naming a number is only there to save you the question “how much is reasonable”, which is the question that most often ends in nothing being sent at all.

Send the transaction reference to support@moredisplays.com and a key comes back. Enter it in the same tab, and the monthly reminder stops. Nothing else changes: there is no feature behind a key, nothing expires, and no limit is lifted.

You do not have to pay anything to keep using the app, now or ever. That is the whole design, and the licence page says why it is a request rather than a check.

Because the app checked whether it could do that thing on your system, found that it could not, and is telling you rather than hiding the control.

The reasons that come up, and what each one means:

• “Virtual displays are unavailable on this Mac.” Either macOS is older than 14, or the private interface did not resolve on this version. The rest of the app keeps working.
• “The brightness keys could not be intercepted on this Mac.” The event tap could not be created. Usually accessibility permission; sometimes the tap simply failed.
• “macOS refused to open MoreDisplays at login.” The login item was rejected. Try removing and re-adding it in Settings.
• “Another app already uses the shortcut for group.” macOS gives a shortcut to whoever registered it first, and a second app cannot win. Pick a different combination.
• “iCloud is unavailable: reason.” Sharing needs an entitlement, a signed build and a signed-in account. A build you compiled yourself will always say this.

Also check the kill switch. Allow virtual displays off stops every creation and releases what exists, deliberately and without an error, which is exactly why it is worth checking first.

The display exists and nothing is being composited to it. In order of likelihood:

The client attached before the display existed. Common right after a login. Disconnect and reconnect.

Nobody is logged in. The app runs in your user session, so before you log in there is no app and no virtual display, whatever the group says.

The session is on a different display. Check which display the group makes main, and whether it includes physical displays that might be taking the session instead.

The mode is something the client cannot decode. Drop to 1920 by 1080 at 60 Hz with HiDPI off. If the picture comes back, work upward.

Troubleshooting has the long version.

Exit code 3 means the tool found nobody on the socket. The socket lives in the support directory, and the app opens it during its launch sequence.

Two causes. Either the app really is not running, or it is running and had not opened the socket yet when you asked. The second is common for anything that runs at login and beats the app to it.

ls -l ~/Library/Application\ Support/MoreDisplays/mdctl.sock

If the file is missing while the app is open, the launch sequence did not finish; quit and reopen. If a script hits this at login, wait for the socket rather than failing: the recipes page has the loop.