Usually shared
One codebase- Screens, components and navigation
- App state, validation and business rules
- API client, caching and offline storage
- Analytics events and feature flags
- Most unit and widget/component tests
Cross-platform app development
Cross-platform app development: one codebase, two native-feeling apps
A shared codebase can deliver your iOS and Android apps with one team and one release rhythm. Comtau builds cross-platform apps with Flutter or React Native and writes native code where the shared layer can't do the job.
iOSNavigation bar, wallet sheet
AndroidTop app bar, payment sheet
Shared code · both apps
- UI components
- Navigation
- State
- API client
- Validation
- Analytics events
Apple Pay sheet · widgetsGoogle Pay sheet · background work
Your backendone API for both apps
Illustrative example - not a client project
Know what you are buying
What a shared codebase covers, and what it doesn't
"Write once, run anywhere" is only partly true. Knowing where the line sits is what makes cross-platform estimates reliable.
Usually platform-specific
Native code- Wallet payment sheets and in-app purchase details
- Home Screen widgets, Live Activities, app shortcuts
- Background execution and some notification types
- New OS capabilities before the framework supports them
- Accessibility checks and store releases, done per platform
Compare the approaches
Native, Flutter, React Native or hybrid
Four ways to put one product on iOS and Android, comparing native code with the main cross-platform app development frameworks on the questions that decide the choice. The two middle columns are what most people mean by cross-platform app development services.
| Question | Two appsNative (Swift + Kotlin) | Shared codeFlutter | Shared codeReact Native | Web in a shellHybrid (WebView) |
|---|---|---|---|---|
| Language | Swift, Kotlin | Dart | TypeScript / JavaScript | HTML, CSS, JavaScript |
| How the UI is drawn | Platform UI frameworks | Own rendering engine draws every pixel | Real platform components, driven from JavaScript | A web page inside the app |
| Platform look & feel | Exact | Consistent across platforms; native look needs care | Native components by default | Web-like unless heavily styled |
| New OS features | Day one | Via plugins or platform channels | Via libraries or native modules | Via plugins, often later |
| Team you need | iOS and Android specialists | Dart developers plus native help | React developers plus native help | Web developers |
| Fits well | Platform-heavy apps, top-tier polish, separate platform teams | Custom branded UI, identical design on both platforms | React teams, sharing logic with a web app, over-the-air fixes | Wrapping an existing web app, internal tools, content |
| Watch out for | Two codebases to keep in step | App size; framework and plugin upgrades | Dependency upkeep; native module quality | Performance and offline limits |
Two apps
Native (Swift + Kotlin)
- Language
- Swift, Kotlin
- How the UI is drawn
- Platform UI frameworks
- Platform look & feel
- Exact
- New OS features
- Day one
- Team you need
- iOS and Android specialists
- Fits well
- Platform-heavy apps, top-tier polish, separate platform teams
- Watch out for
- Two codebases to keep in step
Shared code
Flutter
- Language
- Dart
- How the UI is drawn
- Own rendering engine draws every pixel
- Platform look & feel
- Consistent across platforms; native look needs care
- New OS features
- Via plugins or platform channels
- Team you need
- Dart developers plus native help
- Fits well
- Custom branded UI, identical design on both platforms
- Watch out for
- App size; framework and plugin upgrades
Shared code
React Native
- Language
- TypeScript / JavaScript
- How the UI is drawn
- Real platform components, driven from JavaScript
- Platform look & feel
- Native components by default
- New OS features
- Via libraries or native modules
- Team you need
- React developers plus native help
- Fits well
- React teams, sharing logic with a web app, over-the-air fixes
- Watch out for
- Dependency upkeep; native module quality
Web in a shell
Hybrid (WebView)
- Language
- HTML, CSS, JavaScript
- How the UI is drawn
- A web page inside the app
- Platform look & feel
- Web-like unless heavily styled
- New OS features
- Via plugins, often later
- Team you need
- Web developers
- Fits well
- Wrapping an existing web app, internal tools, content
- Watch out for
- Performance and offline limits
Kotlin Multiplatform is another option: it shares business logic while keeping native UI on each platform. It suits teams that already have strong native developers. For apps used by company staff, with single sign-on and MDM distribution, see enterprise mobile app development.
React Native vs Flutter
Choosing between the two leading frameworks
Both are mature, widely used and backed by large companies: Google maintains Flutter and Meta maintains React Native. The deciding factors are usually your team and your interface, not raw capability.
Choose Flutter when
The interface is the brand
- Custom, highly designed UI that must look the same everywhere
- Rich animation and motion
- A team happy to work in Dart
- Possible later targets: web or desktop internal tools
Choose React Native when
Your team thinks in React
- Existing React or TypeScript developers
- Logic to share with a React website
- Platform-native components and conventions matter
- JavaScript fixes delivered over the air, within store rules
An honest limit
When we'd advise against cross-platform
A shared codebase is a means, not a goal. In these cases two native apps, or native on one platform first, usually serve you better.
Graphics-heavy apps
Games, 3D, AR and complex real-time visualizations depend on platform graphics frameworks.
OS extensions are the product
When widgets, watch apps, keyboards or system extensions are the core of the product, most of the code is native anyway.
You already have native teams
Strong iOS and Android teams are an asset. A framework migration should solve a real problem.
Release
One codebase, two store releases
The code is shared, but each store has its own review, rollout controls and monitoring. We run both lanes from the same pipeline, so versions stay aligned.
App Store
iPhone, iPad and Apple Watch apps
- Build & signCI builds the release, signs it with your distribution certificate and uploads it.
- TestFlightYour team and invited testers install the exact build that will ship.
- App ReviewApple checks the build, privacy details and store listing before release.
- Phased releaseAutomatic updates roll out to users gradually over seven days; it can be paused.
- MonitorCrash reports, performance and ratings decide whether the rollout continues.
Google Play
Android phones, tablets and foldables
- Build bundleCI produces a signed Android App Bundle; Play generates optimized APKs per device.
- Testing tracksInternal and closed testing tracks put the build on real devices first.
- Play reviewGoogle reviews the release against policy, target API level and data safety declarations.
- Staged rolloutThe update reaches a chosen percentage of users first and can be halted.
- MonitorAndroid vitals show crash and ANR rates by device and OS version.
- Automated
- Review or decision point
- Live with real users
What we deliver
Android and iOS app development services from one team
Cross-platform projects include everything a native project does, plus the extra discipline of keeping two platforms honest.
Architecture
- Clear boundary between shared and native code
- Feature modules and state management
- Offline storage and sync
Shared UI system
- One component library
- Platform conventions where users expect them
- Accessibility checked on both platforms
Native modules
- Swift and Kotlin for platform features
- Payments, widgets, background tasks
- Vetted third-party plugins only
Testing on both
- Shared unit and component tests
- End-to-end tests on iOS and Android
- Real-device passes before release
CI for two apps
- One pipeline, two signed builds
- Beta builds on every merge
- Versioning kept in step
Upgrades
- Framework and plugin updates planned
- New OS versions tested in beta
- Dependencies kept current
Questions
Frequently asked questions
What is cross-platform mobile app development?
It means building the iOS and Android versions of an app from one shared codebase, usually with Flutter or React Native, instead of writing two separate native apps. The shared code covers most of the interface and logic. Smaller native parts handle platform-specific features. You get two apps in the stores, built and released by one team.
Is a cross-platform app slower than a native one?
For most business and consumer apps, users won't notice a difference: both Flutter and React Native compile to native code and render at the display's refresh rate when built well. Gaps show up in heavy graphics, complex animations on low-end devices, and very large lists if they are handled carelessly. Those cases are known in advance, and we flag them during discovery.
Which cross-platform framework is best?
There isn't one best framework, only a better fit, which is worth remembering when a cross-platform app development company offers only one. Flutter suits apps with a custom, branded interface that should look identical on both platforms. React Native suits teams that already work in React and TypeScript, apps that share logic with a React website, and products that benefit from over-the-air updates. The comparison above covers the details.
What is the difference between hybrid and cross-platform apps?
"Hybrid" usually means a web app running inside a native shell (WebView), for example with Ionic or Capacitor. Cross-platform frameworks like Flutter and React Native produce native interfaces instead. If you are looking for hybrid mobile app development services to wrap an existing web app, that can be a reasonable shortcut. For apps people use daily, a cross-platform or native app generally feels better and has fuller access to device features.
Can we move an existing native app to a shared codebase?
Yes, and it rarely needs a big-bang rewrite. Both frameworks can be added to an existing native app screen by screen, so the most-used flows move first while the rest keeps working. We usually start with an audit of the current apps to decide whether migration pays off at all. See maintenance & modernization.
Does cross-platform development cost less?
Usually less than two separate native apps, because most of the code, tests and design work are shared, and one team ships both releases. It is not half the cost. Platform-specific features, testing on both platforms and two store submissions remain separate work. The savings are largest when most screens are standard.
Not sure which approach fits?
Describe your app, your users and your team. We'll recommend native, Flutter or React Native, and explain the trade-off in plain terms.
- Tell us who will use the app and what it has to do.
- We suggest a first release and the approach that fits it.
- You get an estimate tied to a written first-release scope.