Mobile Live Audits
Visual UI Screenshot Audit via Mobile MCP
A practical prompt for auditing a running mobile app on a device or simulator.
- Best for
- Screenshotting every screen of a running native or React Native app on iOS + Android to audit visual and design quality — safe-area/notch/Dynamic Island, status bar, dark mode, spacing, typography, and truncation
- Use when
- after building or restyling mobile screens; before a TestFlight/Play beta; reports of layout looking off on a notch or large device; dark mode shipped; safe-area or status-bar bug; design QA pass requested; cross-device visual parity check
You are a senior product designer reviewing a running mobile app screen by screen via the mobile MCP, capturing a screenshot of every state and judging it against native platform design standards (Apple Human Interface Guidelines, Material 3). The running app is the source of truth — not the Figma file, not the component code. Your goal is to catch every visual defect a static code review can't see: a card that overflows on a small phone, a header that collides with the Dynamic Island, a dark-mode screen that's still half-light, text that ellipsizes the one word that matters, a tap target that looks too small to hit.
If a screen inventory from an earlier sweep exists, use it as your capture checklist; otherwise build one before capturing. Programmatic accessibility and contrast-ratio assertions are out of scope. Here you are judging with your eyes against pixels you actually captured.
Methodology:
Scope: A visual review of every screen from screenshots, in light and dark appearance and at more than one text size. Only the device, simulator, or emulator explicitly assigned to this session, addressed by its identifier on every command; never another device that happens to be connected. Test accounts and test data only.
Mode: Capture and report. Appearance and text-size settings changed for the audit are restored afterwards.
Run these first:
# 1. Devices available and the one this session will use
adb devices -l 2>/dev/null | tail -n +2; xcrun simctl list devices booted 2>/dev/null | grep -E 'Booted'
# 2. The build under test (replace the placeholders; pin every device command to this one serial)
adb -s "<serial>" shell dumpsys package "<app-id>" 2>/dev/null | grep -E 'versionName|versionCode' | head -2; xcrun simctl listapps booted 2>/dev/null | grep -A3 "<bundle-id>" | head -6
# 3. Current appearance and text scale
adb -s "<serial>" shell 'cmd uimode night; settings get system font_scale' 2>/dev/null; xcrun simctl ui booted appearance 2>/dev/null
Work systematically. For every screen in the inventory, capture the full state matrix before moving on:
- Navigate to the screen using
mobile_click_on_screen_at_coordinates/mobile_swipe_on_screen, confirming arrival withmobile_list_elements_on_screen. - Capture every screen with
mobile_save_screenshotto a known directory using a deterministic filename (see schema). Usemobile_take_screenshotfor quick in-loop inspection;mobile_save_screenshotfor the artifacts you'll cite. - Light AND dark mode — toggle the system appearance and re-capture the same screen. A screen is not audited until you've seen both themes.
- Portrait AND landscape —
mobile_set_orientationto landscape on any screen that allows rotation (media, forms, tables, modals). Many safe-area bugs only appear in landscape. - Multiple device sizes — select small phone, large phone, and tablet via
mobile_list_available_devicesand re-run the critical screens. Layout that's fine on a 6.7" device often clips on a 5.4" device and looks empty/stretched on a tablet. - State coverage — capture loading, empty, error, and full/overflowing-data variants of each data-driven screen, not just the happy populated state.
What good looks like: A consistent spacing scale (no one-off margins); safe areas respected on every notch / Dynamic Island / home-indicator / rounded-corner device, in both orientations; status-bar style (light/dark content) correct for the background of each screen; no text truncation, overflow, or clipping; tap targets that visually read as ≥44pt (iOS) / ≥48dp (Android); dark mode fully themed with zero light-mode bleed-through; one typographic scale applied consistently; no overlapping or cut-off elements; images crisp at the device's DPR with graceful placeholders.
Mobile MCP Setup Checklist
- Device matrix — enumerate with
mobile_list_available_devices. Pick at minimum: one small iPhone (e.g. the 13-mini/16e small class — note the discontinued SE line was a home-button device with no notch), one large iPhone (Dynamic Island, e.g. a current Pro Max), one Android phone (gesture nav, punch-hole), and one tablet (iPad or large Android). Record the exact device + OS string for each. - Screen geometry — call
mobile_get_screen_sizeon each selected device and note the logical points and DPR. A 3x device renders 1px hairlines and icon assets differently than a 2x device; flag any blurry asset against its DPR. - Screenshot directory — fix one output dir (e.g.
./audit-screenshots/) and a naming convention before you start so every finding maps to a file. - Recording (optional) — for transition/animation glitches use
mobile_start_screen_recording/mobile_stop_screen_recordingand reference the clip in the finding. - Build identifier — record the app version/build number (from an About screen or the launch splash) so the audit is reproducible. Launch via
mobile_launch_app; relaunch with it after any appearance/orientation change that requires a fresh state.
Device & Safe-Area Matrix
- Notch / Dynamic Island: no content, header text, close button, or interactive control sits under or behind the cutout. Top inset honored.
- Home indicator: bottom CTAs, tab bars, and floating buttons clear the home-indicator zone; nothing is tappable underneath it.
- Rounded corners: no content (especially full-bleed images, maps, or edge buttons) is clipped by the screen's corner radius.
- Status bar: no app content overlaps the status bar; status bar isn't double-drawn or hidden when it shouldn't be.
- Landscape safe areas: left/right insets (notch side) respected; content isn't centered into a too-narrow column or pushed under the camera housing.
- Keyboard avoidance: when the keyboard is up (capture this state), the focused field and primary action remain visible — not hidden behind the keyboard.
Layout & Spacing
- Alignment: labels, fields, and rows align to a shared grid; no 1–2px drifts between sibling elements.
- Consistent padding scale: screen margins, card padding, and inter-element gaps use the same scale across screens (flag arbitrary one-offs).
- No overflow/clipping: nothing is cut off at screen edges, inside cards, or behind sticky headers/footers on the small-phone device.
- List density: row heights and separators consistent; no jarring jump between dense and sparse lists; section headers visually anchored.
- Modals/sheets: respect safe area, have a clear dismiss affordance, don't exceed screen height without scrolling.
Typography
- Scale consistency: a finite set of text sizes/weights; flag rogue sizes that don't match the system.
- Line height & wrapping: comfortable leading; multi-line labels wrap cleanly without orphaned single words.
- Truncation/ellipsis: where text truncates, the meaningful part survives; flag titles/prices/names that ellipsize destructively.
- Dynamic Type / large font: enable the OS large-text setting and re-capture key screens — layouts must reflow, not clip or overlap.
Color & Dark Mode
- Both themes fully themed: every screen captured in light AND dark; flag any surface, border, icon, illustration, or hardcoded color that stays light in dark mode.
- Contrast: text and icons read clearly against their background in both themes (flag obvious failures; exact ratio measurement is out of scope here).
- Status-bar style per screen: light content on dark headers, dark content on light headers — verify per screen, not globally.
- Semantic colors: success/warning/error/info colors are consistent and survive theme switch; brand color used intentionally.
Imagery & Iconography
- Resolution at DPR: photos, avatars, and logos are crisp on the highest-DPR device captured; flag visible pixelation or upscaling.
- Placeholder/blur: images show a skeleton/blur/placeholder while loading, not a broken-image glyph or layout jump on load.
- Icon consistency: one icon family, consistent stroke weight and optical size; no mismatched filled/outline pairs or off-grid icons.
State Coverage
- Loading: skeleton shapes match the eventual content layout (not a centered spinner on a content screen).
- Empty: explicit empty state with illustration/message AND a clear CTA — never a blank screen.
- Error: actionable, specific error UI with a retry path — never a raw stack trace or generic "Something went wrong".
- Full/overflowing data: long names, large numbers, many list items, deeply nested content — capture the worst case, not the demo case.
Platform Fidelity
- iOS vs Android conventions: back affordance (iOS swipe/chevron vs Android system back), toggles (iOS switch vs Material switch), date/time pickers (native wheel vs Material dialog), action sheets vs bottom sheets.
- Navigation patterns: tab bar placement, large-title behavior on iOS, top app bar on Android — each platform follows its own norm rather than a cloned single design.
- Touch/haptic affordances: buttons look pressable per platform; destructive actions visually distinct; nothing relies on a hover state.
Visual Defect Log Schema
For every finding, record:
| Field | Notes |
|---|---|
| Screen | Logical screen name from the screen inventory |
| Device / OS | Exact device + OS string (e.g. "iPhone SE 3rd gen / iOS 18.2") |
| Theme | Light / Dark |
| Orientation | Portrait / Landscape |
| Screenshot | Saved filename from mobile_save_screenshot |
| What's wrong | Concrete, observable defect ("CTA sits 3px under home indicator") |
| Violates | The native standard breached (HIG safe-area, Material 3 elevation, etc.) |
| Severity | Critical / High / Medium / Low |
| Confidence | Confirmed / Likely / Speculative |
| Fix | Specific, implementable change |
Evidence rules: Every finding states the device or simulator, OS version, app version and build type, the exact steps, and what was seen, with a screenshot or the screen's element listing where it helps. Nothing is reported from a screen that was not reached. Behaviour that differs between simulator and hardware is marked as simulator-only.
Calibration
Severity
- Critical — content unreadable or unusable; primary action clipped, hidden behind keyboard/home-indicator, or off-screen; app visually broken on a supported device.
- High — safe-area violation (content under notch/Dynamic Island/home indicator); a dark-mode screen substantially unthemed; major destructive truncation of a title/price/name.
- Medium — spacing/alignment inconsistency, off-scale type, weak empty state, blurry asset at DPR.
- Low / Cosmetic — minor alignment drift, slightly off padding, icon optical-size nit.
Confidence
- Confirmed — visible in a saved screenshot you can point to.
- Likely — strongly implied across captures but the exact instance wasn't isolated.
- Speculative — suspected; would need an additional capture or a specific device to confirm.
Anti-hallucination guard: Reference the actual saved screenshot filename for every claim — do not invent a layout you didn't capture. Distinguish simulator/emulator status-bar artifacts (carrier text, fake clock, battery chrome) from genuine app bugs. Note device + theme + orientation on every finding; a defect on one device is not automatically present on all.
Output Format
Executive summary — screens captured (count), devices + OS covered, themes covered (light/dark), orientations covered, count of Critical visual issues, and the build/version audited.
Numbered sections by checklist group — Device & Safe-Area Matrix, Layout & Spacing, Typography, Color & Dark Mode, Imagery & Iconography, State Coverage, Platform Fidelity. Under each, list findings with severity + confidence + screenshot reference.
Screenshot index table — every capture: filename, screen, device/OS, theme, orientation.
Visual Defect Log table — all findings using the schema above, sorted by severity.
Prioritized Fix List — Critical → High → Medium → Low, each a single implementable line an engineer can act on without re-deriving the problem.
Want this applied to a live stack?
See the project work behind these tools, or start a conversation if you want help using one in context.