In-app support: which device details to collect, and which to leave out
Five details make most bug reports answerable. Everything else is a privacy cost with no benefit.
Why “it does not work” is hard to answer
The most common support message is short: “The export does nothing.” Before you can help, you need to know which version of your app the person runs, on which device, and with which system version. Asking for that by email costs a day per round trip, and many users never answer the second message.
An in-app support form can attach these details automatically. The user writes one sentence; you get a report you can act on.
The five details that matter
| Detail | Example | Why it helps |
|---|---|---|
| App version | 2.4 | Tells you whether the bug is already fixed in a newer release |
| Build number | 118 | Separates TestFlight builds that share a version number |
| OS version | iOS 18.1 | Many bugs appear on one system version only |
| Device model | iPhone15,4 (an iPhone 15) | Screen size, memory and hardware features differ. The hardware class is shared by millions of devices, so it identifies nobody |
| Language and region | de_DE | Explains date, number and layout problems, and tells you which language to reply in |
These five answer most first questions. They are also safe to collect: none of them identifies a person.
What to leave out
It is tempting to collect more “just in case”: location, the advertising identifier, a log of the last screens someone opened. Do not. Each extra field has a cost:
- Privacy law. The GDPR asks you to collect only the data you need for the purpose (the principle of data minimisation). “It might help one day” is not a purpose.
- App Store privacy details. Everything your app collects, including through a third-party tool, belongs in your App Store privacy details. Less data means a shorter, friendlier label.
- Trust. A user who reads that a support form sends their location will think twice before using it.
Email only when a reply needs it
Many support forms make the email field mandatory. That stops some people from writing at all. A better rule: the user can send the message without an address, and you show the reply in the app. Ask for an email address only as an option, so the reply can also reach them outside the app, and use it for nothing else.
A picture explains more than a paragraph
For layout bugs and odd behaviour, a screenshot or a short screen recording saves several messages. Let users attach them to a support message, and keep the limits clear so nobody uploads a ten-minute video by mistake.
How InsightsKit handles it
The InsightsKit Swift client fills in app version, build, OS version, device model and locale on every support message. That list is the complete set the server accepts: no location, no advertising identifier, no behaviour history. You reply from the dashboard, and the user reads the reply in the app. On the Basic plan and above, users can add screenshots and videos to a message. All data is stored on a server in the EU.
InsightsKit gives your app a ranked feature board and a support inbox, on iOS, Android or the web. Your users need no account, and the price stays flat however many users you have. Free for your first app.
Create a free account