TL;DR

• React Native apps share one codebase across iOS and Android, which means feedback issues can surface on either platform. Your survey setup needs to handle both.
• The React Native SDK lets you collect in-app feedback directly inside your app without waiting for App Store or Play Store reviews.
• Installation takes three npm commands. Setup requires initializing the SDK, optionally passing user attributes, and configuring survey triggers.
• The SDK works on React Native 0.60+. Expo Go has limitations. Standard Expo with development builds works fine.
• Trigger feedback after key actions (onboarding complete, post-purchase, feature activation) rather than on a timer to get responses worth reading.
• If feedback isn't showing, check SDK token initialization order and netinfo peer dependency setup first. These account for most failed installs.

Most React Native developers think about feedback the same way. Ship the app. Wait for reviews. Read them eventually. Build what the loudest users ask for.

It works. Until it doesn't.

App Store reviews take days to appear. They skew toward frustrated users, because the happy majority doesn't bother rating anything. By the time you've read enough reviews to spot a real pattern, you've already shipped two more versions.

In-app feedback closes that gap. Not by polling every user constantly, but by asking the right person the right question at the right moment: right after onboarding, right after a feature they used for the first time, right when something went wrong. That's what gives you signal you can build from, not noise you have to sort through.

This guide covers integrating Zonka Feedback's React Native SDK: what you need before you start, the full implementation steps, when to trigger feedback for maximum response rates, and how to debug the issues that trip up most integrations.

Why In-App Feedback Beats Waiting for App Store Reviews

App Store and Play Store reviews tell you what went wrong after a user decided to leave. In-app feedback tells you what's going wrong while they're still there to fix it.

Here's the actual difference in practice:

Timing. A review submitted three days after a bad experience is a complaint. A survey triggered five seconds after a failed checkout attempt is a diagnosis.

Who responds. App Store reviews attract users at emotional extremes, the furious or the delighted. In-app feedback reaches your middle segment: the quiet majority who'll churn without ever saying why.

What you can ask. App Store reviews are free-form. In-app feedback lets you target by user segment, session count, feature usage, or any custom attribute you define. Ask new users about onboarding. Ask power users about what's missing. Ask churning users why they're leaving.

What you can do with the response. A bad App Store review requires a public response. A bad in-app feedback response can route to your support team automatically, trigger a follow-up from customer success, or flag the session for a product review, all before the user ever thinks to leave a review.

For a fuller look at in-app feedback approaches and strategy, the in-app surveys guide covers the broader picture. This post is about implementation.

React Native SDK vs. iOS, Android, and Flutter SDKs

Zonka Feedback offers four mobile SDKs. If you're reading this, you've presumably already chosen React Native, but it's worth being clear about when the React Native SDK is the right call and when it isn't.

Use the React Native SDK when your app is built on React Native (JavaScript + React) and you want a single SDK integration that works on both iOS and Android from the same codebase. One integration, two platforms.

Use the native iOS SDK when you have a Swift or Objective-C app, or when you need the tightest possible performance and deepest native UI customization. See the iOS SDK guide.

Use the native Android SDK when your app is Kotlin or Java, or you're targeting Android only. See the Android SDK guide.

Use the Flutter SDK when your app is built in Dart with Flutter. React Native's JavaScript bridge is irrelevant to a Flutter app. You need the Flutter-native package. See the Flutter SDK guide.

For a broader look at how feedback SDKs compare across mobile platforms, mobile app surveys covers the category.

One note on Expo: the React Native SDK works with Expo managed workflow using development builds (expo-dev-client). It does not work with Expo Go, which restricts native modules. If you're on Expo Go and not yet using development builds, that's the first thing to sort.

Before You Start

Three things you need before touching the code:

• An active Zonka Feedback account – If you don't have one, sign up here.
• A survey created in Zonka Feedback – Build this first. Customize the questions for your use case before generating an SDK token.
• Your SDK token – Navigate to Distribute > In-App, enable the toggle, and copy the token. You'll need it in Step 2.

Minimum requirements:

• React Native version 0.60 or above
• Minimum version for dependencies:
  • react-native-community/netinfo: v6.0.2 or higher
  • react-native-device-info: v9.0.2 or higher

How to Integrate the Zonka Feedback React Native SDK

Step 1: Install the Dependencies

Run these three commands in your project terminal:

npm install react-native-zonkafeedback
npm install react-native-device-info
npm install @react-native-community/netinfo

react-native-device-info captures device context (OS version, device type) automatically. @react-native-community/netinfo handles network state detection, which React Native doesn't expose natively. This is the dependency most developers forget, and it's the most common cause of SDK initialization failure.

For iOS, run pod install in your /ios directory after the npm installs.

Step 2: Initialize the SDK

Generate your SDK token from the Distribute menu, then wrap the relevant section of your app in the ZonkaFeedback Provider:

import {ZonkaFeedback} from "react-native-zonkafeedback";
const AppWithZonkaFeedback = () => {
  return (
    <ZonkaFeedback value=>
      <YourApp />
    </ZonkaFeedback>
  );
};

For region, use "US" for United States and "EU" for Europe. The region determines where survey data is stored. Get this right before going to production, not after.

Step 3: Identify Logged-In Users

If your app has authentication, pass user details to Zonka Feedback so responses link to specific users instead of being anonymous. This makes your feedback data significantly more useful. You can filter responses by user segment, subscription tier, or any attribute you track.

import {useZFSurvey} from "react-native-zonkafeedback";
const HomeScreen = () => {
  const {userInfo} = useZFSurvey();
  const hash = {contact_email:"james@examplemail.com",
  contact_name:"James Robinson",
  contact_mobile:"+91019019010"
  }
  userInfo(hash)
}

Anonymous feedback tells you that something is broken. Identified feedback tells you who it's broken for: which plan they're on, how long they've been a user, what they've done in the app. That context changes what you do with the response.

Step 4: Optional Parameters

Capture Device Details

The sendDeviceDetails parameter captures OS version, IP address, and device type alongside each feedback response. It's enabled by default. Set it to false if you need to restrict data collection for compliance reasons.

import {useZFSurvey} from "react-native-zonkafeedback";
const HomeScreen = () => {
  const { sendDeviceDetails} = useZFSurvey();
  sendDeviceDetails(true).startSurvey();
}

Device data is worth collecting for React Native apps specifically. Cross-platform bugs often show up on specific OS versions or device types. Knowing that 80% of your low feedback scores come from Android 12 users is a different problem than knowing your aggregate score dropped.

Pass Custom Attributes

Custom attributes let you pass additional context, including screen name, order ID, subscription plan, or experiment variant, to segment feedback later.

import {useZFSurvey} from "react-native-zonkafeedback";
const HomeScreen = () => {
  const { sendCustomAttributes} = useZFSurvey();
  const hash = {
    plan_type:"pro",
    screen_name:"checkout",
    order_id:"ORD-8821"
  }
  sendCustomAttributes(hash).startSurvey();
}

Use these to trigger targeted feedback. A user on a free plan who's viewed the upgrade screen three times without converting is a different feedback candidate than a new pro subscriber in their first week.

Step 5: Reset Visitor Attributes on Logout

If users log in and out of your app, clear visitor data on logout to prevent responses from mixing across accounts:

import {useZFSurvey} from "react-native-zonkafeedback";
const HomeScreen = () => {
  const {clear} = useZFSurvey();
  clear()
}

Skip this and you'll eventually see feedback responses attributed to the wrong user. Harder to catch than you'd expect.

When to Trigger In-App Feedback

Installation is the easy part. The real work is deciding when feedback appears, and getting this wrong is what makes users dismiss it.

A few principles first: feedback triggered immediately on app open gets ignored. Feedback triggered after a meaningful action gets answered. The goal is to catch users at a moment when they've just done something and have a clear opinion about it.

Here's when it works:

1. After Onboarding Completion

Ask new users how the setup experience felt while it's still fresh. You'll find out where people got stuck before they give up and leave.

Example: After a user finishes onboarding, ask: "How was your experience getting started?"

2. After a Key Feature Is Used for the First Time

The first time a user successfully completes an export, runs a report, or activates a feature, that's when to ask. Not before. They don't have an opinion yet.

3. After Repeated Sessions

A user logging in for the tenth time has seen enough of the app to give you real product feedback. Session-gated triggers work well here.

Example: If a user logs in for the 10th time, ask: "What do you love most about our app?"

4. After a Friction Event

If a user attempts the same action multiple times without success, failed uploads, repeated form submissions, repeated navigation to the same dead end, that's the trigger. Ask what's going wrong while the frustration is specific.

Example: If a user repeatedly tries to upload a profile picture but fails, ask: "Are you facing any issues with the upload feature?"

5. After an App Update Ships

Your React Native setup means you can push updates via CodePush or similar without App Store review cycles. When you do, trigger a short in-app survey for users who've been on the app more than 30 days. Find out if the update landed.

Example: After launching a dark mode feature, ask: "Do you like the new dark mode?"

6. At Exit Intent

When a user browses upgrade options or pricing but doesn't convert, a short feedback prompt before they close the app gives you data you can't get any other way.

Example: If a user browses subscription plans but doesn't upgrade, ask: "What's stopping you from upgrading?"

7. After a Support Interaction

If your app has in-app support or a help center, trigger a CSAT survey after the ticket closes. Not before. Users who haven't resolved their issue yet have a different sentiment than users who have.

For NPS surveys specifically: trigger them at relationship moments, not transactional ones. After onboarding is complete and the user has experienced real value, not after a single session, not right after a bug.

Common Issues and Fixes

Most React Native SDK integrations that don't work on the first try have the same handful of causes.

Feedback Not Showing After Initialization

Check two things in this order. First: is the SDK token correct and matched to the right region ("US" or "EU")? A token from the EU region won't work if the SDK is initialized with "US". Second: is @react-native-community/netinfo installed and linked correctly? The SDK uses it to check connectivity before triggering. If netinfo isn't found, the SDK fails silently.

iOS: Feedback Not Rendering After Pod Install

Run pod install again after upgrading the SDK package. Stale pod caches cause this more than anything. If that doesn't fix it, check that the ZonkaFeedback Provider is wrapping the correct component tree. Wrapping only a subset of your navigation stack means feedback won't show on screens outside it.

Android: Build Failure After Install

Check your Gradle version. react-native-device-info v9+ requires Gradle 7+. If you're on an older React Native version with an older Gradle setup, you'll see a build failure. Either upgrade Gradle or pin react-native-device-info to a compatible version.

Expo Go: SDK Not Working

The React Native SDK uses native modules that Expo Go doesn't support. Switch to a development build with expo-dev-client. This is a one-time setup change and works cleanly from there.

TypeScript: Type Errors on Import

The package ships with TypeScript definitions. If you're seeing type errors, check that your tsconfig.json includes node_modules/react-native-zonkafeedback in the type resolution path.

Conclusion

At this point you have a working React Native SDK integration: dependencies installed, the SDK initialized with your token and region, user attributes configured, custom attributes set up for targeting, and visitor data clearing on logout. You also know when to trigger feedback, after meaningful actions, not on a timer, and how to debug the five failure modes that catch most integrations off guard.

The React Native SDK handles both iOS and Android from a single codebase, which is the main reason to choose it over the native SDKs. If your stack ever changes, a Flutter rewrite, a native iOS companion app, the iOS, Android, and Flutter SDK guides follow the same structure and can be picked up quickly.