iOS 6 comes with built-in support for remote debugging (1 minute screencast). It plays nice with the new Safari Web Inspector which seems to be a 1 year old fork of WebKit Inspector. It misses some features such JS editing and WebSocket frames inspection.
Safari's Web inspector does use the WebKit remote debugging protocol. However, Safari does not use TCP/HTTP as a transport layer, thus making it incompatible with Chrome.
says Timothy Hatcher (aka Xenon), Apple employe
- What does Safari use for transport layer?
- Can I make a proxy from this mysterious transport layer to HTTP to make it work with Chrome DevTools?
The iOS WebKit Debug Proxy project enables this.
To get started, install with homebrew:
brew install ios-webkit-debug-proxy
Run the simulator (if running simulator):
SIM_DIR=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer
"$SIM_DIR/Applications/iPhone Simulator.app/Contents/MacOS/iPhone Simulator" \
-SimulateApplication \
$SIM_DIR/SDKs/iPhoneSimulator6.1.sdk/Applications/MobileSafari.app/MobileSafari
Run the proxy:
ios_webkit_debug_proxy
Check for errors
Look on the device for an error message:
Could not connect to lockdownd. Exiting.: No such file or directory. Unable to attach inspector ios_webkit_debug_proxy
Then check the device for a prompt like this (iOS 7 example: )
Trust the currently connected computer?
Choose "Trust" and try rerunning the proxy:
ios_webkit_debug_proxy
Open default devtools
Then open http://localhost:9221
The DevTools are, by default, an older version (from Chrome 18 circa March 2012).
Try modern devtools
Due to protocol changes, parts the modern DevTools frontend may not work completely. You can try by opening
chrome-devtools://devtools/bundled/inspector.html?ws=localhost:9222/devtools/page/2
where the port
and page
values are the values you're seeing from http://localhost:9221
. Again, this may indeed be buggy.
Read more docs at the ios-webkit-debug-proxy project page.
Update: This works with iOS7 as well. Update: Added fresh devtools frontend instructions via patrick.. Update: Changed devtools.html to inspector.html for Chrome 45, and the new ws
hack via Scheintod.
According to https://github.com/andydavies/node-iosdriver,
Safari uses the same debugging commands as Chrome but wrapped as binary plists over RPC rather than JSON over websockets.
So, yes, it would possible to write a proxy.
I found this thread by looking at what TCP connections Safari was making while connected to the MobileSafari inspector, seeing that it was connected to a process called webinspectord
and Googling that:
# pgrep -lf /Applications/Safari.app
33170 /Applications/Safari.app/Contents/MacOS/Safari -psn_0_21144617
# lsof -p 33170 | grep TCP
Safari 33170 ryan 16u IPv6 0x799d5f43b472a241 0t0 TCP localhost:54892->localhost:27753 (ESTABLISHED)
# lsof -i :27753
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
launchd 371 ryan 42u IPv6 0x799d5f43b472aa01 0t0 TCP localhost:27753 (LISTEN)
Safari 33170 ryan 16u IPv6 0x799d5f43b472a241 0t0 TCP localhost:54892->localhost:27753 (ESTABLISHED)
webinspec 33182 ryan 6u IPv6 0x799d5f43b472aa01 0t0 TCP localhost:27753 (LISTEN)
webinspec 33182 ryan 7u IPv6 0x799d5f43b181a621 0t0 TCP localhost:27753->localhost:54892 (ESTABLISHED)
# ps p 33182
PID TT STAT TIME COMMAND
33182 ?? S 0:00.28 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/libexec/webinspectord