How to collect user feedback for your iOS app
A practical guide for indie iOS developers: the channels that actually work, what to avoid, and how to turn user feedback into shipped features.
Your App Store reviews are a graveyard. Five-star praise tells you nothing about what to build next, and one-star rants rarely point at a fixable root cause. To ship the features users actually want, you need a dedicated feedback channel — one that captures specifics, lets the community vote, and closes the loop when something ships.
This guide covers the channels indie iOS developers can realistically operate solo, the trade-offs between them, and a concrete setup you can copy.
Why App Store reviews aren't enough
App Store reviews are public, anonymous, and read by future customers — that's a feature for marketing, but it's the wrong substrate for feedback. Users dump unrelated bugs and feature requests in a single review. You can't reply with structured questions. You can't sort or prioritize. And once you ship a fix, the reviewer rarely comes back to update the rating.
Reviews are a lagging indicator. Treat them as a quality signal, not a backlog.
The channels that actually work for indie iOS apps
Most indie devs end up with a mix of the following. None of them alone is sufficient, but two or three together cover the gap that the App Store leaves.
- Public feedback boards (Verbr, Canny, Featurebase): visible roadmap, votes, status updates — best for prioritization
- In-app feedback button: lowest friction, captures emotion in the moment, but easily becomes a black hole if you don't reply
- TestFlight feedback (built into iOS 13+): great for beta testers, useless for shipped apps
- Discord / Slack community: high signal but high time cost, only viable if you already have a community
- 1:1 user interviews: irreplaceable for big product decisions, not scalable
A concrete setup that works
Here is the stack most indie iOS developers we talk to converge on:
- A public feedback board at a stable URL — share it from the app's Settings screen and in release notes
- An in-app 'Send feedback' button that opens the board (or a simple mailto: as fallback) — make it findable
- Email follow-up on status changes — when you mark something as 'planned' or 'done', notify the people who voted
- GitHub Issues sync — feedback that gets prioritized flows automatically into your dev workflow
How to encourage actual replies, not just complaints
Feedback volume tends to spike during outages and dry up otherwise. To get steady, useful input:
- Allow anonymous submissions. Forcing a signup before someone can complain kills the signal.
- Show a public status (open / planned / in_progress / done). Users post more when they see previous feedback being addressed.
- Notify by email on status change — even anonymous users with optional email registration. The single highest-leverage retention move.
- Reply in public, even with a short 'thanks, tracked.' Silence is worse than a no.
Closing the loop: shipping and announcing
Feedback you ignore is worse than feedback you never collected — users learn that posting is pointless. When you ship something requested by the board:
- Update the status to 'done' on the original feedback item, not just internally
- Publish a changelog entry pointing back to the feedback (and ideally to the App Store update note)
- If the requester registered an email, they get notified automatically — that re-engagement converts to App Store reviews more often than you'd expect
How Verbr fits
Verbr is built around exactly this loop. Each project gets a public feedback page at verbr.net/<your-slug>, anonymous submissions are allowed, voting and email-on-status-change are first-class, and GitHub Issues sync is built in. The free plan covers a single iOS app with up to 500 feedback items, which is more than most apps will see in their first year.
FAQ
Should I require users to sign up before submitting feedback?
No. Anonymous submission is the single biggest factor in feedback volume. Make signup optional but offer email notification on status changes — most users will opt in just to hear back.
How do I avoid the feedback board becoming a wishlist that overwhelms me?
Use status workflow. Default to 'open', mark a small set as 'planned' each quarter, and close the rest as 'open — under consideration' rather than promising anything. Users self-rank via votes.
Should I also reply to App Store reviews?
Yes — but as a separate motion. Reply briefly to one-star reviews pointing them at your feedback board. That redirects the rant into something actionable and signals to other readers that you're listening.
Where do I link to the feedback board from inside the app?
The two places that work: (1) a 'Feedback' row in your Settings screen, near 'About', and (2) the release notes shown after an update. Both are read by users who actually care.