How to Choose an In-App Feature Request Tool for Your iOS App
Last updated
Sooner or later every iOS app gets the same email: "Love the app, but could you add…?" One request is easy to remember. Two hundred, spread across App Store reviews, support emails and DMs, are not. A feature request tool gives those ideas one home, lets users vote instead of repeating themselves, and shows you what matters most.
There are many options, from big web platforms to small SDK-led tools. This guide does not pick a winner. It gives you the questions to ask, so you can choose the one that fits your app. We make FeedbackKit, and we say where it fits at the end, but the questions apply to any tool.
1. Does it feel native, or is it a web page in a box?
Many feedback tools reach iOS by loading their web portal in a WKWebView. That can work, but it rarely feels like the rest of your app: different fonts, scrolling, dark mode and Dynamic Type behaviour. Canny's mobile widget docs and Featurebase's installation overview are two public examples of that WebView approach.
Ask: is there a Swift package with SwiftUI views? Can you theme it? Does it respect the user's system settings? Open the vendor's sample app on a real device before you decide.
2. Can you use your own UI if you want to?
Ready-made screens get you live fast. At some point you may want the board to match a custom design. Look for an SDK with a data layer (list, vote, submit, comment) you can call from your own views, as well as the drop-in screens.
3. How does it install?
For iOS, Swift Package Manager is the expected route. If you also ship on Android or with a cross-platform framework, check that the same tool has SDKs for those platforms too, so your users land on the same board.
4. How do users identify themselves?
Anonymous voting is low friction but easy to game. Signed-in identity ties votes to real customers. Look at how the tool lets you pass a user ID from your app, and whether it needs a server-side signature. Neither is wrong; choose what matches how your app handles accounts.
5. What happens after a user posts?
This is the question most buyers skip, and it is the one users notice. When a request is approved, in progress or completed, does the person who asked hear about it? Is there a public roadmap they can check? A board that never answers back trains users to stop posting.
6. Where will you manage it?
If you are an indie developer, you will probably triage on your phone between other jobs. Check whether the tool has a native admin app or a mobile-friendly dashboard, and whether you can merge duplicates, reply and change status from there.
7. Does it connect to where you plan work?
If your backlog lives in Linear, GitHub, Notion, Trello or ClickUp, a sync saves copy-pasting. Check which integrations exist and which plan they are on.
8. Does it respect privacy and App Review?
Your app's privacy label covers third-party SDKs too. Ask what data the SDK collects, whether it ships a privacy manifest, and where data is stored. If the board shows other users' posts, think about moderation as well: App Review Guideline 1.2 expects a way to report or hide objectionable user content.
A quick checklist
| Question | What good looks like |
|---|---|
| Native feel | SwiftUI views that follow system settings |
| Custom UI | A data layer you can call directly |
| Install | Swift Package Manager, plus SDKs for your other platforms |
| Identity | User IDs from your app, optional verification |
| Closing the loop | Status emails to the people who asked, and a reply they can read on the request |
| Triage | Native admin app or a good mobile dashboard |
| Integrations | Your actual issue tracker |
| Privacy | Privacy manifest, clear data collection, and a plan for objectionable posts |
Where FeedbackKit fits
The Swift SDK installs through Swift Package Manager and includes ready-made SwiftUI screens, and it ships a privacy manifest. It requires iOS, macOS and visionOS 26, so it is not an option if you still support older iOS versions. Kotlin, React Native and Flutter ship ready-made screens too. The JavaScript SDK is a headless client and ships no screens. Docs: Swift, Kotlin, React Native, Flutter, JavaScript.
Status email goes out for the statuses on that project's list. A new project starts with a default list — approved, in progress, completed and rejected — and choosing a different list needs Pro. The person who submitted the request receives the email, on any plan, when they gave an address. A voter receives it when they opted in and the project is on Team. On Free or Pro the vote still counts, and the voter opt-in is not stored. A reply from your team stays on the request, where the person who asked can read it in the app.
You triage from native apps for iPhone, iPad and Mac. Integrations with Linear, GitHub, ClickUp, Notion, Slack, Monday.com, Trello, Airtable, Asana and Basecamp require Pro, as do HubSpot, Salesforce and the email-list tools (Mailchimp, Kit, beehiiv and MailerLite). Team includes what Pro includes. Free is 1 project, Pro is 2, and Team is unlimited projects and team members.
If the board shows other people's posts, App Review's user-generated-content rule is still yours to satisfy. Check which reporting and blocking tools the SDK version you ship includes before you submit.
Whatever you choose, try it inside a real build for a week. The right tool is the one your users actually open.