Native or cross-platform? The honest test

The backend, the API contracts, the data model, the analytics events and the design system all survive — usually the larger half of what you paid for. The client does not: Dart or JSX screens do not become Swift and Kotlin, so budget a fresh build per platform for the interface layer, less the discovery and product decisions already made. A middle route fits most cases: keep the Flutter or React Native shell and write only the hardware-facing part — the Bluetooth session, the background location service — as a native module behind a platform channel. We build cross-platform apps with that seam in place from the first sprint, so a hardware requirement arriving in year two is a module swap rather than a rewrite. Rebuilding a whole app because one screen needs native access is rarely the cheaper answer.

Review is the short part; the account state and the declarations are what move the date. Apple's App Review usually returns a verdict in a day or two, and Google Play is often same-week — slower for a developer account with no publishing history. Plan two weeks from code complete to live and that date holds. What buys you a rejection round: a privacy declaration that contradicts what the bundled SDKs actually collect, no working demo account for the reviewer, or no in-app route to delete an account once the app lets people create one. A new personal Play account must also run a closed test before it can go public, and that window cannot be compressed. So we settle who owns the developer accounts in week one rather than at code complete — an account that does not exist yet is the only part of this that can cost you a month.

Budget two to five days per platform per year for a small app with few dependencies, and two to three weeks for one leaning on Bluetooth, background location, a payments SDK or a map provider. Almost none of that is your own code — it is upgrading other people's libraries and re-testing every screen they touch. Both stores announce these deadlines well in advance, so we book the work into a sprint instead of handling it as an emergency: Google Play's target-API cut-off has fallen at the end of August every year so far, and Apple's minimum-SDK requirement usually follows in spring. Cross-platform does not spare you this and adds the framework's own major versions on top — a plugin whose maintainer has walked away is the version that costs weeks instead of days.

If the data outlives the handset or is shared with anyone, yes. A checklist that never leaves the phone does not need one; a driver app, a field service app or anything with a login does. What it adds is a system rather than an endpoint: authentication and roles, an API, a Postgres database, push delivery through APNs and FCM, file storage, separate environments, monitoring, and an admin console your own staff can open. That console is the first line cut from a budget and the first one missed, because without it support has nothing to look at when a driver rings in. Scope it as a backend build in its own right and price the running cost separately — it starts billing the month it deploys, not the month you get users.

You do, in writing, before anyone writes the sync loop. We bring the options — last write wins, per-field merge, server-authoritative with client replay, or stopping and asking the user — and put each against a scenario from your workflow: the driver marks a job delivered while dispatch reassigns it, both offline. You choose per entity, because the right answer for a status field is not the one for a signature or a photo. Two mechanics we do not leave open: timestamps come from the server, not the handset, since device clocks drift and users change them, and the losing version is kept and visible rather than silently discarded.

Two or three physical handsets per platform, chosen to match the worst hardware in your users' actual fleet, plus a cloud device farm — Firebase Test Lab or BrowserStack — for the model and OS combinations that cover most of your installed base. We ask for that inventory before the estimate rather than after, because it changes the test plan and occasionally the framework choice. What we will not promise is every Android skin: Samsung's One UI, Xiaomi's MIUI and several others apply their own battery management, and an app with a background service behaves differently on each. If your users carry those handsets, say so early and we test on them rather than around them.