There is a feedback link in the settings screen, it has been there since launch, and what comes through it reads like this: doesn't work. Sometimes there is a second sentence. Rarely is there a version number, a device, or any indication of which screen the person was looking at when it stopped working.
That is not a user problem. A person who has just hit a wall inside an app is annoyed, on a phone, and typing with one thumb. Every detail the form asks them to supply is a detail that will be missing or wrong. The fix is to stop asking for the context and start attaching it, and then to make sure the message that arrives goes to somebody by name rather than into a shared inbox.
Three routes out of an app, and what each one produces
| Route | What arrives | Can it be answered | What it costs |
|---|---|---|---|
| A store review | A rating and a public paragraph, no version, no contact | Publicly, once, in the store | Visible to every future buyer |
| An email address in settings | A message with whatever the user chose to include | Yes, if somebody is watching that inbox | Threads with no version, device or history |
| An in-app feedback form | Structured answers plus whatever the app attached automatically | Yes, with the original message attached | A little build work, once |
The order matters because these three compete. A user with something to say will take the easiest route available, and if the easiest route is the store, the complaint becomes a one star review that ranks alongside the app for months. An in-app form that takes one screen is the cheapest way to make the private route easier than the public one.
None of this removes the need for the store listing to carry real contact details. Apple's App Store Review Guidelines require the Support URL to include an easy way to make contact, and note that out of date contact information may breach the law in some countries. A feedback form inside the app satisfies the spirit of that only if the URL in the listing also works for somebody who has already deleted the app.
Attach the context instead of asking for it
This is the change that does most of the work, and it is usually an afternoon.
Everything the support team needs in order to reproduce a problem is already known to the app at the moment the form opens: the app version and build number, the operating system version, the device model, the locale, the screen the user came from, whether the person is signed in, and which account or workspace they belong to. Passing those into hidden fields on the form, or as parameters appended to the form URL when it is opened in a web view, means the shortest possible message still arrives with enough to act on. Doesn't work becomes doesn't work, version 3.2.1 build 884, iOS 18.6, on the export screen, signed in, and that is a reproducible report.
Two constraints go with it. The user has to be told what is being attached, in one sentence above the send button, because attaching account identifiers silently is the kind of surprise that ends up in a store review of its own. And the attached fields should be things the team will actually read. An app that appends forty diagnostic values produces a response nobody can scan, which is the same failure as no context at all in a different costume.
A screenshot upload is the other high value field, and it is worth the trouble it takes. One image removes most of the back and forth about which screen and which state, particularly for layout problems and for text that was cut off in a language the team does not read. Check the file size ceiling on whatever tool receives it before promising it in the interface, since photo attachments from a modern phone are larger than most free tiers expect.
Where the form lives and when it opens
Three placements, doing three different jobs.
A permanent entry in settings, labelled in plain words such as send feedback or report a problem. This is the one that must always exist, because it is where people look when something has gone wrong and they have already decided to complain.
A contextual prompt, shown immediately after a specific failure. If a payment was declined, an upload failed, or a search returned nothing three times in a row, that is the moment when a single question gets an accurate answer. The question should be about what just happened rather than about the app in general: what were you trying to do here.
A prompt tied to a completed task, for the positive side. Somebody who has just finished the thing the app is for is the only person who can explain what the app is actually worth, and that is where quotable material comes from. Ask permission before using it, with a checkbox and a field for the name and organisation.
Two variations are worth knowing about. During a beta, a gesture such as shaking the device to open the form collects far more than a settings entry does, because testers are looking for things to report and want the shortest possible path. And for an app shipped in several languages, the form itself should be in the language the app is running in, with the free text box accepting whatever the user types. Feedback arriving in a language the team does not read is still the most valuable kind, since it comes from the users least likely to be observed directly, and it only needs translating once it has arrived.
What to avoid is the rating prompt that interrupts a task, and in particular any home grown imitation of the store's own rating dialogue. Apple's guidelines are explicit that the provided API must be used to ask for a rating and that custom review prompts are disallowed, so an in-app form asking for stars that then pushes people towards the store is a review risk as well as an annoyance. A private feedback form is a different thing from a rating prompt, and keeping the two visibly separate is both safer and more honest.
The question set that fits one screen
Four fields, and a strong case for stopping there.
What kind of message is this, with three options: something is broken, an idea, something else. Three options can be scanned; a list of twelve cannot, and the twelve always end up mis-selected anyway.
One free text box, with a placeholder that shows the shape of a useful answer rather than instructions. A placeholder such as tried to export the March report and got an empty file does more to raise quality than a paragraph of guidance above the field.
A screenshot, optional.
A contact address, optional, with one line saying it will only be used to reply. This field is what decides whether a two word message is salvageable, because almost all short feedback is one question away from being actionable. Prefill it for signed in users and let them change it.
Everything else belongs on the form only if somebody is waiting to read it. A dropdown listing every screen in the app, a severity selector, a satisfaction score: each of those costs completions and none of them is more reliable than what the app already knows or what the free text says.
Sorting what arrives
An app feedback form succeeds at collection and then fails at everything after it, which is why teams end up with a folder of messages and no record of what was done about any of them. Four kinds arrive and they need four different first moves.
| What arrived | First move | Where it ends |
|---|---|---|
| A reproducible fault | Reproduce it on the reported version, then reply with what happens next | Fixed in a named release, or cannot reproduce with a reason |
| Confusion about where something is | Change the wording or the placement, then tell the person | Changed, with the date recorded |
| A request | Tag it so that repeats can be counted | Queued, declined with a reason, or shipped |
| Praise | Ask permission to quote, with a name | Approved for use, or kept private |
Three mechanics make that work in practice.
Every message needs a named owner. A shared inbox distributes responsibility evenly, which in practice means the awkward messages wait while the easy ones get three answers. Assigning each response to a person is the entire mechanism, and it is the thing a downloaded spreadsheet cannot do.
Every message needs a status that lives beside it. Without one, the second person to open a message cannot tell whether the user was already answered, and the two familiar failures follow: one user receives two different replies, and another receives none.
Replies have to be part of the record. Answered from somebody's own mail client, the reply is invisible next to the original message, and a month later nobody can say what the user was told or whether the fix was ever mentioned to them. Sending from the same screen the response lives on, and keeping the sent message attached, is what makes the history worth keeping. Those three together are the difference between a form builder and a tool with response management, and they are what the use cases built around support intake actually depend on.
One more mechanic pays for itself on mobile specifically. Keying responses to the same person by email address means the third message from one user sits with the first two, which changes how it reads. A single report of a sync failure is a ticket. The same user reporting it for the third time across two releases is a retention problem, and that is invisible when every submission is a fresh row.
The reply is the part users can see
Almost all of the value of an app feedback form is created after the message arrives, and almost none of it is created by the form. A user who reports a fault and hears nothing concludes that the channel is decorative, and the next time they have something to say they will say it in the store instead. A user who reports a fault and gets a short, specific answer within a day frequently comes back and says so publicly.
That is the whole business case for owners, statuses and a reply that stays attached to the message. It is not tidiness. It is that unanswered feedback converts into public reviews, and answered feedback converts into the opposite.
What to change first
Attach the version, build, operating system, device and current screen to every submission so that the shortest possible message is still reproducible, and tell the user in one line that it is being attached. Then cut the form to four fields and give every message an owner, a status and a reply that stays with it, with Halict or any tool built the same way.
Q1. What should an app feedback form ask for?
Four fields: a three way choice between broken, idea and other, one free text box, an optional screenshot, and an optional contact address. Everything else the support team needs, such as the app version, build, operating system, device and current screen, should be attached automatically rather than typed by somebody who is already annoyed.
Q2. Where should the feedback link go inside an app?
A permanent entry in settings, plus contextual prompts after specific failures such as a declined payment or a failed upload. The settings entry is where people look once they have decided to complain, and the contextual prompt is what catches an accurate description while the failure is still on screen.
Q3. Is it allowed to ask for a rating inside an app?
Apple's App Store Review Guidelines state that the provided API must be used to prompt for a review and that custom review prompts are disallowed, so an imitation of the store dialogue is a review risk. A private feedback form is a separate thing and is not affected, which is an argument for keeping the two visibly distinct rather than blending them into one screen.
Q4. Should in-app feedback be anonymous?
An optional contact field is almost always better. Feedback typed on a phone is short, and most short messages are one clarifying question away from being actionable, which is impossible without an address. State in one line that the address will be used only to reply.
Q5. How should duplicate reports be handled?
Tag them as they arrive rather than sorting them at the end of a quarter, and count the tags. Eight separate reports of the same fault, worded differently, look like noise in a list and are the clearest priority signal in the set. Keying responses to the same person by email address also separates eight users with one problem from one user reporting it eight times, which are different problems.