The Pairing File's Journey

For iloader, a pairing file is not a static attachment that can be copied anywhere once and forgotten. It is generated in relation to a device, assembled differently for different iOS generations, retained through a device-specific cache, and then transferred into an app that knows where to use it. This chapter follows that lifecycle from the first lockdown record to placement or export. The practical judgment is simple: automated placement reduces handling and navigation, while manual export increases portability and the exposure of a sensitive device artifact.

A pairing file is composed for the device generation

Pairing begins with information already available from the host and the selected device. iloader retrieves the device's pairing record from usbmuxd, makes sure the device UDID is attached, and starts a lockdown session. It then sets EnableWifiDebugging in the wireless-lockdown service before serializing the resulting material as a lockdown plist. The source does not present this as a generic file conversion. It is a preparation step that combines host-side pairing information with a live session to the particular device.

The device's product version determines what happens next. In the inspected snapshot, devices below iOS 17.4 use the lockdown plist directly. Devices on iOS 17.4 and later follow an additional RPPairing path. The threshold is a source-defined compatibility branch, not a claim that the repository documents all Apple versions or all pairing semantics. Its importance is architectural: iloader does not force one newer protocol onto older devices, and it does not ask the user to select a format manually.

For the newer path, iloader first looks for a cached RPPairing representation associated with the device UDID. If the stored bytes parse as XML, they can be reused. If there is no cache, or if the cached representation is invalid, iloader generates new remote-pairing material. The cache is keyed with the device identity rather than with a display name, which keeps material associated with the device value used by the pairing logic. The interface can use the presence of this cache to favor a familiar device during automatic selection, but the cache is not itself a live device connection.

Generating RPPairing is a chain of native protocol stages. iloader connects to CoreDeviceProxy, reads tunnel information, creates a software tunnel, and connects to the reported RSD port. An RSD handshake exposes services, including the untrusted tunnel service that the code needs. iloader then connects to that service through a remote XPC client, performs the XPC handshake, and creates a RemotePairingClient. That client connects using the pairing structure generated for the host name iloader supplies. The source logs that the user may need to tap Trust on the device during this work.

The code reconnects to the untrusted tunnel service and performs the remote-pairing connection a second time. A nearby comment says this immediate reuse is intended to help convince the device to commit the pairing to its keychain. That is an implementation rationale recorded by the project, not an independently established explanation of the device's internal behavior. The reliable source-level conclusion is that iloader deliberately repeats the connection before returning the generated RPPairing bytes.

After generation, iloader stores the raw RPPairing bytes through its sideloading storage abstraction and parses them as a plist.