One codebase, two stores, and the parts that still are not shared
Cross-platform development builds for iOS and Android from one codebase, usually React Native or Flutter. Most of the code is shared. What is not shared is platform-specific behaviour, store requirements, native module work and the testing, which still happens twice.
Cross-platform is sold as writing once and shipping twice, and the reality is closer to writing most of it once. That remaining portion is where projects get misjudged, because it is invisible in the estimate and unavoidable in the build. And it is larger in apps that touch hardware, payments or platform conventions.
Estimates assume complete sharing and encounter the exceptions. Navigation and interaction conventions differ between platforms, so an interface that feels native on one feels wrong on the other. Permissions, notifications and payments have platform-specific behaviour. A required capability has no maintained library, so someone writes native modules in both languages, which needs skills the team chose cross-platform to avoid. And testing is still two platforms, because a shared codebase does not produce shared behaviour.
When this work makes sense
Questions worth asking any supplier
How much of the app touches platform-specific capability? That portion is not shared.
Does every capability you need have a maintained library? An unmaintained dependency is a future rewrite.
Does the interface need to feel native to each platform, or is consistent branding acceptable?
What is the team's existing skill set? React experience makes React Native cheaper in practice.
Is performance critical? Cross-platform is adequate for most apps and not for all of them.
Deliverables
Framework recommendation with the trade-offs stated rather than asserted
The app for both platforms from a shared codebase
Platform-specific handling where conventions genuinely differ
Native module work where required capability has no reliable library
Testing on both platforms across a representative device range
Store submissions for both, handled against each platform's requirements
Shared CI and release process for both builds
Crash reporting segmented by platform
Built with
Process
Scoping begins by listing everything the app must do that touches the platform rather than the interface, camera, notifications, payments, background work, biometrics, deep links, and checking each against library maturity. That list is where cross-platform estimates break. A capability with no maintained library means native work in two languages, which is precisely the cost the approach was chosen to avoid, and it is better known in week one.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
React Native, Flutter, or two native apps
React Native
Fits: Teams with React experience; large ecosystem and mature libraries
Limits: Performance is good rather than native; some capabilities need bridging
Flutter
Fits: Consistent interface across platforms, strong rendering performance
Limits: Dart is a separate skill set; interfaces can feel non-native on both platforms
Two native apps
Fits: Performance-critical work or deep platform integration
Limits: Roughly double the build and the maintenance, permanently
Case studies
No published cross-platform case study.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
How much code is actually shared?
Typically most of it for conventional apps, and considerably less for anything touching hardware, payments or platform conventions. The honest estimate depends on your feature list, which is why scoping starts by identifying what is platform-specific rather than assuming a percentage.
React Native or Flutter?
React Native if your team knows React, because the skills transfer and hiring is easier. Flutter if you want tight control over rendering and a consistent look across platforms. Both are mature; the deciding factor is usually your team rather than the framework.
Will it feel native?
Close, and not identical. Users rarely identify the framework; they do notice interactions that follow the wrong platform's conventions. That is a design decision rather than a framework limitation. You can follow each platform's conventions at the cost of some shared code.
Is performance good enough?
For most business apps, comfortably. Heavy animation, intensive processing or real-time graphics are where native pulls ahead. If you are unsure which category you are in, you are almost certainly in the first.
Can we start cross-platform and go native later?
You can, and it is a rewrite rather than a migration. It is a reasonable path if the product needs validating first and native is a known future requirement. It is a poor plan if chosen to defer a decision nobody wants to make.
What happens when a library we depend on is abandoned?
You maintain it, replace it, or write the native module yourself. Dependency health is worth checking during scoping, a library with no commits for two years supporting a core feature is a risk on the critical path.
Do we still need to test on both platforms?
Yes, fully. A shared codebase does not produce shared behaviour: platform differences in rendering, permissions and background handling surface at runtime. Testing effort is not halved by cross-platform development, and budgets that assume it is come up short.
Who maintains it when the framework releases a breaking version?
Somebody has to, on a schedule, and it is worth naming them before you start. Cross-platform frameworks move faster than the native platforms underneath them, so an app left untouched for a year can need real work before it will even build. That maintenance is a running cost rather than a one-off, and a proposal that does not mention it has moved the cost rather than removed it.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.