Feature requests for React Native apps, without a native module

The React Native feedback problem

React Native teams ship to iOS and Android from one codebase, and that is exactly what makes feedback messy. App Store reviews and Google Play reviews are separate systems. Your support inbox mixes both. When five iPhone users and thirty Android users ask for the same feature, you only find out if someone counts by hand.

Native SDKs are the second problem. Canny, Featurebase, and most feedback tools have no React Native package at all; their advice is a WebView. Tools that do ship native modules break Expo's managed workflow and add another dependency to every upgrade. For a small team on a tight React Native upgrade cycle, each native module is a future afternoon lost.

A hosted board avoids both. It is a URL, so Expo Go, EAS builds, and bare projects all open it the same way, and both platforms write to one project. The dashboard records which platform each request and voter came from, so the iOS and Android split is a chart rather than a spreadsheet.

Expo: open the board with expo-web-browser

Install the package and call it from a settings row. On iOS it presents SFSafariViewController; on Android it uses Chrome Custom Tabs. Both keep the user inside your app and share browser storage, which is how votes persist between visits.

npx expo install expo-web-browser

import * as WebBrowser from "expo-web-browser";
import { Pressable, Text } from "react-native";

const BOARD_URL = "https://pickafeature.com/b/your-app";

export function FeatureRequestsRow() {
  const open = () =>
    WebBrowser.openBrowserAsync(BOARD_URL, {
      presentationStyle: WebBrowser.WebBrowserPresentationStyle.PAGE_SHEET,
      toolbarColor: "#6366f1",
      enableBarCollapsing: true,
    });

  return (
    <Pressable onPress={open} accessibilityRole="button">
      <Text>Feature requests</Text>
    </Pressable>
  );
}

Replace the board URL with the one from your dashboard's Projects page. There is nothing else to configure, and nothing to update when the board gains features, because the board is served by us.

Bare React Native: in-app browser or Linking

Without Expo, react-native-inappbrowser-reborn gives you the same Safari sheet and Custom Tabs behaviour:

import { InAppBrowser } from "react-native-inappbrowser-reborn";
import { Linking } from "react-native";

const BOARD_URL = "https://pickafeature.com/b/your-app";

export async function openFeatureRequests() {
  if (await InAppBrowser.isAvailable()) {
    await InAppBrowser.open(BOARD_URL, {
      modalPresentationStyle: "pageSheet",
      toolbarColor: "#6366f1",
      showTitle: true,
    });
  } else {
    await Linking.openURL(BOARD_URL);
  }
}

If you would rather avoid any native dependency, Linking.openURL alone opens the board in the system browser. It leaves your app, which is a worse experience, but it is a zero-dependency fallback that works everywhere.

Embedding the board in a screen with react-native-webview

To make the board a tab or a full screen in your navigator, render a page that embeds the pick a feature web widget in inline mode inside react-native-webview. You can also pass the signed-in user's id so votes follow their account across devices:

import { WebView } from "react-native-webview";

const html = (apiKey: string, userId?: string) => `
<!doctype html><meta name="viewport" content="width=device-width, initial-scale=1">
<div id="board"></div>
<script src="https://pickafeature.com/sdk/v1/pickafeature.js"></script>
<script>
  PickAFeature.init({
    apiKey: "${apiKey}",
    container: "#board",
    theme: "auto",
    user: ${userId ? `{ id: "${userId}" }` : "undefined"}
  });
</script>`;

export function BoardScreen({ userId }: { userId?: string }) {
  return (
    <WebView
      originWhitelist={["*"]}
      source={{ html: html("YOUR_PROJECT_KEY", userId), baseUrl: "https://pickafeature.com" }}
      javaScriptEnabled
      domStorageEnabled
    />
  );
}

Keep domStorageEnabled on; the widget stores the device id and vote state in localStorage. The project key is public by design (it ships inside every mobile binary) and is rate-limited per project on the server. Full option list in the web widget docs.

Triage, merge, and see iOS versus Android

Every submission lands as pending in the dashboard and stays hidden from users until you approve it. That single step removes spam and support tickets from the public board. From there you drag cards across a kanban: under review, planned, in progress, completed. Users see the new status the next time they open the board.

Duplicates are the daily chore of any feedback board, and React Native apps get them twice, once per platform. Drag one card onto another and the merge dialog shows both, lets you keep or combine the title and description, and moves votes and comments across with each voter counted once. The analytics page then charts users and requests by iOS, Android, and web, which is the number you actually want before deciding whether to build a platform-specific feature.

How pick a feature fits a React Native team

pick a feature is a small, flat-priced feedback board for developers who pay for their own tools. 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 or per-tracked-user pricing, so growth on either platform never changes the bill.

For React Native you get the hosted board for Expo and bare projects, the web widget for WebView screens, one dashboard with merge and per-platform analytics, and email notifications when requests arrive. A React Native package is on the roadmap and prioritised by demand; if you want it, say so, and it goes on our own board.

Frequently asked questions