In this guide
This page is about the form itself. When and how to ask is covered in ask for in-app feedback without nagging.
Keep it short
Every extra field costs answers. Start with the minimum:
- Type (optional chips): Bug, Idea, Question, Other.
- Message (required): one multi-line field. Placeholder: "What happened, or what would help?"
- Contact (optional): email, with a note on why you ask ("only if we need to ask back").
- Screenshot (optional): one tap to attach.
Four fields is a ceiling to start from, not a rule. Add a field only when you would act on the answer.
Layout example (Example)
Send feedback
[ Bug ] [ Idea ] [ Question ]
+--------------------------+
| What happened? |
+--------------------------+
[ Attach screenshot ]
Email (optional): ________
[ Send ]
Placement of the entry point
- Settings or profile screen: always available, low noise. Good default.
- After a task: a small "Something off?" link after a key flow, not a pop-up.
- Error screens: a "Report this" button right where the user is stuck.
- Gesture (shake): fine as an extra, never the only way; many people will not know it.
Attach automatically
Context saves a round of questions. Candidates: app version and build, OS version, device model, locale, and the screen the user was on. Attach only what you need and say so in a short line. Do not attach account content or free-text logs without consent. This is not legal advice; check the rules that apply to you.
Details that matter
- Confirm after sending ("Thanks, we read every message") and return the user to where they were.
- Keep the text they typed if sending fails.
- Make it usable with large text and a screen reader.
- Route messages to one place you really read: see feedback channels for apps and weekly triage routine.
Test the form itself
Ask a few testers to send feedback and see where they stumble. AppReviewX offers private, structured feedback from other developers; one feedback you write earns one credit. Get started.
Hub: app feedback guide.