Ninety seconds to screenshot 25 mobile screens, analyze each for visual bugs, and file reports - that's the automated QA pipeline developer Christopher Meiklejohn built by connecting Claude to Android and iOS emulators for his community app, Zabriskie.
The setup is clever in its simplicity. On Android, a Python script uses adb shell screencap to capture each screen, then pipes the images to Claude for visual analysis. Claude looks for broken layouts, missing images, error states, and UI inconsistencies. When it finds something, it files a formatted bug report to the project's production forum. The whole Android side took about 90 minutes to build.
iOS was a different story - six-plus hours of fighting Apple's lockdowns. The core problem: Apple's WKWebView doesn't expose Chrome DevTools Protocol the way Android's WebView does, which means you can't programmatically control the browser layer inside the app. Meiklejohn had to resort to coordinate-based tapping, direct writes to the iOS Simulator's privacy database, and accessibility APIs via ios-simulator-mcp to discover UI element positions instead of guessing pixel locations.
Android vs. iOS: Night and Day
The gap between platforms is striking. Android gave Meiklejohn full Chrome DevTools Protocol access through WebView socket forwarding - essentially the same debugging tools you'd use in a desktop browser. iOS required workaround after workaround. AppleScript couldn't even type "@" symbols into fields, forcing a backend change to accept usernames instead of email addresses for login.
The pipeline now runs daily at 8:47 AM. Both emulators boot, Claude authenticates to each platform, sweeps all 25 screens, and uploads screenshots to S3 through a bot account. First Android run came back clean with zero critical issues.
The Practical Takeaway
Meiklejohn's biggest lesson: prefer protocol-based automation over coordinate-based tapping whenever possible. Tapping at specific pixel coordinates breaks when screen sizes change, when UI elements shift, or when the simulator runs in a different display mode. Protocol-level control (like Chrome DevTools Protocol on Android) gives you reliable, repeatable interactions regardless of visual layout.
This approach works specifically because Zabriskie uses Capacitor, which wraps a React web app in native shells. The app sits in a weird testing gap - "too native for web tools and too web for native tools," as Meiklejohn puts it. Claude's visual analysis fills that gap by treating each screen as an image to inspect rather than a DOM to traverse.
For teams building hybrid mobile apps with similar stacks, this is a template worth studying. The Android path is straightforward enough to replicate in an afternoon. The iOS path is a cautionary tale about Apple's approach to automation - but the accessibility API workarounds documented here could save someone else those six hours of trial and error.