Introducing ProRDP

Why I made my own RDP server for macOS

In the past few decades of alternating between Windows and macOS as my daily driver for both work and personal use, there’s one thing that Windows has out-of-the-box that I could never find a good solution for on macOS: reliable, high-performance remote desktop access.

On Windows, remote access has “just worked” for years. Flip a switch in Settings, open the Remote Desktop client on any other machine, type a hostname, and you’re there. It’s fast, it’s built in, it’s free, and nobody asks you to make an account. I’ve RDP’d into machines under my desk, in closets, and across the country, and it works every time. I can drop straight in to a remote desktop to grab a file, restart a service, or fix an issue.

On macOS, I’ve tried multiple VNC and proprietary remote access solutions, and none of them come close to the seamless experience on Windows. After enough frustration, I decided to try making one myself.

Built-in VNC screen sharing is really bad

You might be thinking “why not just enable the built-in screen sharing feature in macOS?”. Oh I have, and it’s not a good experience. Screen sharing on macOS uses Virtual Network Computing (VNC) under the hood, which is not hardware accelerated and suffers from poor performance, high latency, and low image quality. If you’ve ever tried to move a window around or just do basic interactions, you’ll notice the lag and stuttering immediately. Here’s me trying to move a window around the other day when I was preparing some benchmarks:

With enough tuning and dropping your resolution, framerates, and color depth, you can make VNC somewhat usable, but why do you need to in 2026 when I have the hardware and network capabilities to handle more? Windows seemed to have figured this out years ago, why can’t macOS?

VNC clients are increasingly exploitative

It’s not just the server end of VNC that frustrated me. When I was looking for a Windows VNC client to use, most were either paid, super sketchy, or required cloud accounts and data sharing. Why do I need to create a cloud account or pay for a client just to connect to a machine on my own network? Don’t get me wrong, I understand that developers and companies can’t always give away their work for free, but a monthly fee for a completely local connection felt exploitative.

Even looking to the open-source community for a VNC client didn’t turn up any good options as well. Some of the more promising projects were either abandoned completely or only supported Linux. I could not find a good option for Windows after extensive searching.

I even considered ditching macOS screen sharing and VNC completely, trying completely proprietary servers, protocols, and clients. And to be fair, there were a couple that did offer a free tier that was much, much better than VNC. But their key weakness was they capped performance unless you paid a monthly fee, which left me with blurry and laggy remote sessions even on a fast network.

I finally reached the point where I asked myself: “can I just build my own RDP server for macOS?”.

The spec was always there

My starting point for building my new RDP server was realizing that RDP isn’t actually a secret. Microsoft publishes the entire protocol family as part of its Open Specifications program. The core connection sequence, the graphics pipeline, input, audio, and transport layers are all documented in detail.

I actually came across these specs multiple times back when I worked at Microsoft. Every year Microsoft ran an internal hackathon for pursuing new ideas solving problems you’ve faced, and I had said for years that I wanted to build my own RDP server for macOS, but it always felt too daunting at the time. I’m comfortable in Xcode and can design a decent experience, but these low-level protocol details were intimidating and outside my usual expertise. So I shelved the idea and figured someone else could tackle it who was smarter than me.

Time to revisit the idea

Over the past couple months I’ve been tuning into the Mark and Scott Learn To… podcast to stay in touch with my old boss and hear Mark and Scott’s thoughts on a variety of topics. Lately, that’s been a good amount of conversation around AI-assisted development, and the role of copilots and agents in modern software engineering.

A month ago Mark was talking through his Process Explorer for macOS release, and how AI-assisted development helped him port the Windows version of Process Explorer to macOS. While it wasn’t a one-shot success, he talked through how AI accelerated the process, taking on sections on the backend code while he focused on the user experience and making sure everything integrated smoothly.

That got me thinking: if AI could help Mark accelerate a complex port like Process Explorer, could it help me break down the RDP specs and build my own client for macOS more efficiently? Spoiler alert: it did.

So is this just some AI slop project?

AI didn’t build ProRDP for me. It’s not some one-shot AI slop project that’s riddled with bugs and half-baked features. Did AI do what it does best and summarize the RDP specs and break them down into actionable deliverables? Absolutely. Did it translate the byte-by-byte examples from the RDP specs and create an extensive test suite? For sure. But did I just give a /goal and token max my way into a fully working, polished RDP server for macOS? Not even close.

Since realizing there might be a path forward with AI-assisted development, I took on my first software side project in years. Mornings, weekends, and the occasional late night were spent designing and implementing several of the RDP specs and testing them thoroughly.

The fun part though, is that I had to re-learn a lot of fundamentals of building, validating, and testing software from the ground up. As an example, instead of manually testing each and every feature, my tests now involve AI launching ProRDP, interacting with it, and verifying that it behaves correctly under various scenarios. If you’re familiar with Playwright, it’s like that but on steroids. Every single feature now gets full unit tests and integration tests from the moment they’re created, while I get to focus on the actual feature development and user experience.

In just about a month since realizing that my original idea for a macOS RDP server might be possible, I built a fully functional RDP server for macOS that has basically all of the main features I need to be my daily driver for accessing my Macs remotely. It’s now available for you to download and try out for yourself.

Free for home and personal use

I built ProRDP because I wanted it for my own Macs at home, and I think everyone in that position should be able to use it without needing to sign up for a cloud account and getting bombarded with marketing emails and getting their data sold. I firmly believe that monthly subscription payments have no place in software that runs 100% locally on your own machines, without any cloud dependencies. I also don’t like free solutions that artificially limit functionality to push you towards a paid tier. So for that reason, I decided to just follow the Docker Desktop model and give it away for free for home and personal use.

But I’m also working on commercial licenses for businesses and teams. Commercial licenses won’t exist to take things away from the free version. Instead, they’ll add more advanced functionality like Entra ID integration, centralized management, and other things that actually require a cloud backend and can justify a monthly license fee. I’m still sorting that out, so stay tuned for more details in the coming months.

Help me make it better

This is the first beta release, and I have some ideas for improvements and new features. There are still a few RDP specs that I haven’t implemented yet, and there are likely bugs and edge cases I haven’t encountered. I’ve been using ProRDP every day in my own setup, but your Macs, networks, displays, and RDP clients are going to find things mine never did.

If something breaks, or if there’s something you wish ProRDP did, please tell me. Bug reports and feature requests both live in the prordp-app/release repository on GitHub. I’ll do my best to respond and address them as quickly as possible.

Thanks for giving it a try. I hope connecting to your Mac finally feels as boring as it always should have.

— Aaron