Review Management for Flutter and React Native Teams

You maintain one Flutter or React Native codebase, but the App Store and Google Play hand you back two separate review streams, in two separate consoles, in two different reply formats — and the in-app-review plugin you wired up only asks for the review. It never answers the one that comes back. That gap is the whole problem with cross-platform review management: shipping to both stores is a single `flutter build` away, but staying on top of what users write is two logins, two notification systems, and two sets of rules you have to keep straight.

This is a guide for teams who write once and deploy to both stores. What the Flutter and React Native review plugins actually do (and the part they leave for you), how App Store and Google Play replies genuinely differ once you're answering by hand, and how to collapse both streams into one inbox so a review never rots in the console you forgot to open this week.

Because "cross-platform" stops at the build step. Your UI, your business logic, your state management — all shared. But a review is not part of your app; it lives on the store, and the two stores are run by companies that agree on almost nothing about how reviews work.

A one-star lands in App Store Connect with an email ping if notifications are on. The same review lands in Google Play Console under a different tab, with a different star-weighting scheme (Google recency-weights the average since I/O 2019, so a bad week hurts more and a good month heals faster). Reply limits differ. Notification timing differs. So the team that treats "we shipped to both stores" as one job inherits a second, invisible one: two review desks, each easy to neglect because neither is the console you happen to have open.

They trigger the native rating dialog — the little "Enjoying the app? Rate us" sheet — and nothing more. In Flutter that's the `in_app_review` package; in React Native it's `expo-store-review` or `react-native-store-review`. Both are thin wrappers over Apple's `SKStoreReviewController` and Google Play's In-App Review API. The Flutter call looks like this:

Three things to know before you lean on these. First, the OS decides whether the dialog even appears — Apple caps how often it can show (historically around three times per user per 365 days) and Google enforces its own quota, so calling `requestReview()` is a request, not a guarantee. Second, you cannot read, style, or intercept the result: by design you can't show the prompt only to happy users and route unhappy ones to a support form. That's review gating, and both stores' guidelines forbid it — the native APIs give you no lever to pre-screen by sentiment before the prompt fires. Third, and most important here: the plugin's entire job ends the instant the user taps a star. It generates a review. It does absolutely nothing about the review.

So timing matters — ask after a genuine win, never mid-task — and [in-app review prompt best practices](/blog/in-app-review-prompt-best-practices) goes deep on that. But even a perfectly-timed prompt just fills your two consoles faster. The plugin is the intake. Everything downstream — reading, answering, translating, before it curdles — is still on you.

Once you actually start replying, the two stores diverge in ways that bite you if you assume they behave alike. The differences are small individually and annoying in aggregate:

The character limits, edit behavior, and rating math are broken down side by side in [App Store vs Google Play review replies](/blog/app-store-vs-google-play-review-replies). The point for a cross-platform team is that you're maintaining two reply habits for one product, and that friction is enough that most small teams quietly stop replying on whichever store is quieter.

That reply is under 350 characters, so it posts cleanly to Google Play. Answering the same reviewer with a wall of text you drafted for the App Store gets truncated or rejected — one of a dozen small mismatches a unified workflow just erases for you.

The fix for a two-console problem is to stop looking at two consoles. Pull every Apple App Store and Google Play review for your Flutter or RN app into a single inbox, and the whole split-brain tax disappears: one place to watch, one place to answer, one draft that already knows which store's character limit it's headed for.

This is the job [ReplyArgus](/features) is built for. It watches both stores for the same app, drafts an on-brand reply the moment a review lands — grounded in your own past approved replies and your store listing, so it stays specific instead of inventing a fix that never shipped — and translates in both directions across 100+ languages. Nothing goes public on its own unless you opt in: it's approve-by-default, with rule-based auto-publish you can scope to the safe cases (say, a clean five-star in a language you support) by rating, keyword, language, or store.

This gets sharper the smaller you are. A solo founder shipping a Flutter app to both stores is also the entire support, marketing, and reputation team, and "reply to every review in two consoles in two languages" is exactly the chore that slides when a release week gets busy. The stakes are real: Google's I/O 2019 data showed apps that respond to reviews average +0.7 stars, and academic work (Hassan et al., across 4.5M reviews) found a user is roughly six times more likely to raise their rating after a developer replies. That lift is free — but only if the reply happens.

The honest version of this workflow for a team of one is laid out in [reply to app reviews as a solo dev](/blog/reply-to-app-reviews-solo-dev). The short version: automate the reading, drafting, and translating so the only thing left is a judgment call and a click, and the second store stops being the one you neglect.

You already did the hard part — one codebase, two stores, live. Don't let the reviews be the thing that splits back into two jobs. [Start free with ReplyArgus](/signup) (no card): connect App Store Connect and Google Play once, and every review for your Flutter or React Native app lands in a single inbox with a grounded, correctly-sized reply already drafted in the reviewer's language. You just decide what's good enough to send.