uxplay-windows: an AirPlay receiver for Windows

What uxplay-windows actually is

uxplay-windows is described as free AirPlay to your Windows PC, with the README spelling out the double meaning: free as both in freedom and in free beer.

Underneath it is UxPlay, the AirPlay server, and this repository's job is to package that server as a proper Windows application rather than as a binary you run from a command prompt. The repository layout shows a libuxplay directory and a Bonjour SDK directory, plus src/, packaging/, scripts/ and docs/ directories, which is the shape of a project that vendors the upstream server, wraps it, and produces installers.

The Windows-native part is what the project adds. The application runs from a tray icon, and the README says you control uxplay-windows from it, right-clicking to start or stop AirPlay. You can also set it to run automatically when the PC starts. A UxPlay server on its own gives you a command line and a set of flags; this gives you a windowless background service with a start and stop switch, which is what most people actually want on a second display.

The default branch is multi-arch, and the recent releases include a beta3 tagged as an arm64 test from 2026-06-08, alongside 2.0.0.1736 from 2026-05-04 and 1.72.1-3 from 2025-06-19. So ARM64 support is recent and still being tested, while the x64 path is the established one.

Installing it and the Windows Defender warning

The installation path is a download from the releases page, and then an expectation that Windows will complain about it.

The README addresses that directly in an important callout. If Windows Defender complains during installation, click More info and it will let you install. The stated reason is that the executable is not signed, and the README adds that if you do not trust the software you can always build it yourself, linking to BUILDING.md.

That is a candid answer, and it is also the only thing a user can do about it. An unsigned executable on Windows triggers a SmartScreen warning for every user, and the only route past it is the More info and Run anyway path, which is a one-click decision for a user who does not know what they are clicking. The alternative the project offers is building from source, which is the correct answer for anyone with a reason to be careful.

The second prompt is the firewall one, and here the instruction is the opposite. If prompted by Windows Firewall, the README says to allow uxplay-windows so that it functions properly. That makes sense: an AirPlay receiver has to accept inbound network connections to receive the stream, and a firewall rule that blocks them means AirPlay discovery and streaming silently fail.

So the two prompts ask for opposite responses, which is slightly awkward for a first-time user, and the order of operations in the README is worth following. Allow the application, and expect the Defender warning.

The configuration file and its precedence rules

The advanced configuration is unusually well specified, and it is worth reading because the precedence order has a purpose.

UxPlay arguments are read from a file called arguments.txt. The README gives three levels of precedence. First, %ProgramData%\uxplay-windows\arguments.txt. Second, %APPDATA%\leapbtw\uxplay-windows\arguments.txt. Third, a built-in default of -n uxplay-windows -nh.

The machine-wide file takes precedence when it exists, and the stated reason is that this allows administrators to enforce a shared configuration. When it is absent, each user can maintain their own configuration under %APPDATA%. That is a sensible design for a machine that might be a shared or a lab machine, and it is worth knowing which of the two applies before you start changing settings that appear to have no effect.

Environment variables are expanded when the app starts, and the README gives one example.

-n %COMPUTERNAME% -nh

That turns the device name argument into the machine's computer name, which is what you want if the default uxplay-windows name is going to appear in someone's AirPlay picker among several devices.

The -nh in the default and the example suppresses the hostname lookup in UxPlay itself, so the name is the one supplied rather than the one UxPlay would otherwise derive. Understanding the two flags together is most of what is needed to configure the app properly.

The build system and the PowerShell script

The build story is the part of this project that has been actively reworked, and the README's opening diff block makes that explicit. A note dated 29 july 2026 says the new build system seems to be working great for both x64 and arm64, and asks whether it is possible to codesign uxplay-windows before making a new release.

That question is the crux. The missing code signature is the reason Windows Defender complains, and the author is trying to solve it, so the current state is that the project knows this is a problem and has not yet fixed it.

The local build, once MSYS2 is installed, is one PowerShell command per architecture.

.\build.ps1 package -Architecture x64
.\build.ps1 package -Architecture arm64

Each command produces a verified portable ZIP and an MSI under the corresponding out\<architecture>\artifacts directory, and the developer guide in docs/ covers the prerequisites and other commands.

The word verified in that description is doing work, since a build that produces an artefact and a build that produces a checked artefact are different things, and the README notes that a successful build alone does not verify the runtime behaviour in the case of the upstream project.

The repository structure supports the multi-architecture claim. There is a CMakeLists.txt at the root, separate dependency manifests for clang and for the ucrt, one named clangarm64_dependencies.txt and the other ucrt_x64_dependencies.txt, plus a product.wxs file, which is the WiX source for the MSI installer. The packaging/ directory holds the installer configuration and the scripts/ directory the build steps.

Known issues and the TODO list

The README keeps both lists, and reading them is the fastest way to understand the state of the project.

The TODO list has three entries. Make an update checker. Include uxplay.exe for debugging purposes. And a struck-through entry about passing arguments from uxplay-windows.exe to uxplay, with the note or maybe not attached.

The update checker is the one that matters to a user, because without it an installed copy stays at whatever version it was when it was downloaded, and the releases are infrequent enough that a stale copy is likely. The struck-through argument-passing entry is interesting in the light of the configuration section, since arguments.txt already provides a way to set the server's flags, so the author may have concluded the feature is covered by other means.

The known issues section keeps the crossed-out entries, which is unusual and useful. One is uxplay bugging out when waking the PC from sleep, with the old workaround of killing uxplay-windows.exe, restarting the Bonjour Service and restarting uxplay.exe, or restarting the PC. The author then notes that moving from Bonjour PS to mDNSResponder appears to have fixed it.

That single line is a real architectural change. The Bonjour PS to mDNSResponder switch replaces one multicast DNS implementation with another, and the repository layout confirms it, with a Bonjour SDK directory and a separate mdnsresponder-patches/ directory. The sleep wake bug was almost certainly a discovery problem rather than a streaming one, which is the kind of thing that is invisible until it wakes you at night.

The remaining open issue is that sometimes, just after connecting an iPhone, the stream appears but frozen, and reconnecting a second time fixes it. The author suspects an upstream issue that may already be fixed in a newer UxPlay version, and says more investigation is needed.

Where uxplay-windows is the wrong choice

The first limitation is the missing code signature, and it is not a small one. Every installation goes through a SmartScreen warning, and the only user-facing remedy is a click on More info. For a personal machine that is an irritation. For a machine in an environment with endpoint protection, application allow-listing or a software approval process, the executable may simply be blocked, and the README's advice does not help because the blocking is not the user who clicks the button.

The second is the absence of automatic updates, which is on the project's own TODO list. An installed copy therefore does not track the releases, and the workaround is to check the releases page yourself.

The third is the ARM64 maturity. The beta3 tag from 2026-06-08 is explicitly an arm64 test, and the earlier releases are x64. An ARM64 Windows device, which is now the common shape of a Windows laptop, is on the less-tested path.

The fourth is that this is a thin wrapper. The README says clearly to report issues related to the build system in this repository and issues related to other parts of the software in their respective repositories, which means a problem in AirPlay discovery or in UxPlay itself is not fixed here, and the user has to work out which repository to file it in.

The fifth is the licence. The repository records no licence identifier, and the README points to a LICENSE file with an .rtf extension under docs/. A binary distribution with an unclear licence is a problem for anyone who needs to redistribute it inside an organisation.

uxplay-windows compared with UxPlay on its own and with an AirPlay receiver for Linux

The comparison with running UxPlay directly is the first one, and the difference in approach is packaging rather than function. UxPlay gives you the AirPlay server, and on a machine where you are comfortable with a terminal it is the same server with more control, since every flag is visible on the command line rather than hidden in a text file that the tray application reads. What uxplay-windows adds is the Windows-native integration, the tray control, the start on login option, the MSI installer and the portable ZIP, which is the difference between a tool you can hand to a non-technical colleague and one you cannot.

The second comparison is with the AirPlay receiver built into Windows. Windows can act as an AirPlay receiver for its own screen, which is a different thing from what this project does, since it mirrors an iPhone to a Windows display rather than streaming an iPhone to another AirPlay client such as an Apple TV or a speaker.

The third comparison is with the Linux side of the same idea, where AirPlay receivers are built from the same UxPlay upstream and shipped as packages on several distributions. The difference in approach is the Windows-specific one: the registry of configuration files with its machine-wide and per-user split, the Windows Firewall prompt, the tray icon and the WiX-based MSI, none of which exist on a Linux system. It also means that the Linux package is generally a straight build of upstream UxPlay, while this project carries its own patch set for the Bonjour to mDNSResponder change, which is the part that a distribution package would not have.

The fourth is the hardware angle. Anyone who wants to put a permanent AirPlay target in a room still needs a display or a receiver to show the video on, and this project is the server half of that setup rather than the whole thing.

Licence, community and what to check after installing

The licence field on the repository carries no identifier, and the README points to a LICENSE file in docs/ with an .rtf extension, which is the Microsoft rich text format and an unusual choice for a repository licence file. Anyone who needs to know what they may do with this binary has to read that file, and the README does not paraphrase it.

The project is not archived and the last push was on 2026-09-13, so work is continuing. The 29 july 2026 note about the new build system working for both architectures is recent relative to that, and the open question about codesigning is the item to watch for, because a signed release would remove the largest friction in the installation path.

There is a wiki linked from the README, described as containing the FAQ, troubleshooting and help, and that is where the question of Bonjour versus mDNSResponder and the discovery behaviour is likely to be documented in more detail than the README manages.

Four things to check after a first install.

That AirPlay discovery works at all, which means the firewall prompt was answered with allow, since a blocked inbound rule produces an invisible device rather than an error. That the device name is the one you want, which means checking what the tray application shows and setting -n in arguments.txt if it is not. Where the configuration file you are editing actually lives, since the machine-wide ProgramData copy wins over the per-user one and a change to the wrong file does nothing. And whether the tray icon reports AirPlay as running, because the README's structure implies the server can be stopped from there and a stopped server is a common reason for a device that never appears in the picker.

Editorial conclusion

uxplay-windows suits someone who wants to mirror an iPhone or iPad to a Windows machine, or stream to it, and who is willing either to accept an unsigned executable or to build the project themselves from source. It is the wrong choice for a machine you cannot rebuild, since the executable carries no code signature and Windows Defender will object, and the wrong choice if you need automatic updates, because the update checker is still on the project's own TODO list. Before installing, read the configuration precedence in the README, because the machine-wide arguments.txt overrides the per-user one, and allow the app through the firewall or AirPlay will not discover the machine at all.

Frequently asked questions

Official sources

1. Issues
2. leapbtw/uxplay-windows on GitHub
3. README
4. Releases