Practical guide · 3 min read
Turn iPhone Mirroring captures into useful UI feedback
Capture the relevant states, write a bounded implementation request, and verify the result on the same device state.
Ali AbouelattaFounder and writer on product growth, monetization, and screenshots.
Give the coding agent the screen and the decision it needs to make.
An iPhone screenshot can show a clipped button. A crop can leave out the keyboard or the preceding screen, and the image does not explain which layout you expected. Include those details with the image rather than hoping the agent will infer them.
This is a proposed review workflow using Apple's documented mirroring and screenshot features. It is not a claim that every iPhone app or protected screen can be captured.
Get the right screen onto the Mac
Use Apple's iPhone Mirroring setup guide to check current device, account, and regional requirements. The guide requires compatible devices, the same Apple Account, Wi-Fi and Bluetooth, and a nearby locked iPhone. Some iPhone features are unavailable while mirroring.
Open the app state you want reviewed and record the device, app version, and action that led there. Keep the mirroring window at the same size for before-and-after comparisons. If the connection pauses or the app replaces the content with a protected view, resolve that condition before diagnosing the layout from a blank capture.
Capture enough context to reproduce the problem
For a layout issue, include the affected control and nearby content. For onboarding, capture the preceding screen, the failing screen, and the next visible state in order. Do not combine frames from different accounts or experiments and present them as one flow.
Use the Mac's documented region or window capture, or the capture workflow you already use in LazyScreenshots. Inspect the saved image before attaching it. A working mirroring connection does not establish that the screenshot contains the pixels you need.
| Question | Include with the capture |
|---|---|
| Why is this button clipped? | Device and text-size setting, keyboard state, expected placement |
| Where did onboarding lose context? | Ordered frames, actions between them, and the stated user goal |
| Did the fix work? | Before and after from the same device state and viewport |
| Is this a copy or layout problem? | The exact text, what the user should understand, and what they can do next |
Write one bounded request
For example, using a fictional checkout screen:
The primary button is clipped when the keyboard opens. Image 1 shows the screen before focus; image 2 shows the focused address field. Keep the desktop layout and existing copy. Find the cause, make the smallest change, and verify the focused state at the same size.
Number annotations only when the order helps. A circle around everything leaves the agent with the same uncertainty as an unmarked image. Remove private details with an opaque cover or a crop, then reopen the exported image and verify they are gone before sharing.
Verify the change on the device
After the code changes, repeat the original steps on the same device state. Check the neighboring screen and one condition the first capture did not cover, such as larger text or a longer translated label. Keep an actual failed result when it explains what still needs work.
Use the capture-to-AI workflow for the screenshot handoff, and the onboarding review template when the issue spans several screens. The attachment supplies evidence; your reproduction steps define the test.
Disclosure
Ali owns LazyScreenshots. That creates a conflict when he writes about LazyScreenshots or reviews competitors, so relevant pieces say so plainly. These articles are research and opinion, not independent third-party ratings.