OpenDisplay: turn an iPhone, iPad or spare Mac into a real second monitor

The gap OpenDisplay targets: a second monitor without a subscription or dongle

Apple Sidecar is free but, per the README, requires both devices on the same Apple ID, does not support iPhones at all, and only works on supported hardware pairs. Duet Display moved to a subscription. Luna Display requires a hardware dongle. OpenDisplay positions itself as the remaining option: free, open source, no account, no dongle.

The audience is narrow and specific. You already own an iPhone or iPad and a Mac, and you want macOS to treat that device as an actual extended desktop rather than a mirror. The README is explicit that this is true extension: you drag windows onto it and arrange it in System Settings. Mirroring exists as a mode, not the default.

The project also addresses people who were about to build this themselves. The README says the hard parts (virtual display creation, the low-latency H.264 pipeline, USB transport, input injection) are already working, and asks contributors to join instead of forking the effort. That is a fair summary of where the difficulty sits in this class of tool.

How the virtual display, H.264 pipeline and input path fit together

The architecture is two small apps and one TCP connection. The Mac side captures the screen through ScreenCaptureKit, encodes with hardware H.264 via VideoToolbox in real-time mode with no B-frames, and sends over TCP with TCP_NODELAY set. The receiving side decodes and renders with AVSampleBufferDisplayLayer. Frame-drop backpressure with keyframe recovery handles a receiver that falls behind.

Transport is either USB or WiFi. Over USB, the stream goes through macOS's built-in usbmuxd rather than presenting as a USB video device. Over WiFi, the iPhone advertises itself via Bonjour and you pick it from a dropdown on the Mac. The README describes WiFi as zero config, which is accurate at the discovery layer and less accurate once permissions are involved.

The virtual display matches the device panel pixel-for-pixel at @2x, which is what makes text sharp rather than scaled. Rotating the device rebuilds the virtual display as a vertical monitor at native resolution.

Input travels the other way. Tap to click, drag to drag, and two-finger scroll that the README compares to a trackpad. Apple Pencil support is listed as roadmap, not shipped. The repository layout backs this structure up: separate iOS/, Mac/, MacReceiver/ and Shared/ directories, plus a PROTOCOL.md at the top level.

Setting up OpenDisplay and getting a first extended display

The README points to the website and the quick start section rather than giving shell install commands; the repository has a run.sh, a project.yml and a generate.sh, which suggests the apps are built from source with Xcode tooling. The release notes list v1.19.0, so prebuilt releases exist. What follows is the order of operations the README describes.

Start on the Mac, which needs macOS 14 or newer. Grant Screen Recording when prompted. The purple screen-recording indicator in the menu bar is expected: the README notes macOS shows it for any app using public capture APIs, including Duet, Luna, OBS and Zoom, and that it cannot be hidden by an app.

For the wired path, connect the iPhone or iPad with a cable that supports data. A charge-only cable will not work. The README's test is to look for a cable described as data, sync, or charging and data-transfer. Unlock the device and accept the Trust This Computer prompt if it appears.

USB 2.0 is enough. The README states the highest-quality preset uses 18 Mb/s, well under USB 2.0's 480 Mb/s high-speed link rate, and that USB 1.x is not supported or tested. Avoid hubs and adapters the README calls unreliable.

For WiFi, both sides need Local Network permission, and the README warns that both fail silently without it. Check Privacy & Security then Local Network on the Mac and on the iPhone. Keep the iPhone app open in the foreground, confirm both devices are on the same WiFi network, and pick the device from the Connection menu on the Mac. USB mode is unaffected by Local Network permission.

To use a spare Mac as the display, install OpenDisplay Receiver from the same release. It needs only macOS 12 Monterey or newer, so Macs from around 2015 onward qualify even though the sending Mac needs macOS 14. Over WiFi it works out of the box. For a cable, the README lists a Thunderbolt or USB4 cable (macOS creates a Thunderbolt Bridge network), an Ethernet cable or adapters, or on recent macOS a plain USB-C data cable with an allow-accessory-to-connect prompt on each Mac. The sender moves the session onto the cable automatically, even one plugged in mid-session, and the device row reads Cable. Thunderbolt 1 or 2 Macs work with a Thunderbolt 3 to 2 adapter and a Thunderbolt 2 cable.

Where OpenDisplay breaks down: silent permission failures and unencrypted WiFi

The most likely failure is the one the README calls out itself. Without Local Network permission on both the Mac and the iPhone, the device simply does not appear in the Connection menu. Nothing tells you why. If you are debugging a missing device, check that permission before anything else, then network, then whether the iPhone app is in the foreground.

The second trap is the cable. A charge-only USB cable produces no connection, and the README's own guidance is to use a known-good data or sync cable. This is the kind of problem that reads as a software bug and is not one.

The third is a real limitation rather than a setup issue. Input from a receiving Mac's keyboard and mouse is not implemented; the README links issue #147 and calls it a follow-up. If your plan is to drive the extended Mac from its own keyboard, that plan does not work yet.

The fourth concerns privacy. The README's FAQ says screen content goes over one direct TCP connection and never touches a server, which is true, but it also points to a current WiFi-encryption caveat on the privacy page. The README does not spell out the caveat in the main text. If you are streaming over an untrusted network, treat the wired path as the safer default until you have read that page.

Finally, HEVC is not available. The README says H.264 was chosen because hardware encode and decode are universally fast with excellent latency, and that HEVC is a planned option for better quality-per-bit. If you need the best quality at a constrained bitrate today, that option does not exist yet.

OpenDisplay against Sidecar, Duet and Luna

The comparison that matters is not feature count, it is what each tool assumes about your hardware and your account. Sidecar assumes one Apple ID across both devices, excludes iPhone entirely, and restricts you to supported hardware pairs. It is the only option in the README's table that does not trigger the purple capture indicator, because it runs inside the OS rather than on public capture APIs.

Duet Display and Luna Display both support iPhone as a display and both work across different Apple IDs, which OpenDisplay also does. The difference is commercial: Duet is a subscription, Luna needs a dongle. OpenDisplay is free and its source is auditable, which is the one column in the README's table where the other three are marked unsupported or not applicable.

Wired support splits the field differently. Sidecar, Duet and OpenDisplay all do USB; Luna does not. OpenDisplay's wired path is unusual in that it is not a USB video device at all: it is H.264 over TCP through usbmuxd, which is why a USB 2.0 data cable is sufficient and why video Alt Mode is irrelevant.

One thing the table does not capture: OpenDisplay is the only one of the four where you can read the protocol. PROTOCOL.md sits at the top level of the repository, next to the Shared/ directory the two apps presumably compile against.

Maintenance cadence, licence and what a fork implies

The repository is not archived and the last push was on 2026-09-17. Releases have been frequent: v1.17.0 on 2026-08-20, then v1.18.0 and v1.19.0 both on 2026-09-01. That cadence matters for a tool that depends on macOS capture APIs, because OS updates can change behaviour underneath it.

The licence is GPL-3.0. The README's own FAQ answers the fork question by pointing at the LICENSE file and stating that use, study and redistribution are permitted under those terms. The practical implication for a company is the usual copyleft one: if you modify and distribute the software, GPL-3.0 obligations attach to your distribution. That is a description of the licence, not legal advice, and anyone embedding this in a product should read the LICENSE file rather than this paragraph.

The upgrade cost is low in one sense and non-trivial in another. There is no package manager entry to bump; the README directs you to the website and releases. But the app depends on macOS privacy permissions and on ScreenCaptureKit, so a macOS upgrade is the moment to re-verify that Screen Recording and Local Network permissions survived, and that the capture indicator still behaves as documented.

One structural note from the repository: the landing page is a separate Vite and React project in package.json, named opendisplay-site, with pnpm as the package manager. That is the website, not the app. Do not confuse the two when reading the tree.

Editorial conclusion

Adopt OpenDisplay if you have an iPhone or iPad you want to use as a genuine extended display on a Mac running macOS 14 or newer, and you are willing to check Local Network permission on both sides. Do not adopt it if you need input from the receiving Mac's keyboard and mouse, or if you require encrypted WiFi transport, since the README points to an unencrypted WiFi caveat and lists Mac-to-Mac input as an open issue (#147). Before relying on it, verify the cable supports data, confirm the sending Mac meets the macOS 14 requirement, and read the privacy page for what the apps store locally.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. peetzweg/opendisplay on GitHub
3. Project website
4. README
5. Releases