Mobile — App Store Optimization

React Native App Store Review Rejection Fixes

Direct answer

Most React Native App Store rejections trace to a short list: release-build crashes the team never saw in dev, vague or missing permission purpose strings, no working demo account for the reviewer, over-the-air updates described in a way that sounds like remote code injection, and apps that feel like thin webview wrappers. The fixes are procedural — test the exact binary you submit, write purpose strings that name the feature, seed a demo login, and keep OTA updates within your app's declared purpose.

React Native apps get rejected for predictable, fixable reasons — and the rejection notices rarely tell you the underlying cause. After shepherding many RN builds through App Review, these are the failure modes I check first and how I resolve each one.

Key facts, with sources

App store search drives 65% of app discovery on iOS and 58% on Google Play, making it the single largest acquisition channel ahead of browse, referrals, and ads. (Business of Apps)
In 2025 the average US conversion rate was 8.56% on the App Store and 16.15% on Google Play, with category extremes ranging from about 5% for trivia games to over 50% for food and drink apps. (AppTweak)
A one-star rating increase can lift conversion 10 to 15%, and moving from three to four stars can boost conversions by up to 89%. (AppFollow)
Apple Ads placements at the top of App Store search results deliver an average conversion rate above 60% across available countries, measured November 2024 to October 2025. (Digital Applied (ASO statistics compilation))
Apps compete against roughly 1.96 million titles on the Apple App Store and over 1.5 million on Google Play, with tens of thousands of new apps published every month. (BuildFire)

Guideline 2.1 crashes: test the binary you actually submitted

The most common RN rejection is a crash on launch that never reproduces in development. Release builds differ from dev builds in ways that bite: Hermes bytecode behaves differently from Metro's dev bundle, environment variables baked at build time can be empty in the release configuration, and an API base URL pointing at a local or staging server will hang forever on the reviewer's network.

My rule is that nothing goes to review that hasn't been installed from TestFlight and cold-launched on a physical device with airplane-mode and slow-network runs. Check that your error boundaries render something useful instead of a white screen, because a hung splash screen is indistinguishable from a crash to a reviewer, and their report will just say the app did not load.

Permission purpose strings that name the feature

Apple rejects purpose strings that are vague, generic, or missing — and RN dependencies silently add permission usage that you never declared. A library for image picking can pull in camera and photo library access; if the corresponding usage descriptions are absent, the build fails or gets rejected. The fix is to write purpose strings that state the specific in-app feature, not a legal boilerplate sentence.

In Expo projects I declare these in app.json so they survive prebuild and are reviewed like code. State what the user gets, in their language via localized strings if you ship multiple locales.

app.json — specific iOS purpose strings

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSCameraUsageDescription": "Scan receipts with the camera to attach them to expense reports.",
        "NSPhotoLibraryUsageDescription": "Choose an existing photo of a receipt to attach to a report.",
        "NSLocationWhenInUseUsageDescription": "Tag site visits with your current location while you are checked in."
      }
    }
  }
}

Demo accounts and review notes reviewers can actually use

If your app sits behind a login — and most B2B and SaaS-companion RN apps do — the reviewer needs a working account, and rejections for this are entirely self-inflicted. SSO-only apps are the classic trap: the reviewer cannot sign up through your customer's identity provider. Ship a reviewer-accessible credential path, seed the demo account with realistic data so the app doesn't look empty, and verify the login works on the production backend the day you submit.

Use the review notes field aggressively. Explain anything non-obvious: hardware the app pairs with, geofenced features, flows that require a second user. I treat review notes as documentation for a first-time user with fifteen minutes and no patience, because that is roughly what a reviewer is.

OTA updates and the remote-code question

Teams get nervous that expo-updates or similar OTA tooling violates Apple's rules about downloading executable code. Interpreted JavaScript run by the system-provided or bundled framework is permitted, provided updates do not change the app's core purpose or unlock features that were hidden from review. The danger is not the mechanism; it is how you use it.

What actually triggers rejections is behavior that looks like deception: shipping a benign app and flipping a flag post-approval to reveal different functionality, or describing your updater in review notes as a way to ship features without review. Keep OTA payloads to fixes and iterations of the reviewed experience, ship anything that changes native modules or entitlements as a store build, and this issue stays theoretical.

Minimum functionality and metadata rejections

Guideline 4.2 rejections hit RN apps that are effectively a website in a shell. If most screens are webviews of your responsive site, App Review may ask why this needs to be an app. The cure is native capability that a browser cannot match: push notifications tied to real events, offline access to core data, camera or biometric integration, home-screen widgets. I add at least two of these before first submission for any content-heavy app.

Metadata rejections are cheaper but just as blocking: screenshots showing Android status bars in an iOS listing, mentions of other platforms in the description, placeholder text left in fields, or age-rating answers that contradict app content. Do a final pass on the listing with the same rigor as the binary — the reviewer evaluates both.

When to hire senior help

Bring in ASO help once the product has retention worth scaling and organic installs have plateaued, since optimization multiplies traffic you already earn rather than creating demand. Specialists matter most in competitive categories, where keyword targeting and conversion testing against entrenched incumbents is a data discipline generalist marketers rarely run well. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships Mobile — App Store Optimization projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

✕Stuffing keywords into the app title despite Apple's 30-character limit and policy, while leaving the separate iOS keyword field empty or full of duplicates
✕Never running screenshot or icon experiments with Google Play store listing experiments or Apple Product Page Optimization, even though the first screenshot dominates conversion
✕Ignoring ratings mechanics: no in-app review prompt at moments of user success and no replies to negative reviews, letting the average drift below the critical 4.0 threshold
✕Treating ASO as a one-time launch checklist instead of iterating on keyword rankings and conversion data, and skipping listing localization for non-English markets

Frequently asked questions

Why does my React Native app crash in App Store review but not in development?

Release builds differ from dev builds: Hermes bytecode instead of the Metro dev bundle, build-time environment variables that may be empty, and production API endpoints. A staging URL unreachable from the reviewer's network is a common culprit. Always install the exact TestFlight build on a physical device and cold-launch it, including with poor connectivity, before submitting.

Are Expo OTA updates allowed by Apple's App Store rules?

Yes — interpreted JavaScript updates are permitted as long as they do not change the app's core purpose or unlock functionality that was concealed from review. Use OTA for bug fixes and iterations of the reviewed experience. Anything touching native modules, entitlements, or the app's fundamental behavior should ship as a normal store build through review.

How fast can I resubmit after an App Store rejection?

You can reply in Resolution Center or resubmit immediately, and re-reviews are often faster than first reviews — typically within a day or two, though it varies. If you believe the rejection is a misunderstanding, a clear Resolution Center reply with steps to reproduce the intended behavior sometimes clears it without a new binary. Repeated identical rejections deserve a fix, not an argument.

Does ASO actually matter or should we just buy ads?

Search drives 65% of discovery on iOS and 58% on Google Play, so the organic listing is the largest single acquisition channel and every paid click also lands on it. With average conversion at 8.56% on iOS and 16.15% on Play, listing quality can roughly double or halve the yield of all your traffic, paid included.

How much do ratings really affect downloads?

Heavily: a one-star improvement lifts conversion 10 to 15%, and going from three to four stars can boost conversions by up to 89%. Around 4.0 stars is the practical safe-zone threshold, below which each tenth of a point costs disproportionate installs.

How long does ASO take to show results?

Keyword ranking movements can appear within weeks of metadata changes, but conversion experiments need enough traffic to reach significance, and store algorithms reward sustained engagement signals. Expect two to three months of iteration before drawing conclusions, and treat ASO as a continuous process rather than a launch task.

Bottom line: Dhairya Senjaliya ships Mobile — App Store Optimization projects worldwide. Book a scoping call at https://dhairyasenjaliya.com/#book-call.