Feature requests for iOS apps: let users vote on what you build next

Why App Store reviews are the wrong place for feature requests

App Store reviews were designed to rate an app, not to run a product conversation. A review is a star rating with a paragraph attached. There is no upvote, so a great idea posted once looks the same as an idea posted by forty people. You can reply, but only once per review, and the user gets no notification when you ship the thing they asked for. Reviews are also public and permanent, so a frustrated request written on a bad day drags your rating down forever.

The result is that most iOS developers keep a spreadsheet of requests copied from reviews and support tickets. That works for a month. After that, nobody knows whether "widgets" was asked for by two people or two hundred, and the users who asked never hear back. A dedicated board solves both problems: votes give you the count, and statuses give users the feedback loop.

Cost is the other reason developers avoid the tools built for this. Canny starts at $79 a month on its Pro plan and prices by tracked user. Featurebase's Basic plan is $59 a month. UserVoice is enterprise-only, with quotes from around $16,000 a year. For a solo iOS developer paying out of pocket, that is more than the app earns. pick a feature is free for one project and 10 requests, then $5 a month for unlimited requests, which is the price point this page assumes throughout.

Three ways to add a feature request board to an iOS app

There is no single right answer, so here is the honest breakdown.

1. Native Swift package. WishKit is an open source SwiftUI package with a hosted backend. The UI is fully native, which is the best-feeling option. The trade-offs: it is iOS only, so your Android or web users get nothing, and you are tied to one project's roadmap and pricing changes.
2. Hosted board in SFSafariViewController. Your project gets a public page at a pickafeature.com URL. You open it from a settings row using Apple's own in-app browser. No package to update, works on iOS 9 and up, and the same board serves Android, Flutter, and your website. This is what the rest of this page walks through.
3. WKWebView with the web widget. If you want the board inside your own view hierarchy instead of a Safari sheet, load a page that embeds the pick a feature web widget in inline mode. More control, slightly more code, and you own the container styling.

If you ship only on iOS and never plan to add another platform, a native package is a fine choice. If you have, or expect to have, an Android build, a Flutter build, or a web app, one shared board is worth more than native chrome. Votes from every platform add up in one place, and you see which platform each request came from.

Open the board from Swift or SwiftUI

Create a project in the dashboard and copy its board link from the Projects page. It looks like https://pickafeature.com/b/your-app. Then present it with SFSafariViewController. This is the UIKit version:

import SafariServices

func openFeatureRequests() {
    let url = URL(string: "https://pickafeature.com/b/your-app")!
    let safari = SFSafariViewController(url: url)
    safari.preferredControlTintColor = .systemIndigo
    present(safari, animated: true)
}

SwiftUI has no built-in wrapper, so add a five-line representable and present it as a sheet:

import SwiftUI
import SafariServices

struct SafariView: UIViewControllerRepresentable {
    let url: URL
    func makeUIViewController(context: Context) -> SFSafariViewController {
        SFSafariViewController(url: url)
    }
    func updateUIViewController(_ vc: SFSafariViewController, context: Context) {}
}

struct SettingsView: View {
    @State private var showBoard = false

    var body: some View {
        List {
            Button("Feature requests") { showBoard = true }
        }
        .sheet(isPresented: $showBoard) {
            SafariView(url: URL(string: "https://pickafeature.com/b/your-app")!)
        }
    }
}

That is the whole integration. The board follows the system light or dark appearance, remembers the user's votes in Safari's storage, and shows only the requests you have moved to planned, in progress, or completed. New submissions stay private until you review them in the dashboard.

Prefer the board embedded in your own screen? Load a small HTML page in a WKWebView that includes the web widget in inline mode. The web widget docs cover the container option; the snippet is one script tag with a data-container attribute.

What your users see, and what you see

Users get a list with two tabs, planned and completed. Each request shows its title, description, vote count, and comments. Tapping the arrow upvotes; tapping again removes the vote. A "Suggest a feature" button opens a short form with title, description, and an optional email so you can follow up. Everything is one vote per person, enforced per browser storage, so a user cannot stuff the count by tapping repeatedly.

On your side, requests land in a kanban board in the dashboard with pending, under review, planned, in progress, and completed columns. Drag a card to change its status. Drag one card onto another to merge duplicates: you preview both, pick or combine the title and description, and choose whether votes and comments carry over. The analytics page breaks users and requests down by platform, so if you also ship on Android you can see whether "iCloud sync" is an iOS ask or an everyone ask.

Email notifications tell you when a new request, vote, or comment arrives, so you do not need to keep the dashboard open.

One board for iOS, Android, Flutter, and web

Most apps do not stay iOS-only. The moment you add an Android build or a web version, per-platform feedback tools split your users' voices in two. The hosted board approach sidesteps that. The same URL works from Android's Chrome Custom Tabs, from React Native, and from a plain link in your website footer. If your app is written in Flutter, the Flutter SDK renders the board natively and talks to the same project.

Because every integration writes to one project, the vote count on "dark mode" is the real total, not the iOS total. That matters when you are deciding what to build with a one-person team.

How pick a feature fits an indie iOS developer

pick a feature was built for developers who pay for their own tools. The free plan is not a trial: one project and 10 feature requests, for as long as you want. Starter is $5 a month for three projects and unlimited requests. Unlimited is $15 a month for as many projects as you ship. There are no per-seat or per-tracked-user fees, so a viral week does not turn into a surprise invoice.

For iOS specifically you get the hosted board described above, the merge tool for cleaning up duplicate asks, per-platform analytics, and a public board link you can also post on social when you ask "what should we build next?". If you later want a native SwiftUI package, that is on the roadmap and prioritised by demand; email us and say so.

Frequently asked questions