Most business apps fail on the fifth floor of a concrete building with two bars of signal — not in the design review. We build for the conditions your users are actually in: patchy connectivity, a cracked screen, gloves on, and a battery that has to last a shift.
Tested on your worst device10–18 weeks to storePublished under your accounts
Mobile app development is building software that runs on iOS and Android phones and tablets, including the backend it talks to. Canopus builds native apps in Swift and Kotlin and cross-platform apps in Flutter and React Native — with offline-first data handling, store submission under your own developer accounts, and full source ownership.
Each has a different centre of gravity — and a different thing that goes wrong if it's underestimated.
Drivers, engineers, inspectors, warehouse staff. Offline-first by necessity: a local database, a sync queue, conflict rules and honest UI about what has and hasn't reached the server.
Hard part: conflict resolution, not connectivity.
Booking, ordering, account management, loyalty. Judged against every other app on the phone, so the first-run experience and the login flow carry more weight than any feature list.
Hard part: earning the second session.
A mobile surface onto your existing platform — approvals, dashboards, alerts, quick capture. Cheapest of the three, because the backend and the rules already exist.
Hard part: an API that was never designed for mobile.
We recommend cross-platform for around 70% of business apps. Here is exactly where that recommendation flips, including the cases where it costs you more.
| Criterion | Flutter / React Native | Native Swift & Kotlin |
|---|---|---|
| Cost for both platforms | One codebase — roughly 60–70% of the native cost | Two codebases, two release cycles, two sets of bugs |
| Standard business UI | Indistinguishable to users in practice | Marginally better, rarely worth the difference |
| Continuous background location | Fights the platform; battery and reliability suffer | The correct choice — full control of background modes |
| Bluetooth / hardware peripherals | Plugin quality is the risk you inherit | Direct access, predictable behaviour |
| Heavy camera or on-device ML | Workable with native modules | Better performance and thermal behaviour |
| CarPlay, Android Auto, watch apps | Native code required regardless | Native from the start avoids a hybrid mess |
| Speed to first release | Typically 3–5 weeks faster to both stores | Slower, unless you only need one platform |
| Long-term maintenance | One upgrade path, occasional plugin churn | Two upgrade paths, but fewer surprises |
Scroll the table sideways to compare both columns.
Flutter when the app is forms, lists, maps, capture and payments — which is most business software. React Native when you already have a React web team, because they can review and eventually own the code. Native when the app depends on the phone being a piece of hardware rather than a screen: tracking a vehicle for eight hours, pairing to a scanner, or running the camera continuously. In that last case we'll quote you the more expensive option and explain why, rather than shipping something that drains a battery by lunchtime.
Store submission is a small task that goes badly when it's left to the last week. We start it in the middle of the build.
Apple Developer Program enrolment can take several days and, for organisations, requires a D-U-N-S number that occasionally takes longer. We start it immediately rather than discovering the delay at launch. Both accounts stay yours — we're added as members, not owners.
We push a skeleton build through TestFlight and Play internal testing in the first month. It catches the things that get first submissions rejected — a missing privacy manifest, an unexplained permission, a login screen with no demo account for the reviewer — while there's still time.
Apple's privacy nutrition labels and Google's Data Safety form require declaring every SDK that touches user data. We audit the actual dependency tree rather than filling the form from memory, because an inaccurate declaration is grounds for removal later.
TestFlight and Play testing tracks with a group of your actual staff or customers, on their own handsets. This is where the $120 Android phone with 4GB of RAM finds the performance problem that no simulator will.
Google Play staged rollout at 10%, watching crash-free rate before opening further. Sentry or Firebase Crashlytics wired in from the first build, so a regression is visible within hours rather than in a one-star review a fortnight later.
Clients quote for "an app" and mean an app, a database, an API, an admin panel, push infrastructure and a reporting view. The mobile client is often the smaller half of the work.
How we handle it: the estimate splits mobile from backend explicitly, so you can see both numbers and decide whether an existing system can serve the app instead.
Built and reviewed on a current iPhone; deployed to warehouse staff on four-year-old Android handsets with a cracked screen and 2GB of usable RAM.
How we handle it: we ask for the actual device inventory in week one and test on the worst device in it, not the best. If you don't know what your team carries, finding out is the first task.
"It should work offline" is a sentence that hides a week of decisions. What happens when two people edit the same job while both are offline? Whose version wins, and does the loser find out?
How we handle it: conflict rules are agreed in writing during design, per entity, with you — not decided by whichever engineer implements the sync loop.
Apple and Google both force SDK and target-API updates roughly yearly. Miss one and you can't ship updates at all until it's done — usually discovered when an urgent fix is needed.
How we handle it: OS compatibility work is inside the AMC retainer, scheduled ahead of the deadline rather than quoted as an emergency.
One platform or both is the first fork, and usually the biggest. After that: whether the app has to work offline with agreed conflict rules, and whether the backend already exists or has to be built alongside it. The backend is usually the larger half and the part clients forget to budget for — an app with nothing behind it is a form. We price it after a paid discovery, and you leave with a written fixed estimate that splits mobile from backend and a specification you own, whether or not you build it with us.
Flutter or React Native for roughly 70% of business apps: one codebase, both platforms, near-native feel. Native Swift or Kotlin when the app depends on hardware or background behaviour — continuous location tracking, Bluetooth peripherals, CarPlay or Android Auto, heavy camera work. We recommend against cross-platform in those cases even though it costs you more.
Ten to eighteen weeks to the first store release. Add two to three weeks for offline synchronisation, and one to two for the store review cycle. Apple review is typically 24–48 hours now, but a first submission rejected on a metadata or privacy issue can cost a week — which is why we submit a test build early.
Yes — listings, screenshots, privacy nutrition labels, data safety declarations, age ratings, TestFlight and Play testing tracks, and the review responses if something is rejected. We publish under your developer accounts, not ours, so the app and its reviews always belong to you.
Yes, and for field, driver and warehouse apps it isn't optional. We build a local database with a sync queue, conflict resolution rules agreed with you in advance, and clear in-app state so a user knows what has synced. The hard question is never storage — it's what happens when two people edited the same record while both were offline.
You own both. Source and IP transfer on payment, and the app is published under your Apple Developer and Google Play accounts from the first build. If we part ways, nothing needs migrating and no app has to be re-listed under a new publisher — which would reset your reviews and rankings.
Both platforms force an SDK or target-API update roughly annually, and an app that misses one stops accepting updates. That maintenance is real and continuous, which is why our AMC retainers include OS compatibility work, dependency upgrades and store policy changes rather than treating each one as a new project.
Yes. We audit the codebase, dependency health, build pipeline and store account state first, then hand you a written plan. The most common blocker isn't code — it's that the previous developer owns the signing keys or the Play listing, which we help you recover before any work starts.
Those two answers decide native versus cross-platform, the offline strategy and half the budget. An engineer replies within one business day with a recommendation and a range.