Most bug reports from users say "it does not work". A useful one says which screen, which button, which app version and which phone. This guide shows how to collect reports like that from a SwiftUI app, with no form for the user to fill in and no account for them to create.
What one report contains
Every report that Nitpick receives has the same fields, so your agent and your dashboard can filter on them:
| Field | What it tells you |
|---|---|
comment |
What the user wrote, 1 to 2000 characters. |
kind |
general for a comment about the app, specific when the user pointed at something. |
screen |
The screen name you gave with .nitpickScreen. |
element and element_match |
The element you named, and whether the tap was exact, nearest or none. |
tap, element_frame, viewport |
Where the user tapped and the box of the element, in points. |
app_version and build |
For example 1.4.2 and 87. |
device |
Model identifier such as iPhone16,1, the iOS version and the language. |
sdk |
The component and its version. |
A report never has a name, an email address, an account id or the name the user gave their phone. Feedback is anonymous, which also means you cannot write back to the user.
Make the reports point at your code
The fields screen and element only help if you name things. Add .nitpickScreen("Checkout") to each screen and .nitpickElement("checkout.pay_button") to the buttons, fields and cards people tend to point at. Choose names that lead to the file, so an agent can search for the exact string:
Button("Pay") { pay() }
.nitpickElement("checkout.pay_button")
A report with element: checkout.pay_button and element_match: exact means the user tapped that very button. With nearest they tapped within 44 points of it, and with none only the screen is known. The screenshot still shows the rest.
Read and sort the reports
List what is open, filtered by the version in which it happened:
nitpick feedback list --app-version 1.4.2
nitpick feedback show <id> --screenshot report.png
Your agent does the same with the MCP tools list_feedback and get_feedback, and feedback_stats counts open reports by screen, by element and by app version. That shows you in one call which screen produces the most trouble.
Close the loop
Let your agent fix a report and then call resolve_feedback. If the problem comes back in a later version, reopen_feedback makes the report open again. The prompt that sets all of this up is on Claude Code with SwiftUI, and the commands are in the CLI reference.
Two rules for good reports
Keep the General option for opinions and use Point at something for bugs. Mask personal data on screen with .nitpickMask(), because the screenshot is part of the report. See how the screenshot works. If you have not added the component yet, start with in-app feedback for SwiftUI. The MCP tools are described in the MCP reference.