Debugging an iPhone From Windows Over USB: Screenshots and Logs With Python

By Nesim Razon, independent Android developer · 2026-11-14

#Dev notes#iOS

On Android, adb makes it easy to take a screenshot or read a log from a phone on your desk. I expected nothing like it for an iPhone on Windows, but there is a way: Apple's own driver package plus an open source Python tool. Here is the setup that worked on an iPhone 7 running iOS 15.8, the traps in the order I hit them, and a real bug I solved with it.

What you need

• The Apple Devices app from the Microsoft Store. It brings the USB driver for iPhones, and winget can install it.
• Python 3 and the pymobiledevice3 package.
• A phone with a cable, the screen unlocked, and the Trust prompt accepted on the phone.

Install order matters

After installing Apple Devices, the iPhone still showed up in Device Manager with an error status, and the tool answered that it could not connect to the usbmux socket. The fix was to open the Apple Devices app once with the phone connected and unlocked, accept the Trust prompt, and let it finish installing the drivers. Only then did the phone list correctly.

The Python trap

On my machine the first python on the path was an old Python 2.7, so the plain pip command installed nothing useful. On Windows the py launcher picks the right one: install with py -3 -m pip install pymobiledevice3 and always run the tool as py -3 -m pymobiledevice3, because the executable it creates is not on the path.

Four commands I use all the time

• usbmux list shows the connected phone with its model and iOS version.
• mounter auto-mount downloads and mounts the developer disk image once. On iOS 15 I did not have to turn on any Developer Mode.
• developer dvt launch followed by the bundle identifier starts the app.
• developer screenshot followed by a file name saves what the screen shows right now.

Reading the log without drowning

syslog live prints everything the phone logs, which is far too much. Filtering by process name keeps only your app. Even then my app produced more than a megabyte of log in thirty seconds, so I write the output to a file and search it afterwards instead of watching it scroll.

Your own messages are the easiest to find. In Swift a call to NSLog shows up in this log, so I tag my lines with the app name and search for that tag.

A real example: why was the banner empty?

My game showed no ad banner after I switched from Google's demo ad unit to the real one. The phone gave no visible error. I added a small delegate to the banner view that writes the result of the ad request with NSLog, built it, installed it through TestFlight and read the log over USB.

The answer was one line: no ad to show. That means the ad server had nothing to fill with, which is normal for a brand new ad unit in an app that is not on the store yet. Without the log I would have kept looking for a bug in my code.

Limits and privacy

A screenshot captures whatever is on the screen, and an unfiltered log contains lines from other apps. If the phone is shared, as mine is with another project, I only launch my own app first and filter the log by its process name. The tool works over the trust you give the computer, so only accept the Trust prompt on machines you own.