Feature requests for Android apps: collect ideas and votes inside your app

Why Google Play reviews don't work as a feature request system

Play Console lets you reply to reviews, and that is where its feature-request support ends. There is no voting, so you cannot tell whether "add a widget" is one person's wish or a hundred. Reviews are tied to a star rating, so users who want to ask for something often knock a star off to get attention, which hurts your listing. And a reply is a one-time message: when you finally ship the widget six weeks later, the reviewer never finds out.

Android also has a fragmentation problem that iOS mostly avoids. The same request can mean different things on a Pixel and a Samsung tablet, and you want to be able to ask the person who posted it. A board with comments lets you do that without publishing the exchange to your store page.

The tools built for this were priced for SaaS companies, not app developers. Canny's Pro plan is $79 a month and scales with tracked users. Featurebase charges $59 a month on Basic. Frill starts at $25 a month and caps you at 50 ideas. pick a feature is free for one project and 10 requests and then $5 a month, flat, which is the assumption behind the setup below.

Your options for an Android feature request board

1. Chrome Custom Tabs to a hosted board. Your project gets a public page at a pickafeature.com URL. A Custom Tab opens it inside your app with your toolbar color, shares Chrome's cookies so votes persist, and falls back gracefully on devices without Chrome. No SDK to maintain. This is the recommended route and the one detailed below.
2. WebView with the web widget. Embed the pick a feature web widget in inline mode inside a WebView when you want the board to live inside your own layout, for example as a tab. More styling control, and you can pass the signed-in user's id so votes follow their account.
3. Flutter SDK. If the app is written in Flutter, use the native Flutter package instead. It renders the board with Material widgets and reports the platform as Android automatically.
4. Build it yourself. A Room table, a Compose list, and a Firebase backend gets you a board in a week. It also gets you moderation, spam, duplicate cleanup, and notifications to build next. The build versus buy breakdown puts the ongoing cost at 80 to 120 developer hours.

Open the board with Chrome Custom Tabs

Add the AndroidX browser dependency if it is not already there:

dependencies {
    implementation("androidx.browser:browser:1.8.0")
}

Then launch the board from wherever you keep support links. Copy your board URL from the Projects page of the dashboard; it looks like https://pickafeature.com/b/your-app.

import android.content.Context
import android.net.Uri
import androidx.browser.customtabs.CustomTabColorSchemeParams
import androidx.browser.customtabs.CustomTabsIntent

fun openFeatureRequests(context: Context) {
    val colors = CustomTabColorSchemeParams.Builder()
        .setToolbarColor(0xFF6366F1.toInt())
        .build()
    CustomTabsIntent.Builder()
        .setDefaultColorSchemeParams(colors)
        .setShowTitle(true)
        .build()
        .launchUrl(context, Uri.parse("https://pickafeature.com/b/your-app"))
}

In Jetpack Compose, wire it to a settings row:

@Composable
fun SettingsScreen() {
    val context = LocalContext.current
    ListItem(
        headlineContent = { Text("Feature requests") },
        supportingContent = { Text("Vote on what we build next") },
        modifier = Modifier.clickable { openFeatureRequests(context) }
    )
}

Custom Tabs use the device's default browser when Chrome is absent, and Android falls back to a normal browser intent on the rare device with neither. Either way the board loads. The page follows the system dark theme and stores the user's votes in browser storage, so one person gets one vote per request.

Embedding the board in a WebView instead

Some apps want the board as a first-class screen rather than a browser sheet. For that, host a small HTML page (or serve it from assets) that loads the web widget in inline mode, and show it in a WebView with JavaScript enabled:

<div id="board"></div>
<script
  src="https://pickafeature.com/sdk/v1/pickafeature.js"
  data-api-key="YOUR_PROJECT_KEY"
  data-container="#board"
  defer
></script>

The project key is a public key, the same kind that ships inside any mobile binary, and the server rate-limits it per project. If your app has accounts, call PickAFeature.identify from the page with the user's id so their votes survive a reinstall. The web widget documentation lists every option.

What happens after a user posts a request

New requests arrive as pending in your dashboard and are invisible to users until you approve them, which keeps spam and support questions off the public board. You get an email for each new request, vote, and comment. Move cards across a kanban board (pending, under review, planned, in progress, completed) and users see the status change on their next visit.

When two people ask for the same thing in different words, drag one card onto the other. The merge dialog shows both, lets you keep or combine the titles and descriptions, and carries over votes with each voter counted once. The analytics page then shows requests and users split by Android, iOS, and web, so you know whether a request is an Android pain point or a product-wide one.

How pick a feature fits an Android developer

pick a feature is priced so a developer with one app on Google Play can afford it: free for one project and 10 feature requests, $5 a month for three projects with unlimited requests, $15 a month for unlimited projects. No per-seat and no per-tracked-user fees, so a Play Store feature does not become a billing event.

You get the hosted board for Custom Tabs, the web widget for WebViews, a Flutter SDK if you go cross-platform, and one dashboard with merge and per-platform analytics across all of them. A native Kotlin library is on the roadmap; tell us if you need it and we will weigh it against the other requests, which is exactly the process the product is built for.

Frequently asked questions