Get Your iOS Feature Requests Into One List
Ask an indie iOS developer where their feature requests live and the honest answer is "everywhere". A few are in the support inbox, some in App Store reviews, more in TestFlight feedback, a handful in replies on social media and the rest in your head. Each one is easy to remember on its own. Together they are impossible to rank. This post is a routine for getting them into one list, cleaning that list up and moving the best items into the tool where you plan work.
The short version
- Pick one list as the home for every feature request, and make it one your users can see and vote on.
- Each week, sweep the other channels and move requests into that list.
- Merge duplicates so each idea has one count.
- Rank by votes, then by the revenue behind those votes.
- Send the requests you commit to into your issue tracker, and keep the status in step.
Step 1: choose the home
The home can be a spreadsheet, a board in your tracker, or a feedback board inside your app. What matters is that there is one, and that you never let a second one grow next to it.
We think the home should face your users. A private spreadsheet counts what you happened to write down. A board inside the app lets people add their own requests and vote on everyone else's, so the counts grow without you typing them in. If you have not set one up yet, How to gather user feedback inside an iOS app covers where to put it.
Step 2: sweep the other channels
Requests will keep arriving through other doors. Set a weekly slot, thirty minutes is usually enough, and go through each one.
Email and support
When a support thread is really a feature request, answer the person, then send them a link to the board, or tell them where to find it in the app. If they will not post it themselves, add it yourself and mention the source in the description ("asked for by three users by email in May").
App Store reviews
Read new reviews for phrases like "wish it had", "please add" and "would be five stars if". Reply to the review to say the idea is on your board, and add it there if it is new. Our post on replying to App Store reviews has wording that works.
TestFlight
Most TestFlight feedback is about bugs in the current build, and it belongs in your tracker. The few true feature requests go to the board, where your App Store users can vote on them too.
Social media and community
Replies, DMs and forum threads are the hardest to keep. Save the link, add the request to the board, and reply with where it now lives. People are happy to vote when you make it one tap away.
Step 3: merge duplicates
"Offline maps", "Download trails for no signal" and "Use the app in the mountains" are the same request. Left separate, each looks small. Merged, they are the top item on the list. Merge whenever two items would be solved by the same piece of work, and keep the clearest title.
A good merge keeps everything: the votes from both items (each person counted once), the comments, and a note of where each part came from. Without that, people who voted on the duplicate lose their place.
Step 4: rank what is left
Votes tell you how many people want something. They do not tell you who those people are. Ten votes from paying subscribers can matter more than fifty from people trying the free version. Sort by votes, then look at the revenue behind each request before you decide. If you want a fuller method, RICE prioritisation treats votes as reach and revenue as impact, and our overview of prioritisation frameworks compares the common ones.
Step 5: hand it to your tracker
Once you commit to a request, it becomes work, and work lives in your issue tracker. Create the issue from the request rather than retyping it, so the two stay linked. Then keep the status in step in both places, so the board tells users what the tracker tells your team.
How FeedbackKit fits in
FeedbackKit is a feedback board inside your app. The Swift SDK gives you the SwiftUI screens (Swift docs), and the same board is available from Android, Flutter and React Native. Users vote and comment inside your app, and a new request starts with its submitter's vote.
FeedbackKit does not import email, reviews or social posts. Those still come in through the weekly sweep above. For requests you add yourself, the REST API accepts new feedback with your project's API key, or you can post from a build of your own app.
Here is how triage looks in FeedbackKit, with sample data from a fictional hiking app:
From Pending to TestFlight
Merging and ranking
In the native admin apps for iPhone, iPad and Mac, you can merge duplicate requests into one. Votes move across with each voter counted once, and comments move across with a note of the request they came from. Requests can be sorted by votes, and on every plan by the total MRR of the users behind them. Your app passes each user's MRR through the SDK:
SwiftlyFeedback.updateUser(payment: .monthly(4.99))
SwiftlyFeedback.updateUser(payment: .yearly(39.99))Statuses
Every request carries one of six statuses: Pending, Approved, In Progress, TestFlight, Completed and Rejected. Users see them in the app. Voting stops on Completed and Rejected.
Trackers and Slack
On Pro and up, you can create an issue from a request, one at a time or in bulk, in GitHub, Linear, Notion, ClickUp, Monday.com, Trello, Airtable, Asana or Basecamp. The link stays on the request. Status sync keeps the FeedbackKit status in step with GitHub, Linear, Notion, ClickUp, Monday.com, Airtable, Asana and Basecamp. Trello creates cards and syncs comments. Vote counts sync to Notion, ClickUp, Monday.com, Airtable and Asana. GitHub and Airtable have no comment sync. There is no Jira, Azure DevOps, Zapier or Make integration. Slack posts new requests and status changes to a channel on Pro and up. The full list is on the integrations page.
The Free plan has one project and ten visible feedback items per project, with no integrations. Plan details are on the pricing page.
One list, swept weekly, merged and ranked, beats five half-lists every time. Start free and give your requests a single home.