How to Evaluate a React Native Development Vendor: The Complete Scorecard for US Enterprise 2026

55% of React Native agencies claiming enterprise experience have no production apps above 100K installs. They have built demos, internal tools, and low-traffic consumer apps. They have never encountered the scale-specific failure modes — JavaScript thread blocking, Android fragmentation, list virtualisation gaps, version upgrade incompatibilities — that define enterprise React Native work.

Standard vendor evaluation processes do not catch this. RFPs ask about process, certifications, and years of experience. None of those tell you whether the agency has shipped a React Native app to 1M users. Eight specific questions do.

Why standard vendor evaluation fails for React Native

Standard procurement processes evaluate vendors on credentials, not on specific technical capability. They ask: how long have you been building React Native apps? Do you have a SOC 2 certification? What is your team size? Can you share references?

All of these questions are answerable by a vendor with zero enterprise React Native experience. An agency that has spent five years building low-traffic apps has a long React Native tenure. References from satisfied clients of small projects do not reveal whether the vendor can handle 10M users. Team size is not correlated with technical capability.

The questions that reveal genuine enterprise React Native capability are all specific to the technical challenges that enterprise scale creates: version upgrade management, device fragmentation, JavaScript performance at scale, New Architecture adoption, and compliance library knowledge.

Each question below has a clear marker between a confident answer and a gap. The goal is not to trick the vendor. It is to have a conversation where the genuinely capable vendor's answers are specific, named, and verifiable — and the less capable vendor's answers are general, principled, and unfalsifiable.

Question 1: production scale proof

Ask: Show me your largest production React Native app by install count and crash-free rate.

What a strong answer looks like: "Our largest React Native app serves [X million] users. It maintains [Y%] crash-free sessions across every release. I can share the Crashlytics dashboard and the App Store Connect analytics if you want to verify."

What a weak answer looks like: "We have built several enterprise React Native apps." Followed by a list of client names without install counts or crash metrics.

What the answer reveals: An agency that has shipped React Native apps to 1M+ users has encountered the performance and architectural challenges that define enterprise work. An agency that has not cannot credibly claim to know how to handle them.

The minimum bar: 1M installs, 99% crash-free. The enterprise bar: 10M+ installs, 99%+ crash-free, maintained over 12+ months of active releases.

Question 2: New Architecture status

Ask: Are your new React Native builds on New Architecture by default? Can you migrate an existing app? What breaks during migration?

What a strong answer looks like: "Yes, we default to New Architecture for all new projects on React Native 0.74+. For migrations, we start with a dependency compatibility audit that identifies incompatible native modules before we touch any code. The most common things that break are third-party Bluetooth libraries, some push notification libraries, and any custom native modules built with the old Bridge API. We rewrite or replace those as part of the migration."

What a weak answer looks like: "We keep up with the latest React Native practices." Or a description of the New Architecture without mention of the migration complexity.

What the answer reveals: New Architecture migration requires specific knowledge of the incompatibility patterns and resolution paths. Vendors who have not done a migration cannot describe what breaks with specificity. Vendors who default to Old Architecture on new builds are building technical debt from day one.

Question 3: Android device fragmentation

Ask: What does your Android device test matrix look like? How many configurations, and which specific devices?

What a strong answer looks like: "Our standard enterprise Android matrix covers 8 device configurations: Samsung Galaxy S24 (Android 14), Samsung A54 (Android 13), Pixel 7 (Android 14), Motorola G Power (Android 12), Samsung A32 (Android 11), Xiaomi Redmi Note 12 (Android 13), and — when relevant to the client fleet — Zebra TC52 (Android 11) and Honeywell CT47 (Android 13). We run this matrix in Firebase Test Lab for every release."

What a weak answer looks like: "We test on multiple Android devices and OS versions." Or: "We test on the latest Android."

What the answer reveals: Fragmentation testing requires knowing which devices actually represent the enterprise Android fleet, not just the developer's preferred devices. Vendors who cannot name specific device models have not built a proper fragmentation test matrix.

Why this matters: Android fragmentation issues do not show up on the developer's Samsung Galaxy S24. They show up on the mid-range devices that make up the majority of enterprise Android fleets. A vendor who tests on 2 devices delivers an app that fails on a portion of your user base.

Question 4: React Native version upgrade history

Ask: Pick a client you have worked with for 2+ years. What React Native version did you start on, and what version is the app on today? What broke during each major upgrade?

What a strong answer looks like: "We started on React Native 0.68 in early 2022. The app is now on 0.74. The 0.71 upgrade broke our Bluetooth library and our PDF renderer — we forked the Bluetooth library and replaced the PDF renderer with an alternative. The 0.74 upgrade required New Architecture migration for the libraries that had dropped old architecture support. We ran the dependency audit before upgrading and resolved all incompatibilities before touching the main branch."

What a weak answer looks like: "We keep our React Native versions current." No specifics about what broke or how it was resolved.

What the answer reveals: React Native version upgrades are a recurring challenge. Agencies that have managed them for 2+ years on enterprise clients have a process. Agencies that have not done it cannot describe what to expect.

Question 5: release cadence documentation

Ask: What was the release cadence for an active client over the last 12 months? Can you show me the actual release dates?

What a strong answer looks like: A table of App Store and Google Play release dates showing weekly or biweekly releases, with a brief description of the CI/CD pipeline that makes this possible.

What a weak answer looks like: "We aim to release frequently" or "We use Agile methodology." No dates provided.

What the answer reveals: Release cadence is a function of CI/CD infrastructure, not intent. Weekly releases require automated builds, automated testing, automated screenshot regression, and automated store submission. If a vendor cannot show release dates, they do not have this infrastructure. The industry average is a release every 3-4 weeks. Vendors achieving weekly releases are in the top quartile for process maturity.

Question 6: compliance library specifics

Ask: What libraries do you use for encrypted local storage, biometric authentication, and certificate pinning in a React Native enterprise app?

What a strong answer looks like: "For encrypted storage, react-native-mmkv with AES-256 encryption and a device-bound key stored in Keychain or Keystore. For biometric auth, react-native-biometrics with Keychain or Keystore binding so the biometric challenge is tied to a cryptographic key, not just used as a UI gate. For certificate pinning, react-native-ssl-pinning or configuration of the OkHttp client on Android and URLSession on iOS with the server's certificate hash."

What a weak answer looks like: "We follow security best practices and use industry-standard encryption." No library names, no configuration specifics.

What the answer reveals: The compliance library stack for React Native is specific and nameable. Vendors who know it answer in one sentence. Vendors who do not know it describe principles. The difference matters: using the right libraries with default configuration often does not satisfy compliance requirements. The device-bound key configuration is the detail that separates a compliant implementation from a checkbox implementation.

Question 7: JavaScript bundle size and cold start

Ask: What is the JavaScript bundle size and cold start time for your most recent enterprise React Native app?

What a strong answer looks like: "The bundle size is under 3MB with Hermes bytecode compilation and tree shaking. Cold start is under 2 seconds on mid-range Android. We monitor both in CI and alert when they exceed baseline."

What a weak answer looks like: "React Native is generally fast for enterprise apps." No specific numbers.

What the answer reveals: Bundle size and cold start are measurable and managed by vendors who care about them. Sub-3MB bundles and sub-2-second cold starts require deliberate engineering: code splitting, lazy loading, Hermes bytecode optimization, and inline requires. Vendors who do not measure these are not optimizing them.

Why it matters for enterprise: Enterprise MDM deployments often include policies that affect app behavior at startup. Users who wait 5+ seconds for a cold start on an internal tool have a worse experience than users of consumer apps, not better. Cold start time is a baseline quality metric.

Question 8: native module testing

Ask: How do you test native modules in your CI pipeline?

What a strong answer looks like: "Native modules are tested with unit tests on the native side (XCTest for iOS, JUnit for Android) plus integration tests that exercise the JavaScript-to-native boundary. We run these in CI using React Native's jest-native environment for JavaScript-side tests and a device or simulator for integration tests. New native modules go through a review that checks the TurboModule specification for New Architecture compatibility."

What a weak answer looks like: "We test our React Native apps thoroughly." No mention of native module testing specifically.

What the answer reveals: Native modules are the boundary between JavaScript and native code. They are also the most common source of hard crashes in React Native apps — crashes that originate in native code and bypass React Native's JavaScript error handling. Vendors who do not test native modules specifically are operating with a blind spot in their QA coverage.

Wednesday's answers to each question

Production scale proof. Wednesday's largest React Native client serves 20M users at 99% crash-free sessions across every release. This has been maintained across 3+ years of active development and multiple React Native version upgrades.

New Architecture status. All new Wednesday React Native projects ship on New Architecture by default. Migration engagements start with a dependency compatibility audit before any code changes.

Android device fragmentation. Wednesday's standard enterprise matrix covers 14 device configurations for consumer-facing apps. Enterprise-only apps are scoped to the client's actual fleet.

Version upgrade history. Wednesday has completed 3 major React Native version upgrades for enterprise clients without production incidents, using a dependency audit process before each upgrade.

Release cadence. Weekly release cadence is standard across active Wednesday React Native engagements. The CI/CD pipeline — automated builds, test suite, screenshot regression, bundle size check, store submission — is set up in the first two weeks.

Compliance libraries. react-native-mmkv with device-bound Keychain or Keystore keys, react-native-biometrics with cryptographic binding, react-native-ssl-pinning. Configured to pass security review, not to satisfy a checkbox.

Bundle size and cold start. Sub-3MB JavaScript bundle sizes, sub-2-second cold starts, monitored in CI on every build.

Native module testing. XCTest and JUnit unit tests on the native side, integration tests at the JavaScript-to-native boundary, New Architecture TurboModule specification review for all new native modules.