Should we build with Flutter or React Native?

Flutter suits apps with a strong custom interface and animation, since it draws every pixel itself and looks the same on both systems. React Native suits teams with JavaScript or TypeScript skills who want web developers contributing to the app, and it hands off to native modules cleanly. We recommend one after seeing the feature list rather than by default.

Can one codebase really pass review on both stores?

Yes, with the store rules treated as part of the specification rather than as a final step. We match permission strings to real usage, keep privacy declarations accurate, and add account deletion paths where the guidelines require them. Review outcomes depend on policy compliance, so we follow the published rules for each store.

What happens when a plugin breaks after an operating system update?

We list the plugins a project depends on before development starts and flag the ones touching regulated areas such as background location, contacts, health data, and payments. Where a wrapper looks fragile, we write a small native module ourselves, which takes a few days and removes that dependency from your critical path.

How long does a cross-platform app take, and what does it cost?

A mobile MVP is a typical order of $4,800 to $8,500 across four to six weeks, covering around twenty to twenty-five screens on one codebase for both stores. Larger products, or ones with payments, offline sync, and hardware integration, run longer and are quoted per phase at our flat rate of $39 per hour.

Do we still need native developers for some features?

Sometimes, for a defined piece of work rather than a whole app. Camera pipelines, Bluetooth and sensor work, background location, and anything a store treats as sensitive often justify a small native module. The rest of the product stays in the shared codebase.

Cross-Platform Mobile App Development

One Flutter or React Native codebase for iOS and Android, with shared screens, native modules where needed, and both store releases handled.

See our work:

AccuLevels: Precision Measurement Mobile App→Voteme App→Walking Cure→

You want your app on both stores, and you would rather not pay for it twice. That is what a cross-platform build offers: one codebase, one feature roadmap, and two releases that mostly travel together. The offer holds for most business apps and breaks in predictable places, around heavy device hardware, platform-specific interface rules, and plugins that fall behind a new operating system version.

Much of the work is deciding where sharing saves money and where it starts to cost you, then setting up a release pipeline that keeps both stores current without a scramble each time a store changes a requirement.

What a cross-platform build is

We write the app once in Flutter or React Native and compile it for iOS and Android. Screens, navigation, business logic, API calls, and most of the interface live in the shared layer. A small platform layer handles what genuinely differs: permission prompts, notification behaviour, file access, biometrics, payment rules, and hardware the framework cannot reach on its own.

Who it suits

Cross-platform fits products where both versions should behave the same: account apps, booking and on-demand services, community products, internal field tools, and utilities that read a sensor and show a number. It also fits teams with one product owner and one backlog, because there is one codebase to keep in step.

Two situations point toward native instead. If the platform capability is the product, as with a camera pipeline, an audio engine, or a game, the framework tends to sit in the way. A single-store launch is the other case, since sharing code with a platform you are not shipping on buys nothing this quarter.

Framework choice, and the native comparison

Flutter draws every pixel itself, so the interface and animation look the same on both phones. Its plugin ecosystem covers common needs well and niche hardware thinly, which is where a native module gets written. React Native keeps the work in TypeScript and JavaScript, which matters when your web team will contribute, and it hands control to native modules cleanly.

AccuLevels shows that split in practice. The app reads the accelerometer and gyroscope through React Native's sensor APIs, with calibration logic that compensates for device-specific variance, so one measurement implementation serves both platforms instead of two drifting apart.

Native stays right for hardware-heavy products and single-platform launches. The comparison that matters is one shared codebase plus a few native modules against two codebases and two teams.

Shared interface, platform behaviour

Shared UI does not mean identical behaviour. Android users expect the system back gesture and a back stack that survives process death, while iOS users expect swipe-back, sheet patterns, and safe-area handling around the notch and home indicator. Permission dialogs read differently on each system, and Android notification channels have no iOS equivalent.

We keep layout, copy, and state in the shared component and let behaviour branch in one platform file. The difference stays visible in a single place instead of scattered across screens.

Plugin risk and the native escape hatch

Every plugin is a dependency with an owner who may be slower than Apple and Google. A camera or Bluetooth plugin can lag an operating system release, and a policy change can invalidate the way it requests a permission.

We list the plugins a project depends on before the build starts and mark the ones touching regulated areas: background location, contacts, health data, payments. Where a wrapper looks fragile, we write the small native module ourselves, which costs a few days and removes a dependency from your critical path.

Builds and releases for two stores

Both stores separate build, signing, and review. Android wants a signed app bundle, a keystore you keep permanently, and a staged rollout you can halt. iOS wants provisioning profiles, certificates, TestFlight rounds, and privacy answers that change between releases. We set up continuous integration so a merge produces installable builds for testers on both platforms, and the signing credentials stay in your accounts.

Review outcomes depend on policy compliance rather than on our wishes, so we treat the guidelines as part of the specification: permission strings that state the real reason, privacy declarations that match what the app collects, and account deletion paths where the rules require them.

Where cross-platform genuinely costs more

Testing doubles: two operating system versions to track, two device families, two sets of permission dialogs, and two crash reporters feeding one dashboard. Deep links, push notifications, in-app purchases, and background execution each need a per-platform implementation for the shared layer to call.

Android fragmentation still takes time, because one build runs across phones whose manufacturers changed background limits and battery rules. That work usually stays smaller than running two native projects, as long as the estimate includes it.

Where the project starts

Three starting points, each with a different first phase.

A plain idea. We run discovery on the user journeys, then build the shared layer and both platform shells from the first commit. The framework choice is still open, and your team's existing skills carry weight in it.

An existing conventional codebase. One platform already works and you want the other without a second team. We inventory what is genuinely platform-specific, port the rest into the shared layer, and keep the current release pipeline running while the new one proves itself.

An AI or vibe-coded prototype. The screens exist and some of them demo well. We audit the architecture, the data model, and the API calls, keep what holds up, and rebuild whatever would block a store release or a first paying user. Your prototype stays useful as a specification and as working code where it earns its place.

What we deliver

A shared codebase in your repository, the platform layer, continuous integration for both stores, and the release material each store asks for. You receive the signing credentials, store accounts, and documentation naming every native module and the reason it exists.

What it costs

Work runs at our flat rate of $39 per hour, or as a fixed scope after discovery. The pricing page lists a mobile MVP as a typical order of $4,800 to $8,500 across four to six weeks, covering roughly twenty to twenty-five screens on one codebase for both stores, which matches a cross-platform first release. From there the number moves with a second platform's payment and push rules, an unplanned native module, an offline sync layer, and any hardware integration that needs its own testing pass. We quote those in weeks and phases.

Proof

Voteme is a cross-platform social app with voting, credits, chat, and moderation tools, delivered with Xamarin for iOS and Android. It shows one delivery program covering both stores for a feature-dense product, with reporting and blocking in the shared layer, so both platforms get them together.

AccuLevels is a level and measurement utility published on the App Store and Google Play, built as one React Native codebase. It shows a shared build carrying a hardware-dependent feature, because the calibration logic that absorbs device variance ships once and behaves the same on both platforms.

Walking Cure is a WordPress clinic website for a California practice. It is the web side of health and wellness work that often grows a patient-facing app, and it shows the content structure we bring when an app has to match an existing clinic brand.

Related services

Mobile app development covers the full range, including native builds when one platform deserves its own codebase.
Mobile backend and cloud infrastructure for the accounts, data model, and APIs the shared app talks to.
Mobile SDK and API version upgrades for the annual operating system and store requirement cycles that affect both platforms.
Mobile app maintenance and support once the first release is live and plugins need to keep pace with new system versions.
API development and integration when the app needs to connect to systems you already run.

Next step

Send the feature list, the platform you need first, and the systems the app must talk to. We will say which parts belong in the shared layer, which need a native module, and what a first release covers.

Contact us with your requirements, or run them through the Vasilkoff.info estimator to get an initial scope and cost range before you talk to anyone.