What Cross-Platform App Development Costs You Later

Cross-platform app development bills you twice. The first bill you see during scoping. The second arrives as engineering weeks, some months after launch, in a quarter Google or Apple picked rather than you, and it buys your users nothing they can see.

That second bill is the argument worth having before you sign, and it has little to do with performance. One codebase, two stores, one team: the arithmetic is usually sound, and we say so knowing the native version would be the larger contract for us. What the estimate leaves out is that a shared codebase is a standing dependency on somebody else’s roadmap.

The upgrade bill nobody quotes

Flutter’s last year shows the shape of it, and its record here is better than most.

Swift Package Manager replaced CocoaPods as the iOS default, with the CLI doing most of the migration for you. Android Gradle Plugin 9.0 went the other way: it handles Kotlin itself now, and it breaks any project still applying the Kotlin Gradle Plugin by hand. Material and Cupertino are moving out of the core framework into independently versioned packages, and the in-framework copies are already frozen, due for deprecation at the next stable release. Every Flutter codebase alive owes an import migration nobody asked for.

Some churn earns its keep. Hybrid Composition++ arrived on Android as an opt-in flag that hands compositing of embedded native views to the OS, which fixes the frame drops teams have been dropping into native code to avoid for years. Flip a flag, real problem gone.

The rest ships no feature. What makes it expensive is the timing rather than the difficulty. The migration lands in the quarter Google chooses, and you staff it out of the same budget your roadmap was already spending.

Where the release actually slips

Framework releases are the visible half. Outages come from the layer underneath: an abandoned wrapper around a payment SDK, a barcode scanner whose last release predates the current OS.

Plugin authors carry obligations you never see. In Flutter’s case they now have to declare a minimum framework version of 3.44 in the package manifest, and an app depending on a plugin whose author skipped that step fails to build. Your release slips because of a maintainer you have never spoken to.

So check a dependency before you commit to it. Last release date, open issue count, whether anyone answers them. That pass costs an afternoon across a whole dependency list, and it decides whether next September is a recompile or a rewrite. We run it during scoping, we drop plugins over it, and when that means writing the integration ourselves it goes into the quote as a line you can see.

Pricing the upkeep, and the builds we turn down

Ask a vendor who does the OS-release work every September, and whether that sits inside a retainer or arrives later as a change order. Ask whether the framework version is pinned, and who gets to decide when you move off it.

We quote post-launch upkeep as a retainer instead of folding it into the build price. Apple and Google ship yearly releases that break things, and an app nobody maintains eventually gets pulled from the store. For scale, a two-store launch build sits at ₹10L – ₹14L in our mobile app cost guide, since shipping both stores together roughly doubles testing and store work even on one codebase. The retainer is a separate number and belongs in the same conversation. Where a migration is already public and dated, like the Material and Cupertino split, put the engineering time into the next two release cycles, before it lands in the sprint where it blocks a feature.

Which framework you pick matters less than the volume of that argument suggests. If your team already writes React and TypeScript, React Native wins and it is not close. If nobody there writes JavaScript the two start level, and our React Native and Flutter comparison covers where each pulls ahead; the hiring pool breaks the tie.

There are builds we will not take cross-platform. Any app where the hardware is the product: continuous video, real-time audio, a sustained Bluetooth session with a meter or a wearable, background location that has to survive the OS killing your process. An inspection app that photographs a meter and uploads the reading is a screens app with a camera in it, and cross-platform handles that comfortably. A dashcam running detection on a live feed gets Swift and Kotlin, costs you more, and we will say that on the first call. Same answer when you need a platform feature the week Apple announces it, because the alternative is waiting for a plugin or writing the bridge yourself, which is native work with coordination overhead stapled on. Our native versus cross-platform comparison has the full side by side.

We also turn down the mobile engagement where the money runs out at launch. Ask one fixed price to cover the build and a year of OS releases behind it, and something gets dropped; it is always the maintenance, because maintenance is the only part with no demo attached. If that is your budget, cut a feature or ship one platform properly. We would rather lose the enquiry now than three weeks in.