For the codebase decision itself, not mobile delivery broadly
Cross-Platform App Development
Sharing one codebase across platforms is a real engineering trade-off, not a shortcut, and most of the pain shows up in the ten percent that does not share cleanly. This practice goes deep specifically on that trade-off: what breaks, the native escape hatches available, and when cross-platform genuinely stops being the right call.
How the shared-codebase trade-off actually plays out
What shares cleanly, what needs a native escape hatch, and when to stop sharing.
90 secSample frame · video pending01Before committing to one codebase
What genuinely shares, and what does not.
The shared-codebase promise gets oversold constantly. Four questions settle how much of your specific app will actually share cleanly.
How deep is the hardware or sensor integration?
Background processing, deep camera control and certain sensors resist clean sharing. These usually need a native module regardless of framework choice.
How much does the interaction model rely on platform gestures?
Standard forms and lists share almost perfectly. Complex, platform-native gesture patterns are where a shared codebase shows its seams first.
Will the team maintaining this grow or shrink?
A shrinking or lean team benefits most from one codebase. A growing team with native specialists can absorb a native rewrite more easily later.
How much has the app already grown past its first version?
A young app shares cleanly by default. A mature app has usually accumulated feature requests the framework was never built to serve well.
| Shares cleanly | Usually needs a native escape hatch | |
|---|---|---|
| Forms, lists, navigation | Yes, close to fully | Rarely |
| Standard camera or location use | Mostly | Occasionally, for advanced control |
| Background processing | Partially | Often |
| Complex platform-native gestures | Rarely | Usually |
02Agreed before the codebase is chosen
The ledger that keeps a shared codebase honest
Cross-platform engagements go wrong when 'one codebase' quietly becomes a promise nobody can keep once a hard feature shows up. This ledger states plainly what you bring, what we build, what returns, and what stays yours.
- Your side
You bring
- The product scope and target launch window
- Team size and its native development experience, if any
- Any platform-specific features already known to be required
- Our side
We build
- A shared React Native or Flutter codebase covering both platforms
- Platform-specific escape hatches scoped for the features that need them
- A build and release pipeline covering both stores from one source
- Your side
You receive
- Working apps published to both stores from one codebase
- A documented list of what needed a native escape hatch
- A pipeline your team can run without doubling its effort
Never leaves you
- Product direction and design authority over both platforms
- All intellectual property in the shared codebase
- The decision on when a feature justifies going native
Where the line sitsOne codebase does not mean one identical app. Platform conventions are respected inside the shared structure, not flattened into the lowest common denominator.
03From framework choice to both stores
Four stages, each closing on evidence
Cross-platform apps that feel wrong on one platform usually skipped a stage here. This system closes each one with something tested on real devices, on both platforms.
Choose React Native or Flutter deliberately
The framework decision is made against your specific hardware needs and interaction complexity, not a team preference carried over from the last project.
A framework chosen against the actual appMap likely native escape hatches early
Features likely to resist clean sharing are identified during design, so a native module is a planned exception, not a late scramble.
Escape hatches scoped before they are neededBuild and test both platforms together
iOS and Android are developed and tested in parallel throughout, catching platform-specific regressions before they compound into a larger rework.
Both platforms tested as first-class, not one then the otherRelease to both stores from one pipeline
The build and release pipeline ships both platforms from the shared codebase, so an update never means maintaining two separate release processes.
A pipeline that ships both stores from one source
04What actually moves the number
Four drivers, priced from the trade-off
Cross-platform work is priced against how much of the app will genuinely share, because these four factors change scope by multiples.
Depth of hardware and sensor integration
An app needing deep hardware control costs more here than one built mostly from standard forms, lists and navigation.
Number of anticipated native escape hatches
Each escape hatch is real engineering, distinct from the shared codebase, and is priced and scoped as its own scoped piece of work.
Existing app size, if this is a migration
Moving an existing native app to a shared codebase costs more than starting fresh, because existing behaviour must be preserved feature by feature.
Platform-specific design fidelity required
Matching each platform's native conventions closely costs more than accepting a single, slightly generic look across both.
05Evidence and proof
Codebases that stayed shared where it mattered.
Cross-platform proof is a shared codebase that held under real growth, with escape hatches used sparingly. Every record here waits for written client approval before production.
Explore case studiesBoth stores launched from one codebase inside a single quarter.
Pillar Learning had a small team and two platforms to reach at once. A shared Flutter codebase with two scoped native modules shipped to both stores from a single team.
- Codebases maintained
- One, plus two modules
- Time to both stores
- One quarter
A background-processing feature shipped without forking the codebase.
Tern's dispatch app needed reliable background location tracking the framework could not handle cleanly. A scoped native module solved it while the rest of the app stayed fully shared.
- Codebase forked
- No, one native module added
- Feature reliability after fix
- Consistent across both platforms
They told us exactly which feature would need a native module before we hit the wall ourselves, which saved a rewrite.
Sample · pending client approval
06Read this first
When cross-platform is the wrong call
Forcing a heavily hardware-dependent app into a shared codebase spends effort fighting the framework instead of building the product. The exits are marked plainly. Where cross-platform is justified, it runs on React Native and Flutter with native modules where genuinely required.
- AR/VR development
The app is fundamentally hardware or performance heavy
Games, AR experiences and deep hardware integration usually justify native from day one, rather than fighting a shared framework repeatedly.
- Application development
The platform decision is still genuinely open
If web, mobile or something else has not been settled yet, that broader decision belongs on the generalist application page first.
- Team extension
You need mobile engineers, not a delivery layer
If your team already owns the mobile roadmap and needs capacity, team extension fits better than a commissioned build.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | Platforms and scope are settled | Design and priorities | Shared codebase and escape hatches |
| Delivery pod | Scope evolves as the user base grows | Product decisions each cycle | Engineering, QA, releases |
| Team extension | Your leads run mobile delivery | Architecture and standards | Named mobile engineers |
07Straight answers
Asked before a codebase decision is locked in.
01React Native or Flutter, which is actually better?
Neither wins outright. The choice depends on your team's existing skills, the specific native modules a feature might need, and your long-term maintenance plan.
02What exactly breaks when you share code across platforms?
Deep hardware access, background processing and complex platform-native gestures are the usual friction points. Most forms, lists and standard navigation share cleanly without issue.
03How is this different from mobile app development?
Mobile app development covers the whole mobile delivery decision, including native as one option. This practice goes deep specifically on the shared-codebase trade-off itself.
04What is a native escape hatch?
A scoped native module built for one feature the shared framework cannot handle cleanly. The rest of the app stays shared; only that one feature goes native.
05When should we abandon cross-platform for a native rewrite?
When enough features have needed escape hatches that the shared codebase is doing less and less real work. An honest assessment can tell you if you have reached that point.
06What does cross-platform app development cost?
Priced against hardware integration depth, expected escape hatches and platform-fidelity requirements from the assessment. Fewer hardware needs generally mean lower cost.
07Can you migrate an existing native app to a shared codebase?
Yes, though it costs more than starting fresh, since existing native behaviour must be preserved feature by feature during the migration.
08Do you build the backend the app talks to as well?
Yes, when needed. API development and cross-platform app development share this practice's delivery discipline, so a new backend need does not require a separate vendor.