# idevice_pair: a cross-platform GUI for iOS pairing files

> idevice_pair is a Rust desktop application that creates lockdown and remote pairing records for iOS devices over USB or Wi-Fi, with validation and the option to write the file straight into an app's Documents directory. It suits developers and sideloading users who need a pairing file without the command line.

**jkcoxson/idevice_pair** — Generate pair records for iOS and save them

- Repository: https://github.com/jkcoxson/idevice_pair
- Stars: 922 · Forks: 93
- Language: Rust
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/jkcoxson-idevice-pair

## Two kinds of pairing record over two transports

The scope is small and well defined. idevice_pair is a cross-platform GUI for creating iOS pairing files, over USB or over Wi-Fi, and the feature list draws the distinction that matters. It can create a lockdown file or a remote pairing, which is called an RPPairing file, on either transport. The two are not interchangeable. The lockdown flow reuses the record usbmuxd already holds and only pairs if there is not one, which is why lockdown works everywhere, while remote pairing needs iOS 17.4 or later. The device list is populated automatically, since usbmuxd devices show up without any action from the user, and a device that usbmuxd sees over Wi-Fi is already paired, so it appears in the dropdown and works the same as a cabled one. That last detail is a useful piece of information on its own, because it means a device can appear in the list without you having paired it through this application. The application also handles device state, in that developer mode and wireless debugging can be enabled over USB so the device can be reached over Wi-Fi later.

## Two destinations for the file, and one of them bypasses the filesystem

Where the generated file goes is the second design decision, and there are two options. The first is the obvious one, saving the file to disk. The second is writing it straight into an app's Documents directory over AFC, which means the file never touches the host filesystem and lands where the app expects to find it. For the applications this tool is aimed at, that second option is the point, because the file has to be in a specific place or the app will not use it. The documentation lists the apps with a known pairing file location, and the list is long and specific: SideStore, LiveContainer combined with SideStore, StikDebug, SparseBox, Feather, Protokolle, Antrag, KSign, EnsWilde, Reynard Browser, Auto Capture, StosDebug and StikStore. That list is the most useful single fact in the repository for anyone trying to work out whether this tool is for them, because it is a compatibility table written by someone who has actually installed the file into each of them. The validation feature closes the loop on that, since it checks that a file you just created actually works, and the troubleshooting section pairs it with a fresh file and the Validate button when a pairing file does not work in an app.

## Wi-Fi pairing over mDNS, with a code typed on the device

The wireless path is the more interesting of the two, and it has a hard version requirement. Pairing over Wi-Fi with an iPhone or iPad requires iOS 27 or later, with both the device and the computer on the same network, and the troubleshooting section adds that mDNS must not be blocked. The flow is that you click Pair over Wi-Fi, pick this computer on the device, and type the code shown by the application into the device. The device then joins the dropdown for as long as the app is open, and the RPPairing record created by the Wi-Fi onboarding is loaded automatically on the device page. Apple TV has its own path, because the box has to be put into manual remote pairing mode through Settings, Remotes and Devices, Remote App and Devices, and then the code shown on the Apple TV is entered in the application, and the device stays in the dropdown for as long as the app is open. The limitation that matters for any real workflow is stated plainly: the remote pairing is only kept in memory, so you have to pair again after a restart, and lockdown pairing is unavailable for this transport, so a lockdown pairing file requires connecting through usbmuxd.

## Building from source is three commands and Rust

The build path is short and the prerequisites are ordinary. You need macOS, Linux or Windows, with usbmuxd installed for USB devices, an iOS or iPadOS device with a passcode set, and Rust if you are building from source. The from source route is three commands:

```bash
git clone https://github.com/jkcoxson/idevice_pair.git
cd idevice_pair
cargo run --release
```

The release build is worth understanding because it is tuned hard for a desktop binary. The release profile in the Cargo manifest sets codegen-units to 1, thin LTO, an opt-level of s, panic abort, and stripping the symbols. Panic abort matters for a GUI, since a panic in an event loop terminates the process rather than unwinding into a framework that might restart the task. The opt-level of s optimises for size rather than speed, which is the right trade for something that ships as a download. There are also platform specific dependency sections, with eframe and pollster pulled in for macOS to provide the glow renderer, and a Windows build dependency on winresource, which is how the icon gets embedded into the executable. The repository root carries icon.icns, icon.ico and icon.png alongside an Assets.car file, so the application ships a complete icon set for all three desktop platforms.

## The whole Apple device stack arrives as one crate

The dependency list shows how much of the protocol work is delegated. The application depends on a single crate, idevice, at version 0.1.68 with default features turned off, and instead the features it needs are selected explicitly: afc for the file transfer used to write into app Documents directories, core_device_proxy, house_arrest, installation_proxy, mdns, pair, remote_pairing, ring, rsd, tcp, tunnel_tcp_stack and usbmuxd. That list is a map of the protocols involved. Pair and remote_pairing are the two pairing flows, usbmuxd is the USB multiplexer daemon that carries device traffic, mdns is the discovery side of Wi-Fi pairing, afc is the Apple File Container that moves the file, rsd and core_device_proxy cover the newer device services, and ring and tunnel_tcp_stack belong to the remote debugging side that pairs with the developer mode and wireless debugging features. Around that, the GUI is eframe, which is the egui framework, with rfd for native file dialogs, tokio for the async runtime, mdns-sd for multicast DNS, uuid for identifiers, and tracing with tracing-subscriber for logging filtered by an environment filter. The dependency on a single upstream crate rather than a sprawl of separate libraries is a good sign, since it means the protocol layer is maintained in one place.

## The common failures are environmental, not code defects

The troubleshooting section is short and honest about what a user can fix themselves. When a device is not detected, the advice is to check that the device is connected and trusted, or reconnect it, and on Linux to make sure the usbmuxd service is running, which is also why the Linux install instructions start with installing usbmuxd. When wireless pairing does not show the computer, the requirements are that both sides are on the same network with mDNS not blocked, that only iOS 27 and later can start pairing from the device, and that for an Apple TV the manual pairing mode must be open before you start. When a pairing file does not work in an app, the answer is to check that the app expects the kind of file you created, to create a fresh one and to use Validate to confirm it works. The USB flow has a similar practical note that is easy to miss, that you should keep the device awake on the home screen while pairing, which is the kind of instruction that only appears when someone has watched it fail. The fact that the troubleshooting text is framed around the user's environment rather than around version conflicts is a sign of a project that is used in earnest.

## Install routes for three platforms and a licence question

The distribution story covers each desktop platform separately, and the differences matter. On macOS you download the universal disk image and drag the application to Applications. On Windows the instructions start with installing iTunes, which is the Apple driver bundle that usbmuxd and the device services come from on that platform, and then you download the x86_64 executable. On Linux you install usbmuxd first and then take the AppImage for your architecture, with separate x86_64 and Aarch64 builds:

```bash
sudo apt install -y usbmuxd
```

The AppImage approach means there is no package manager integration and no system install, which is convenient and also means the usbmuxd service is a separate thing you have to keep running. The release history shows the project moving quickly through 2026, with v1.1.0 from 2026-08-17 described as platform fixes, v1.0.0 from 2026-08-01 and 0.1.14 from 2026-06-17, and the last push on 2026-10-07. The version scheme is worth a note, since a 0.1.x line followed by a 1.0.0 in the same project suggests a deliberate change of the stability promise. On licensing, the licence field for the repository is not identified, while the documentation states MIT under its own heading. Those two facts disagree, and a team that intends to distribute this or build on it should read the licence file rather than rely on either statement.

## Conclusion

idevice_pair is a good fit for someone who needs a pairing record for an iOS device and does not want to learn a command line tool, especially if they use Wi-Fi pairing, since the app handles the mDNS discovery, the code entry and the in-memory record for that path. It is the wrong tool if you need the pairing file to survive a restart over Wi-Fi, because the remote pairing record is kept only in memory, and it is the wrong tool if you want a lockdown pairing over that transport, which is not available and requires connecting through usbmuxd instead. Before using it, read the troubleshooting section, because the common failures are environmental rather than bugs, and check that a passcode is set on the device, since that is a stated prerequisite. The licence field on the repository is not identified even though the documentation states MIT, and the last push was on 2026-10-07.

## FAQ

### What does idevice_pair do?

It is a cross-platform GUI for creating iOS pairing files over USB or over Wi-Fi. It can create a lockdown or a remote pairing file on either transport, save the file to disk or write it into an app's Documents directory over AFC, validate that a file works, and enable developer mode and wireless debugging over USB.

### How do I build idevice_pair from source?

You need Rust, an iOS device with a passcode set, and usbmuxd installed if you are using USB. The three commands are git clone https://github.com/jkcoxson/idevice_pair.git, then cd idevice_pair, then cargo run --release. Prebuilt builds exist as a macOS disk image, a Windows x86_64 executable and Linux AppImages for x86_64 and Aarch64.

### Why does my Wi-Fi pairing file stop working after restarting the app?

The remote pairing is only kept in memory, so you have to pair again after a restart, and the device stays in the dropdown only for as long as the app is open. Lockdown pairing is not available over that transport, so a lockdown pairing file requires connecting through usbmuxd instead.

### Which apps can use a pairing file created by idevice_pair?

The documentation lists the apps with a known pairing file location: SideStore, LiveContainer with SideStore, StikDebug, SparseBox, Feather, Protokolle, Antrag, KSign, EnsWilde, Reynard Browser, Auto Capture, StosDebug and StikStore. Writing the file into an app's Documents directory over AFC is one of the two save destinations.

### What are the requirements for pairing an iPhone over Wi-Fi?

You need iOS 27 or later, with both the device and the computer on the same network and mDNS not blocked. Remote pairing over the network needs iOS 17.4 or later, while lockdown pairing works everywhere, and for an Apple TV you must first enable manual remote pairing mode in its settings.

## Sources

- [Issues](https://github.com/jkcoxson/idevice_pair/issues)
- [jkcoxson/idevice_pair on GitHub](https://github.com/jkcoxson/idevice_pair)
- [README](https://github.com/jkcoxson/idevice_pair/blob/master/README.md)
- [Releases](https://github.com/jkcoxson/idevice_pair/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jkcoxson-idevice-pair