Ten mobile app feedback examples, and where each one lands

The interesting thing about the mobile app feedback examples below isn't what people write. It's where it arrives, because three of the most common destinations are places the person who could fix the thing never looks.

The ten below are written for this post, not copied from any app's reviews. Each is paired with where that kind of message usually ends up and what actually happens to it there.

Where does app feedback actually go?

Six destinations, and they sort cleanly into the ones that reach a person and the ones that reach a number.

A store review reaches a number. A one star rating with no words changes an average and tells nobody anything. A support message reaches a person, and is by far the most useful thing an app receives, and is also the one that gets answered and then deleted.

There's a board that collects the third kind, open without an account.

The ten, and where each one lands

The first pattern worth naming is that rows one, two, seven and nine all land in the store, where there's no conversation, no device information, and a reply reaches only the one person who wrote that review.

The store is a rating system that people use as a feedback channel because it's the only channel the app offered them.

The second is row ten. The people happy with your app write nothing, and the loudest part of any feedback channel is the part currently unhappy with a change.

What do the newest store reviews actually say?

The ten above were written for this post. The figures here were measured. On 3 October 2026, the 50 newest reviews were read from the public review feed of every app on the US iPhone store's top free and top paid charts, up to 100 of each in each of 25 categories. That came to 4,875 apps, 4,319 of them with at least one review, and 168,034 reviews in all.

The ratings split rather than average. 31.7 percent of the newest reviews give one star and 46.4 percent give five. Two, three and four stars together hold 21.9 percent, so an average of these reviews describes almost nobody who wrote one.

A review is short, but it names its version. The median review runs 23 words, about two sentences, which is rarely enough to reproduce a fault. All but 13 of the 168,034 carry the app version they were written on, and 32.5 percent were written on the version the store was serving that day. On the 2,965 apps with a full 50, the newest 50 reach back a median of 74 days.

Requests arrive on good ratings. A request for something new turns up in 1.8 percent of four and five star reviews and 0.5 percent of one and two star ones, which is row two of the table above: the five stars count toward the average and the request goes nowhere. On 38.4 percent of the apps with a full 50, at least one of the newest 50 asks for something new.

Taking something away reads differently from leaving it out. Reviews asking for a feature back, or saying they used to be able to do something, average 2.3 stars. Reviews asking for something new average 3.9.

A review counts under a row when its title or text contains one of a fixed list of phrases, such as "please add", "would be nice if" or "can you add" for a request. A request worded any other way is not counted, which is why that row says at least. One review can count under several rows. No app is named and no review is quoted.

What is worth acting on, and what is not?

Three tests, applied in order.

Does it contain a situation? Row six says what somebody was trying to do and what happened. Row two says what somebody wants. The first can be investigated. The second can only be agreed or disagreed with.

Did more than one person say it? A single message is an anecdote. A single message you've heard four times is a pattern, and the only way to know which one you're holding is to count.

Can you tell them when it changes? If the channel can't carry a reply, acting on the feedback produces no visible result to the person who gave it, and they won't give you another.

Row one passes the third test only in part. When a developer responds to a store review, the reviewer is told and can change the review. The response reaches that one reviewer, and nobody else who hit the same crash and wrote nothing.

Three channels that never reach the person who could act

Store reviews. The app version, but no device and no thread. The signal arrives as a star average, and an average of a thousand ratings moves too slowly to tell you anything about last Tuesday's release.

Social media mentions. Fast, public, and answered by whoever runs the account rather than by anybody who can change the app. The useful content of these is almost always a repeat of something already in support.

The one star with no words. It records anger without a cause. There's nothing in it to act on, and reading a pile of them teaches a team that users are irrational rather than that the app has a specific problem.

Four messages in full, and the verdict each earns

The table above shows what people write in a line. Here is what four of those same situations look like in full, written for this page, because the verdict changes once you read past the first sentence.

A bug report, in app, on the board.

On the board for the Riverside project. Added a comment from a phone on the train, no signal. It said posted, then it wasn't there after checking from a laptop at home.

Actionable. Names the project, the device, the exact moment it failed, and hands you a repro path: post a comment with no connection, then reopen from a second device.

A store review, nine words.

Used to love this, now it's slow and ugly.

Nothing to act on. No screen, no version, no example of slow or ugly. File it under sentiment, not under a ticket.

A feature request, with its own reasoning attached.

Add a way to mute one project's notifications without muting all of them. On four boards and only one of them matters this month.

Actionable and ready to rank. The why sits next to the want, so whoever reads it in six months still knows what problem it solves.

A support reply that never left the inbox. A customer asked why a renewal charged twice. Support explained it was a proration adjustment, and the thread closed. Nobody connected that explanation to the three other people who asked the same question that month. The reply itself was fine. What failed is that it never became a pattern anyone could see.

Why does it matter when a message was written?

Because feedback written in the moment and feedback written afterwards are different evidence, and they read identically once they are in a list.

A message typed while somebody is standing in the thing that went wrong carries the detail: which screen, what they were holding, what they expected instead. A message typed a week later carries the feeling that survived, which is usually stronger and much less specific.

Both are worth having and they answer different questions. In the moment feedback tells you what broke. Afterwards feedback tells you what mattered enough to still be annoying on Thursday.

The practical consequence is about where you put the collecting surface. A control inside the app, on the screen where the thing is missing, collects the first kind. A store review, an email reply or a public board collects the second, because all three require the person to have stopped using the app and gone somewhere else.

Most mobile products only collect the second kind and then wonder why the reports are hard to reproduce. If you only change one thing after reading this page, put a way to say something on the screen rather than in a settings menu three taps away.

How do you collect this without another tool?

One in app link, one address, one weekly hour.

The link goes where people are annoyed rather than in a settings menu nobody opens. The address can be a shared inbox. The weekly hour is spent writing one line per message into a sheet, holding the situation, the person, the date, and whether you've told them anything.

Two things this can't do, and they're the same two every manual system hits. It can't count the same want once when forty people phrase it differently, and it can't tell forty people at once that the thing shipped.

How a request board changes the mobile picture

It gives rows five, six and eight somewhere to land where they're counted and answered.

The board is public and works in a mobile browser, so a link from inside the app reaches it with no account and no install. An iPhone or iPad app can go further and put the board on a native screen of its own, through VoteFirst's Swift package. What somebody writes there stays visible, other people add to it rather than writing it again, and the request carries the list of who asked.

Twenty two in app feedback tools cover the surveys and bug reports a board does not, with what the two app stores let an app ask for a rating.

That list is what makes the third test above pass. When a request ships in a release, the people on it who signed in with an email address are told, and nobody keeps a record by hand.

The timeline is the part that matters when support is filing on behalf of people who wrote in, not posted, which is how rows three and four get onto the board at all.

Two limits worth being plain about. A board doesn't collect row ten, because nobody happy writes anything anywhere. And the counts on boards are smaller than people expect.

On 634 public Canny and Featurebase boards read on 3 October 2026, only 12.3 percent of requests reached ten votes, and the median held two. The votes on all 634 boards are in one open file. How the board is wired is written up here, and the same question for websites has its own page.

14 days, a card at signup, then $9 or $39 a month.

What do app feedback examples look like on the screen?

Four screens from one iPhone app talking to one board, shot on 15 September 2026.

Everything above is what people write and where it goes. This is what it looks like when the app carries the board itself, so the writing and the answering happen in the same place.

The app is the sample that ships with VoteFirst's Swift package. Five files, the package resolved by URL the way anybody else installs it, pointed at a board with real requests, real votes and real comments on it.

Four requests fit on the first screen. Voting system at 78 votes, Public roadmap at 65, Comment threads at 55 and Onboarding wizard at 52, with a fifth starting underneath. The top row carries 15 comments and 258 views.

A reply from the team sits on the fourth card, in the list, before anyone has tapped anything. That's the whole point of putting the board in the app: the person arrives to find other people wanted the same thing, and somebody answered.

Two fields. What should we build, and why does it matter to you. The second is the one most forms leave out and the one that makes a request rankable later.

Under both is a line saying an owner reads every suggestion before it appears. Somebody who presses send and can't find their request assumes it vanished, so saying it's held first, on the form, is the difference between a queue and a black hole.

Voting system, opened. Completed, 78 votes, 15 comments, 258 views, and a line saying this stage doesn't take votes, because a finished thing can't be asked for again.

Underneath are the three details a person actually wants: the release it went out in, what kind of change it was, and the month somebody first asked for it.

Six releases, newest first, each one dated in plain words. Three days ago, one week, two weeks, a month.

This is the half most apps skip. Somebody who voted in March opens the app in September and finds out it shipped, in the same place they asked, with no email and no release notes page on a site they never visit.

What VoteFirst connects to, including the Swift package these screens came from, is written out on the integrations page.