Cross-Platform Mobile (React Native / Flutter)
One codebase that ships to both the App Store and Google Play. Cross-platform development is a real engineering approach, not a shortcut, when the right framework is matched to the right project. The choice between React Native and Flutter has measurable consequences for staffing cost, maintenance over time, and how far a single codebase can stretch. We work through that decision before a line of code is written.
Most projects run $15,000-$60,000 depending on scope, integration complexity, and whether custom native modules are required.
one codebase, two stores: when cross-platform is the right call#
what cross-platform development actually means#
Cross-platform frameworks compile or bridge a single shared codebase into platform-specific binaries that run natively on iOS and Android. Flutter compiles to native ARM code via Dart. React Native renders actual native UI components through a JavaScript-to-native bridge -- or, in v0.74+, via the Bridgeless New Architecture that eliminates that bridge entirely.
The output is not a web app wrapped in a shell. Done correctly, a cross-platform app is indistinguishable from a native one in everyday use. The engineering tradeoff shows up at the edges: deep hardware access, complex animations, and platform-specific UI patterns where native code offers more direct control.
when it makes sense vs. when native is worth the cost#
Cross-platform development is the right call when:
- You need iOS and Android delivery at the same time, not sequentially
- The feature set is standard UI and API calls, without heavy hardware integration
- Your team works in JavaScript (React Native), or you need web and desktop in addition to mobile (Flutter)
- Maintenance budget matters: one codebase to update beats two
Native development is worth the additional cost when:
- The app's core functionality depends on platform-specific APIs with no cross-platform equivalent
- You're building sustained 60fps rendering -- games, video editing, AR
- A native module integration failure would block a tight App Store review deadline
what you give up and what you gain#
You gain shipping speed and a smaller maintenance surface. The tradeoff is direct access to platform APIs without native modules, and the occasional version mismatch between the framework and a new OS release. Both React Native and Flutter have improved their native API parity significantly, but neither is zero-overhead. We document the specific gaps relevant to your feature list during scoping, so there are no surprises mid-build.
React Native vs Flutter: how we choose#
React Native: JavaScript-native, deep platform access#
React Native renders real native UI components. The JavaScript developer talent pool for React Native outnumbers Dart/Flutter developers approximately 20:1, which directly affects staffing cost and team flexibility (BrowserStack, 2025). LinkedIn US shows roughly 6,400 React Native job postings compared to approximately 1,100 Flutter postings as of 2025 -- a number that reflects how deeply React Native has embedded itself in enterprise mobile work (DEV Community, 2025).
The v0.74+ Bridgeless New Architecture removes the JavaScript bridge that historically caused latency on complex interactions (React Native documentation, 2025). For teams with existing JavaScript or React web codebases, React Native enables genuine code sharing: business logic, state management, and API client code travel between web and mobile. The shared layer is actual running code, not a common language.
React Native is our default recommendation when the client team is JavaScript-native, or when the product has a React web companion that benefits from shared logic.
Flutter: custom rendering, true multi-platform reach#
Flutter does not use native UI components. It draws everything through its own Skia/Impeller rendering engine, which means the same codebase runs on iOS, Android, web, and desktop without separate renderers. Flutter achieves 95%+ code reuse across all four platforms; React Native achieves 60-70% reuse when paired with a React web app (DroidsOnRoids, 2025).
Flutter holds approximately 46% of cross-platform mobile framework market share vs. React Native at 35% as of 2025 (Statista via TechAhead, 2025). Its growth is concentrated in teams that need consistent UI behavior across every platform: fintech, enterprise tooling, products where pixel-perfect design fidelity is non-negotiable.
Flutter is our recommendation when the client needs multi-platform reach beyond iOS and Android, when the design system is complex and custom, or when rendering consistency across platforms is a hard product requirement.
decision factors: team, roadmap, performance, timeline#
We work through four factors at scoping:
- Team composition -- JavaScript-native or open to Dart? This affects build timeline and long term ownership cost. In our experience, the Dart learning curve is usually a week, not a blocker, but it still adds time early on.
- Roadmap scope -- Does the product need web or desktop reach within 12-18 months? Flutter's multi-platform story is stronger here.
- Performance profile -- Sustained high-frame-rate rendering on complex UIs? Flutter's custom renderer gives more predictable results.
- Timeline -- React Native moves faster early when the team already knows the language. Flutter pays off more on long-lived products.
The output of this process is a written framework recommendation with documented reasoning, not a verbal suggestion that evaporates after the call.
what's included in a cross-platform engagement#
stack selection and architecture scoping#
Before development begins, we produce a written architecture brief: framework recommendation and reasoning, proposed app architecture (state management, navigation, data layer), native modules required, and known platform-specific risks for the feature set. This gives the client a checkpoint before build costs are committed.
UI build and platform parity testing#
We build against the agreed design system, with platform parity testing as part of the definition of done for each feature, not a final QA pass. Testing covers physical devices on current and one previous OS generation for both iOS and Android, catching the fragmentation issues that typically surface closest to production.
app store submission and release pipeline#
App store submission is included: provisioning profiles, signing, build configuration, and the submission workflow for both Apple App Store and Google Play. We configure a CI/CD release pipeline (typically GitHub Actions or Fastlane) so the client ships future updates without external help. See our mobile development overview for how this fits within our broader mobile practice.
handoff, documentation, and optional retainer#
Handoff includes architecture documentation, a component and screen inventory, environment setup instructions, and a documented release process. Clients who want ongoing support can continue on a monthly retainer. For clients with iOS-specific or Android-specific native requirements alongside a cross-platform core, we scope those as separate workstreams.
pricing and timeline#
Scope drives timeline more than framework choice. A standard engagement -- authentication, core feature set, API integration, app store submission -- runs 10-16 weeks. Complex apps with offline sync, custom native modules, or large data surfaces run 16-24 weeks.
| Scope | Estimated Range | Typical Timeline |
|---|---|---|
| MVP (auth, 3-5 screens, API integration) | $15,000-$25,000 | 10-14 weeks |
| Standard product (full feature set, custom UI) | $25,000-$45,000 | 14-20 weeks |
| Complex app (native modules, offline sync, multiple roles) | $45,000-$60,000+ | 20-28 weeks |
These are scoping estimates. The architecture brief produces a fixed-scope proposal before build begins. If you're weighing cross-platform against a web or SaaS approach, that's a conversation worth having before any framework is chosen. See our technologies overview for how we approach stack decisions across the full product surface.
FAQ#
Should I build my app in React Native or Flutter?
It depends on your team and roadmap. React Native fits when your team is JavaScript-native or when you have a React web app with logic worth sharing. Flutter fits when you need iOS, Android, web, and desktop from one codebase, or when design consistency across platforms matters more than anything else. We document this recommendation during scoping, so the decision is written, not verbal.
What is the difference between React Native and Flutter?
React Native renders actual native iOS and Android UI components, driven by JavaScript. Flutter uses its own rendering engine and draws the UI directly, bypassing native components entirely. Both produce apps that feel native to users. The practical differences are in staffing (JavaScript talent is easier to find), platform reach (Flutter extends to web and desktop more naturally), and performance predictability on complex UIs.
Can a cross-platform app replace two native apps?
For most commercial products, yes. The cases where cross-platform falls short -- sustained AR rendering, complex hardware APIs, OS-level features the framework has not yet bridged -- are specific and identifiable. We flag them during scoping, before any build work starts.
How much does cross-platform mobile development cost?
Most projects run $15,000-$60,000 depending on feature scope, integration complexity, and whether native modules are required. A fixed-price proposal is produced after scoping, so the number is binding.
Do you handle app store submission?
Yes. Both Apple App Store and Google Play submission is included in every engagement. We configure signing, provisioning, build pipelines, and release automation so the client manages future releases independently.
If you have a framework decision to make and want an engineering opinion before committing to a build, start with a scoping call. We'll work through your feature set, team, and timeline, and send a written recommendation before anything is agreed.
