Apple Devices is installed, but the USB service is not running
The phone appears in Apple Devices and nothing can debug it. Port 27015 is the tell, and one command settles it.
Fixes → Every route, without a Mac
How to debug iOS Safari without a Mac, in 2026
You are on Windows or Linux, something renders wrong in Safari on a real iPhone, and you cannot open Web Inspector. Here is every route, what each one asks of you, and where each one stops. We sell one of them, and we have marked which.
The short answer
All of these work. Start with the free ones. If you
need a phone connected over USB and you are debugging web content, the
open-source route is genuinely capable and costs nothing. It asks you to
assemble and run it yourself, and it says little when a step fails.
See the process on a real phone in our 72-second Windows and iPhone setup video, with a written checklist and transcript.
The routes
ios-webkit-debug-proxy: free, and the foundation of most of the rest
Google's proxy speaks WebKit's remote inspector protocol over USB and exposes it on a local port. It runs on Windows and Linux. Nearly everything else in this list sits on top of it, including our own product.
Where it stops: it is infrastructure, not a tool. You get a daemon and a port. When the chain breaks it reports what it can see, which is usually an empty list, and the same empty list covers four different causes. The upstream repository has been dormant since the middle of 2025.
remotedebug-ios-webkit-adapter: free, gives you Chrome DevTools
Translates the WebKit protocol into something Chrome DevTools understands, so you inspect an iPhone page in a familiar DevTools window.
Where it stops: you are running two processes and wiring a debugger to a port by hand, and the translation is not complete. Some Chrome DevTools features have no WebKit equivalent and simply do nothing.
ios-safari-remote-debug-kit: free, bundles the setup
Scripts that wrap the proxy and serve a real WebKit Web Inspector locally, which sidesteps the protocol-translation gap above.
Where it stops: still a scripted setup you run yourself, with no diagnosis when a step fails.
Free MCP bridges: for an agent, not for you
Open-source MCP servers exist that hand an AI coding agent access to iOS Safari through the same proxy. If your goal is to let an agent read a real phone's DOM, they work and cost nothing.
Where they stop: they are command-line bridges. The agent gets eyes; you get a configuration file and no workbench. There is also no permission model, so an agent connected this way can do whatever the protocol allows.
Apple's own Safari MCP server: macOS only
Apple shipped a first-party MCP server on 1 July 2026, in the Safari 27 beta and Safari Technology Preview 247, built on safaridriver.
Where it stops: it runs on macOS and drives desktop Safari windows. Apple's announcement describes no way to attach it to Safari on a physical iPhone and offers no Windows build, so for the problem this page is about it is not an option. Its guidance on access is to use only agents you trust. Checked against Apple's announcement on 1 September 2026.
Cloud device labs: no cable, no phone
Hosted real devices that you drive through a browser. Genuinely the right answer if you need breadth of device and OS coverage, or if you have no phone to hand.
Where they stop: it is not your phone, in your hand, with your local build and your logged-in session. Subscription pricing, and latency you feel.
Commercial desktop apps, including ours
A few paid desktop tools put a real workbench around the same underlying connection. Ours is one of them (CrocProbe); inspect.dev is the established one and is a capable product.
What you are paying for is not access to the phone; the free routes already give you that. It is the workbench, and the diagnosis when the chain breaks. CrocProbe's inspector is free with no session timer; a license adds page actions and lets you invite an agent under permissions you hold.
When it will not connect at all
Most of the time you are not choosing a tool, you are stuck. These three failures account for nearly all of it:
The proxy runs, but returns no targets
The port answers and the list is empty. Five causes produce that one message; here they are in the order that finds it fastest.
Connected, listed, and running nothing
A backgrounded iOS tab keeps answering the inspector while its JavaScript is suspended. It looks exactly like a broken connection.
What you will need regardless of route
- Apple's USB driver, from the Apple Devices app or iTunes. It is proprietary and no tool is permitted to bundle it.
- A trusted phone: the Trust This Computer prompt accepted, on an unlocked device.
- Web Inspector switched on, under Settings → Apps → Safari → Advanced.
- A data-capable cable. A charge-only cable produces a phone that charges and is invisible to everything.
- A Safari tab in the foreground. See the suspended-page note above; this catches people repeatedly.