In-app feature voting for iOS: five options compared

Feature voting is the difference between collecting feedback and ranking it. A form gives you a pile of requests. A board with votes gives you a list sorted by how many people want each thing, which is the list you actually build from. This post compares the five ways to get voting into an iOS app, from the free options Apple gives you to a native SDK, and is honest about which ones are voting at all.

Full disclosure: WishKit, our product, is option five. The comparison below is fair to the other four because each of them is the right answer for someone.

Option 1: TestFlight feedback

Testers on a TestFlight build can send you feedback and screenshots straight from the app, and it lands in App Store Connect. It costs nothing and takes zero setup.

• Voting: none. Each piece of feedback is a private message to you.
• Who can use it: beta testers only. Your App Store users never see it.
• Pick it if: you are pre-launch and want bug reports from a small group.
• Skip it if: you want production users to shape the roadmap. It is a beta tool and stops mattering the day you ship.

Option 2: a form or an email button

A "Send feedback" row in Settings that opens a mail composer or a survey form. Every app can add this in an afternoon, and many should, because it is the lowest-friction way to let someone report a problem.

• Voting: none. You will count duplicates by hand in an inbox, which is the job a board exists to remove. Our guide to mining App Store reviews describes that spreadsheet, and it applies to inboxes too.
• Closing the loop: manual. Nobody who asked for a feature finds out it shipped unless you email them.
• Pick it if: you get a handful of messages a month and mainly want bug reports.
• Skip it if: requests have started repeating. Repetition is the signal that you need votes.

Option 3: a web feedback board inside a web view

Tools like Canny and Featurebase are web products, and the usual way to get them into an iOS app is to load the board in a web view or hand the user off to Safari. You get real voting, statuses, and a mature admin dashboard.

• Voting: yes, and everything around it: comments, statuses, roadmap, changelog.
• The feel: a web page inside your app. Different fonts, its own loading state, no pull to refresh that matches yours, and a login wall or cookie prompt if the board requires identity. Users notice, and some treat it as leaving the app.
• Identity: your app knows who the user is; the web view does not, unless you wire up single sign-on, which is usually a paid tier.
• Cost: Canny is free to 25 tracked users and $79 a month from there; Featurebase is free for one seat and $29 per seat after. See Canny pricing and Featurebase pricing.
• Pick it if: you already run one of these for a web product and want the same board in the app.
• Skip it if: the app is the product. A web view in a native app is the one place polish is visibly missing.

Option 4: build your own

A table of requests, a vote count, a SwiftUI list, and CloudKit or a small backend behind it. Every iOS developer has sketched this on a napkin, and the napkin version takes a weekend.

• Voting: yes, exactly the way you want it, and fully native.
• What the napkin leaves out: one vote per user without forcing sign-in, duplicate merging, moderation and spam control, statuses and notifying voters when something ships, an admin screen you will use for years, and comments. Each is a small feature; together they are the product.
• Ongoing work: yours forever. Feature voting is never your app's core, so it is always the last thing that gets maintained.
• Pick it if: you have unusual requirements, such as an offline-first app or a compliance reason to keep every byte in your own infrastructure.
• Skip it if: the honest reason is "it seems easy". It is easy to start.

Option 5: a native SDK

WishKit is a SwiftUI SDK: add the package, call configure with your project key, and present a view. The board renders as native UI on iOS, macOS, visionOS, watchOS and tvOS, and you manage requests in a web dashboard. It is option four without the backend, plus option three's admin tooling, in native clothing.

• Voting: yes, with comments, statuses, duplicate merging, and voter notifications when a status changes.
• The feel: native. System fonts, your accent color, real navigation. Users do not know it is a third-party component.
• Identity: users vote without signing in, and if your app knows their email or what they pay, you pass it along with one call and can sort requests by revenue in the dashboard.
• Cost: free for one project with unlimited users. Premium is a flat $15 a month for two projects, comments, and notifications.
• Setup: about ten minutes. The step-by-step is in how to add a feedback board to a SwiftUI app.
• Skip it if: you need a roadmap and changelog module bundled in, or Jira and Salesforce integrations. Those are what option three is for.

How to choose

Pre-launch: TestFlight feedback plus an email button. Free, instant, and enough while your users are a group chat.

Launched, requests starting to repeat: this is the moment for votes. A native SDK gets you there in an afternoon without a web view; a web board in a web view gets you there if you already pay for one.

App and web product with one shared board: either a web tool in a web view, or a native SDK that also has a web embed. WishKit's board can be embedded on a website with two lines of HTML, so the app and the site share one list.

Special constraints: build your own, with clear eyes about the maintenance.

Whatever you pick, put the entry point where users look for it, label it "Feedback" or "Feature Requests", and reply to the first few requests within a day. The tool matters less than users seeing that someone is on the other end. The workflow around that is in how to collect and prioritize iOS feature requests.

Frequently asked questions

Does Apple provide feature voting?

No. TestFlight lets beta testers send feedback and App Store reviews let users rate the app, but neither has voting, and neither reaches your production users as a shared list of requests.

Can I use Canny or Featurebase in an iOS app?

Yes, through a web view or a link to Safari. Neither offers a native iOS SDK, so the board looks and behaves like a web page inside the app. See WishKit vs Canny and WishKit vs Featurebase for the native angle in detail.

Do users need an account to vote?

With a native SDK, no. WishKit keeps a user's votes consistent without sign-in, and you can attach an email or ID later if your app has one. Web boards usually need a login or SSO to prevent duplicate votes.

Is feature voting worth it for a small app?

Once requests start repeating, yes. Votes turn the same ten emails into one line with a number next to it, and that number is what tells you what to build next.