pymobiledevice3 keeps a Python 3.9 floor by pinning an old dependency

One install line and three commands that prove it works

Installation is a single command:

python3 -m pip install -U pymobiledevice3

Verification is three more, given immediately after it:

pymobiledevice3 usbmux list
pymobiledevice3 syslog live
pymobiledevice3 apps list

Those three are the whole smoke test. The first asks the usbmux service what devices are attached, the second streams the system log live, and the third lists installed applications. Each one maps to a different layer of the stack, so a failure in the first with a failure in the third means something different.

The file claims Windows, Linux and macOS support and says it ships both a command line tool and a Python API, so those three commands and the equivalent API calls are two faces of the same surface rather than two products.

The Python 3.9 floor costs an older dependency release

The package declares `requires-python` as 3.9 or newer and the classifiers run from 3.9 through 3.15, so the floor is deliberate rather than leftover. Keeping it costs something, and the dependency list says what.

There is a comment attached to `construct-typing` that explains it. Version 0.8.0 of that package requires Python 3.10 or newer and replaces one field constructor with a differently named function, referenced to a specific source file. So the dependency is declared twice under environment markers: 0.8.0 or newer when the interpreter is 3.10 or later, and 0.7.0 with an upper bound below 0.8.0 when it is older.

A second pin is less explained. `gpxpy` is required at anything below 1.7.0 with version 1.6.0 explicitly excluded, so a version nobody can install is carved out of an otherwise open range. Both pins are the kind of thing that reads as a maintenance burden six months later, when the comment explaining the first one is the only record of why the code looks the way it does.

A shell and a notebook environment are hard dependencies

The dependency list runs to two dozen names and most of them are protocol libraries that belong there: construct for the binary formats, asn1 for certificates, pyusb for USB access, cryptography at 43 or newer, pykdebugparser for kernel debug logs, pycrashreport, bpylist2 for the property list format Apple uses in plists, pygnuutils, parameter_decorators, typing_extensions, packaging, requests, tqdm and pygments for output.

Two of them do not fit that pattern. IPython is a notebook environment, and xonsh is a Python-native shell. Both are unconditional requirements, not extras, so every install of this package pulls them in whether or not anything uses them.

That is not automatically wrong. A tool with an interactive shell and an embedded notebook can be pleasant to drive from a Python prompt, and this one does expose a Python API as a first class surface. But it does mean the install footprint is decided by features most users will never touch, and the file gives no extras group to opt out of them.

Two patch releases in forty one minutes, then a minor bump

The three newest releases are v11.20.1 on 2026-09-30 at 12:15, v11.20.2 the same day at 12:56, and v11.21.0 on 2026-10-04. Two patch releases forty one minutes apart is a fast correction, and the minor version bump two days later says the fix was not considered patch sized.

The last push to the default branch is dated 2026-09-24, before all three of those tags. So the published builds come from tag points that are not visible in the branch's push history, which is what a release workflow driven by tags rather than by branch commits looks like from the outside.

Nothing in the file explains the version scheme. The version field itself is dynamic rather than written down, so it comes from the release tooling, and a reader has no way to tell from the packaging whether v11.21.0 corresponds to a compatibility break.

The plugin is a Claude Code plugin documented under a Codex URL

The repository ships its device operator agent skill as a Claude Code plugin, installed with two commands:

/plugin marketplace add doronz88/pymobiledevice3
/plugin install pymobiledevice3-device-operator@pymobiledevice3

The link text says the skill teaches an agent to operate a connected iPhone or iPad through pymobiledevice3, and the plugin name in the second command carries a device-operator suffix matching that description.

The link it points at does not match. Its path ends in a codex-device-operator-skill slug while the surrounding text is entirely about Claude Code. So the same skill is presented as a Claude Code plugin and documented at an address named for a different assistant. Both of those can be true at once, since the repository also carries a .codex/ directory alongside .claude/, but nothing in the file says which agent the skill is actually written for.

The documentation goes down to RemoteXPC and DTX

The docs are a MkDocs site built from the `docs/` directory with a `mkdocs.yml` beside it and an `overrides/` directory for theme changes. Seven entry points are linked from the file, and they divide cleanly by audience.

Three are operational: installation and platform notes, CLI recipes, and a page on iOS 17 and later tunnels with a support matrix. Two are for code: a Python API guide and a separate API reference. One is protocol internals, described as covering RemoteXPC, DTX and the iDevice layers.

That last one is the differentiator. Most tooling for this device family is documented as a set of commands, and this one documents the transport stack the commands are built on, which is what makes the DDI and DVT developer tooling for iOS 17 and later over a tunnel a usable feature rather than a black box.

Two assistant directories, a markdown linter and a sponsors folder

The top level is mostly project furniture. There is a `.claude/` and a `.codex/` directory, an AGENTS.md and a CLAUDE.md, a pre-commit configuration, and a markdown lint setup made of `.markdownlintignore` plus `markdownlint-config.json` with matching disable and enable markers in the file itself.

Then the Python project bits: `pyproject.toml`, `pytest.ini`, `MANIFEST.in`, the package directory and `tests/`.

One directory has nothing to do with the library. `misc/` holds the sponsor artwork, and the sponsor block in the file references a path inside it for a dark mode image, served from a raw content address pinned to one commit. Alongside that sit a test infrastructure vendor, a Discord community link and a PEP 691 package index badge, so the file mixes release, sponsorship, community and install information in one header without separating them.

Editorial conclusion

pymobiledevice3 fits a developer who needs to automate a physical iPhone or iPad from a host machine rather than from Xcode, and who wants a Python API and a CLI over the same protocol layer. Two things to check first. Read the platform notes for your host before expecting the same USB behaviour everywhere, since the file points at a dedicated installation page rather than repeating them. And know what you are pointing it at, because everything in the highlight list, from AFC file access to syslog streaming to backup and restore, acts on a device that has to be paired and unlocked, so the consent boundary is the same one you would draw for any tool that can read a phone's contents.

Frequently asked questions

Official sources

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