The PoC writes one canary instead of opening the file system
Airlift demonstrates a specific iOS sandbox escape through AirTraffic, the media-sync path used by a Mac and a paired iPhone. It does not install an iOS app. The host stages a random canary, moves it outside the expected media directory, reads the exact bytes back, then removes the generated paths. The README lists 12 directories where fresh-file writes were confirmed, including SpringBoard, SMS, Safari, app containers, and /var/tmp.
That narrow behavior is a reason to consider Airlift over an improvised exploit script. The Python driver rejects root or relative target paths, generates fresh names, snapshots tracked Books artifacts, and authorizes cleanup only after its preconditions pass. Its result records whether the bytes matched, whether cleanup completed, and whether the Books state was restored. Existing files are not exposed as general read, write, or delete targets.
The limitation is equally important. Airlift is evidence for a path-validation flaw, not a supported way to modify an iPhone. Reads are indirect: the PoC moves a known file into Media, retrieves it through AFC, and moves it back. The README says MobileGestalt is outside the verified scope. If you want a jailbreak, backup browser, device manager, or persistent modification tool, this repository is the wrong shape.
Two private macOS frameworks make the real build Mac-only
The Makefile builds 2 native helpers with xcrun clang. One links Apple's private MobileDevice framework, while the other links AirTrafficHost. Both are ad-hoc signed after compilation. The Python entry point then calls xcrun devicectl to find paired physical iPhones and runs those helpers for staging, AirTraffic moves, AFC reads, restoration, and cleanup. A Debian build check cannot reproduce that device path.
The documented workflow is short: run make, then ./airlift.py. You can choose a paired iPhone interactively, pass its UDID with --device, select another absolute destination with --target, and request helper diagnostics through --verbose. No API key or hosted account appears in that flow. You do need a Mac with the relevant frameworks and a paired iPhone reachable over USB or Wi-Fi.
Main currently has no Windows host. Issue 1 asks for Windows support, and draft pull request 3 proposes a host based on Apple Mobile Device Support plus pymobiledevice3. The pull request had no comments or review comments when checked and was not merged. Linux is a poorer fit because the current Makefile names macOS framework paths directly. For ordinary cross-platform phone communication, libimobiledevice or pymobiledevice3 is a better starting point.
What happened when we ran it
Our fresh Debian sandbox cloned commit c684cd4 with 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. Installation succeeded in 15 seconds, added 35 packages, and occupied 37 MB. The detected build step succeeded in another 6 seconds. Pip-audit reported 0 known vulnerabilities.
There was no test script or target, so the pipeline skipped tests. The repository had 9 files, about 548 lines of source, and a 0.2 MB checkout. It contained no CI workflow, Dockerfile, or tests directory. Those are useful measurements of the small repository and Python environment. They do not prove that the two native helpers compile on macOS or that a write succeeds on a phone.
We did not pair an iPhone, invoke AirTraffic, or touch device storage in this sandbox. Our successful 6-second build check must stay inside that boundary. Airlift's meaningful acceptance test needs the intended host framework, a specific iOS build, exact-byte recovery, complete cleanup, and confirmation that the Books preimage returned. The repository automates those last checks, but our container could not supply the first two conditions.
iOS 27.0 final has conflicting public reports
The README says the PoC was tested on iOS 27.0 RC build 24A435 and should also work on final build 24A437. Other iPhone builds are allowed with a warning. That wording is appropriately narrower than a broad compatibility claim, but current issue activity makes 24A437 a question buyers must test rather than assume.
Issue 4 reports that staging on 24A437 stops with kAMDInvalidCheckinError. Its author attributes the failure to an entitlement gate around streaming_zip_conduit and provides diagnostics, but there was no maintainer response when checked. The main repository's last code push was September 15, 2026, before that September 27 report. An open report is evidence of one failed environment, not a universal result.
Draft pull request 3 points the other way. Its author reports an exact 83-byte canary readback on an iPhone 15 Pro running the same final build, using a proposed Windows host. That code is unmerged and its claim was not part of our lab run. Together, the two reports say host path, signing, or device conditions may matter. They do not establish one dependable final-build recipe on main.
Four open items and no tests keep this in research territory
GitHub showed 352 stars and 4 combined open issues and pull requests. Three were issues and one was the draft Windows pull request. There is no tagged release, and the repository has no automated test target or visible CI workflow. Issue activity continued through September 28, 2026, but code had last been pushed on September 15. That is a recent PoC with active interest, not a maintained compatibility matrix.
The code deserves credit for limiting its own power and checking cleanup. Use it when the question is whether this AirTraffic path can cross its intended directory boundary on hardware you control. Keep the phone expendable, record the exact host and iOS builds, and require every cleanup flag to pass. If your goal is routine device access, choose a general library. If your result depends on 24A437, reproduce it before drawing any conclusion.