How to Add In-App Feature Voting to an iOS App: Your Options

Feature voting turns a pile of emails into a ranked list. Instead of ten people writing "please add offline maps", one person posts it and nine tap a vote. On iOS there are five realistic ways to get there, and they differ less in what users see than in how much work lands on you afterwards: moderation, identity, triage and telling people when their idea ships.

We make FeedbackKit, so read this with that in mind. Facts about other tools come from each provider's own website and docs, and facts about Apple's frameworks from Apple's developer documentation, checked on 17 October 2026 and linked where used.

The short version

• Build it yourself if feedback is core to your product and you have time to maintain moderation and an admin tool.
• Use a native SDK if you want SwiftUI screens and a dashboard without writing a backend.
• Load a web board in a web view if your team already runs a web feedback portal and the app is one of several entry points.
• A form and a spreadsheet, or TestFlight feedback, are fine for collecting ideas, but neither gives users a way to vote.

Picking a specific tool? Our buying checklist covers the questions to ask, and the roundup of in-app feedback tools for iOS lists the candidates.

Option 1: build it yourself

A voting board is a small data model: requests, votes and comments, plus a status on each request. The hard parts are around it.

On CloudKit

CloudKit's public database is a natural home for a board that every user can see. Apple's documentation for the public database says its contents are readable by all users of the app, that users have write access to the records they create, and that its data counts toward your app's iCloud storage quota. That shapes the design: one user cannot change another user's record, so a vote is best stored as its own record that points at the request, and you total the votes yourself.

import CloudKit

func vote(for request: CKRecord) async throws {
    let vote = CKRecord(recordType: "Vote")
    vote["request"] = CKRecord.Reference(record: request, action: .deleteSelf)
    _ = try await CKContainer.default().publicCloudDatabase.save(vote)
}

CloudKit gives you storage and sync with no server to run. It does not give you an admin dashboard, duplicate merging, status emails or a view for Android users.

On your own backend

If you already have accounts and a server, a few tables and endpoints get you a board tied to real user IDs, on every platform you ship. You also get to join votes to your own data, such as which plan each voter is on. The cost is everything after launch: an admin screen to triage and merge duplicates, and a way to tell people when their request moves.

Moderation is part of the job

A public board is user-generated content. App Review Guideline 1.2 asks apps with user-generated content for a way to filter objectionable material, a way to report offensive content with timely responses, the ability to block abusive users, and published contact details. Budget for those whichever option you pick, and especially when you build your own.

Option 2: a native SDK

A Swift package with ready-made SwiftUI screens gets you a board in an afternoon, and the vendor hosts the backend and the dashboard. Four to look at:

• FeedbackKit: SwiftUI screens for iOS, macOS and visionOS 26 or later, plus SDKs with screens for Android, Flutter and React Native. Revenue per request, six statuses and native admin apps. No in-app chat, and no hosted public roadmap or changelog for your users. Free $0, Pro $15/month or $150/year, Team $39/month or $390/year (pricing, Swift docs).
• WishKit: a native SwiftUI SDK for iOS, macOS, visionOS, watchOS and tvOS, according to its pricing page, with an MIT-licensed iOS package for iOS 16 and later. Free $0 with five visible requests; Premium $15/month or $150/year. See the comparison.
• Features.Vote: SwiftUI views with no WebView, for iOS 16 and macOS 13 or later, says its SDK page. Lite $9/month or $90/year and a 14-day trial; its pricing page lists no free plan. See the comparison.
• Votice: an MIT-licensed SwiftUI SDK for iOS, iPadOS and tvOS 17 and macOS 14 or later, with a management app. Free for 1 app; Pro €4.99/month or €49.99/year; Lifetime €99.99, sold as App Store in-app purchases (product page). See the comparison.

The trade-off is dependence on a vendor and the vendor's minimum iOS version. Check that it matches your deployment target before anything else.

Option 3: a web board in a web view

If you already run a web feedback portal, you can show it inside the app. iOS gives you two ways.

WKWebView

A WKWebView lets your app load the board and pass the signed-in user through, so votes are tied to your accounts. Canny's mobile widget works this way: you load a URL with a board token and a single sign-on token that your server generates, and Canny says the mobile widget needs SSO. Featurebase suggests a WebView with auto sign-in, and Sleekplan's docs offer an iframe or mobile webview.

SFSafariViewController

Apple's SFSafariViewController documentation says interactions with the web interface aren't visible to your app, and that your app can't access AutoFill data, browsing history or website data. It also points you to WKWebView when you need to customise the controls or interact with the content. So it is the simplest way to open a hosted board, such as a Nolt or FeedBear board, but your app cannot sign the user in for them. FeedBear's pricing FAQ suggests exactly this: link to the board in a webview or the browser.

Either way, the board looks like a web page inside a native app, with its own fonts and scrolling. In return you get the web platform's portal, roadmap and changelog, which native SDKs mostly lack. See FeedbackKit vs Canny and FeedbackKit vs Featurebase.

Option 4: a form and a spreadsheet

A "Suggest a feature" button that opens a web form, writing rows to a spreadsheet, costs nothing and takes ten minutes. It is a good way to find out whether your users send ideas at all. It does not let them see or vote on each other's ideas, so you count duplicates by hand, and nobody hears back unless you email them yourself.

Option 5: TestFlight feedback

If you run a beta, TestFlight already collects feedback. Apple's TestFlight page says testers can take a screenshot from your app, mark it up and share feedback, and can add context when a crash report is sent, and that you can invite up to 10,000 external testers. It is excellent for bugs and rough edges in a build. It reaches testers, not your App Store users, and it has no votes, so it complements a board rather than replacing one.

Trade-offs at a glance

How FeedbackKit fits in

FeedbackKit is option 2. You add the Swift package, show the ready-made SwiftUI board, and identify users with your own IDs. A new request starts with its submitter's vote, voting stops on Completed and Rejected, and you can merge duplicates so each voter is counted once. When a request moves to a status on your project's list, the person who asked gets an email (see closing the loop with status emails). What users see once the board is in your app is covered in feature voting for iOS apps. Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

Choose another route if…

• Build it yourself if voting is part of your product's core experience, or you need data FeedbackKit doesn't hold.
• Use a web board in a web view if you need a hosted public roadmap or a changelog for your users, or plan work in Jira.
• Pick WishKit, Features.Vote or Votice if your app supports iOS versions before 26, which FeedbackKit's Swift SDK does not.
• Stay with TestFlight if you are pre-launch and your testers are the people you want to hear from.

If a native board fits, you can add one on the Free plan with one project. Start free.