VoteFirst is a feedback board, and its Swift package puts that same board natively inside an iPhone or iPad app, drawn with SwiftUI rather than loaded in a hidden web page. It ships for iOS and macOS only. There is no Android SDK, and nothing on this page should be read to suggest otherwise. A project costs nine dollars a month on Lite, with a fourteen day trial and a card asked at signup, same as everywhere else VoteFirst runs.
Does the board live in the app, or in a webview
It lives in the app. VoteFirstUI ships SwiftUI views for the board, the public roadmap, the changelog, one opened request and the suggestion form, plus a UIViewController wrapper for UIKit. Each one draws with the system's own list, search field and navigation bar rather than rendering a page, which is what makes it hold a native scroll position, respect Dynamic Type, and look like the rest of the app rather than like a browser tab pasted into one. The colours come from the project's own board, so a themed app does not end up with a mismatched white panel in the middle of it.
A team that would rather draw its own list can skip the shipped screens entirely and call the same routes directly, one call per route, and nothing hidden behind the ones the screens use.
Who can vote, and how a signed in user's identity reaches the board
Nothing has to be set up first. The package mints an anonymous voter on a device the first time it needs one, keeps it in the keychain, and that voter can vote, comment and suggest without ever creating an account.
If people are already signed in to the app, that identity can carry over, so their vote is theirs on every device rather than tied to one phone. The app's own server signs a token naming its own user id, with an expiry, and the package sends it to a sign in route. The signing secret stays on the server and never ships inside the app, because a client that could name any user could vote as any one of them. Two things have to be true on the VoteFirst side for that token to be accepted: the project is on a Pro plan, and an SSO secret has been generated for it on the project's Share page. On Lite, a signed token is refused and the device falls back to the anonymous voter it already had.
Which plan the SDK needs, and what it costs
The embed key a project already has for its public board is the only key the package needs, and it opens the same routes a browser visiting that public board can already reach, nothing more. That works on Lite, nine dollars a month, one project. Signing in an app's own users with their real identity needs Pro, thirty nine dollars a month, because the SSO secret that makes a signed token acceptable is a Pro feature on the Share page. The in app message banner, the one line a project owner can put on a screen the app already has for an outage or a fix in review, needs Pro as well, for the same reason the dashboard page that writes those messages is gated to it. Both plans carry the same fourteen day trial with a card asked at signup.
Minimum iOS and macOS versions
iOS 15 and macOS 12 or later. Installed with Swift Package Manager, no other dependencies. There are three products to depend on: VoteFirst, which re-exports the other two and is the one most apps want; VoteFirstUI, the screens; and VoteFirstKit, the client with no SwiftUI in it, for a server side Swift process or a command line tool that only needs to make calls.
How the in app board and the public web board share one list
They are the same board. A vote cast inside the app and a vote cast on the public web page both land on the same project, through the same API, and both show up in the other place on the next refresh. The columns, the stages and the vote counts are one list, not two that get reconciled later.
The voter behind each one is not automatically the same person. An anonymous voter in the app and a visitor to the public web board are two different, separately minted identities unless that person signs in on both with the same account. The package has no way to read a browser cookie, and the two never merge on their own.
How a user hears that a request they voted for shipped
Publishing a release sends one email, to every signed in voter whose own vote is attached to something in that release, and to nobody else. An anonymous voter, which is what the app mints by default, has no email address on file, so that person gets no release email no matter how they voted. The only way an iOS user is on that list is if the app signed them in with their own email on the token, or if they separately have a VoteFirst account with an email on it. Inside the app itself, the changelog screen shows every release whether or not anyone was emailed about it.
What an iOS team weighs against this
A web board loaded in a webview. The fastest thing to ship, because it is one web view pointed at a URL and no App Store review surface changes. It also reads like a browser tab sitting inside the app, loses native text selection and Dynamic Type, and needs a network round trip on every open rather than the native screens' own retry and offline queue.
An email link to the public board. No app code at all, but it asks someone to leave the app they are already in, open their inbox, and come back, which is a few more steps than most people take in the moment they had a complaint or an idea.
App Store reviews. Already where frustrated users write, and already read by the team, but there is no way to sort by how many other people want the same thing, no way to tell one clear request from six worded differently, and a public reply from the developer is the only response available. Of 168,034 of the newest App Store reviews on 4,875 top chart apps, read on 3 October 2026, at least 1.4 percent asked for something new, most of them inside four and five star reviews.
A survey or bug report SDK. Built for a different kind of feedback: a score at a moment the team picks, or a screenshot of something broken, seen by the team alone. Twenty two in app feedback tools, with their SDKs and prices, were read on 3 October 2026.
TestFlight feedback. Reaches only the beta list, not the shipped audience who is actually living with the app, and a build's feedback typically does not carry forward once a newer build replaces it.
What VoteFirst does not do
No Android SDK. The native option is Swift, for iOS and macOS only. No SAML or OIDC, JWT only, for the signed in voter token described above. No Slack, Zapier or outgoing webhooks. No AI features anywhere, on this plan or any other.
Does a vote cast anonymously in the app still count toward the public board
Yes. The vote is recorded against the device's anonymous voter and counted on the board exactly like any other vote, visible on the web page the same project already has.
Can a project try this before paying
Yes, the fourteen day trial that covers every plan covers this. A card is asked for at signup on either plan, and the SSO secret that an app's own sign in needs is available to generate as soon as the project is on Pro, trial included.
What this costs
Lite
$9 /mo
Pro
$39 /mo
Lifetime
$999 once
Fourteen day trial of Pro, card asked for at signup. Nothing here counts the people who vote, so the bill does not move when the board starts working. The long version, with what happens if you stop paying.
Other use cases
Feature voting software, for the fuller picture once there is more than one plan to weigh. Feedback widgets, for a team that wants the board on a web page instead of inside an app. The feature request API, for an app that would rather draw its own screens against the same routes. Feedback board for indie hackers, for a one person team running the whole product alone.