The first version of a cross-platform app is easy, and every demo looks the same. The cost arrives later: the capability with no maintained plugin, the background rule each OS enforces differently, the store review that objects to something the framework made convenient, and the second year when nobody upgraded. We build for that year from the first week.
30 minutes, working session. You leave with a one-page read of your app either way. Nobody follows up more than once.
A national epidemic control platform — the travel-health app of a public-health programme in the Caribbean, live in both public stores. Case →
None of these mean the framework was the wrong choice. They are what happens when nobody owned the parts that are not the UI.
Nothing has shipped in five months
A rejection nobody had time to resolve, then a framework upgrade nobody scheduled, then a certificate that expired. The release stopped being a routine and became a project.
It works until the signal goes
On a train, in a lift, in a basement. The app hangs on a spinner or quietly loses what the user typed, because offline was a state nobody designed.
The plugin is abandoned
The one that does the thing your product depends on. Last commit two years ago, an open issue matching your crash exactly, and a maintainer who has moved on.
The crash rate is unknown
No monitoring, or monitoring nobody reads. The team hears about problems through store reviews — the slowest and most public channel available.
September broke something
A new OS, a changed background rule or a tightened permission, and a behaviour that worked for two years stops. Nobody was testing against the beta.
Two codebases appeared anyway
Enough platform branching that the one codebase is now two, interleaved in the same files, with nobody able to say which platform a given change affects.
Each links to its own case page.
The Qatar Ministry of Foreign Affairs’ official app, built in Flutter and shipped on iOS and Android. The hard part is the gates: a government review process, a national brand, and Apple’s and Google’s own review — all before a single user opens it. Cross-platform work rarely has to pass three reviewers who each have a different definition of wrong.
LIVE IN PRODUCTION — BOTH PUBLIC STORES
A Flutter app that turns a photo taken at an event into an enriched contact, with AI follow-ups, CRM export and an offline mode. Camera, GPS and Bluetooth are ours: written in Swift and Kotlin and maintained by us rather than depended on from a stranger’s repository. Venue Wi-Fi is usually the first thing to fail, so the capture path has to behave when it does.
Desk, room and locker booking over live IoT data, with a chatbot and a survey engine. The hard part is trust: the moment the app shows a desk as free that somebody is sitting at, nobody opens it again. That makes the sync path the product, not a detail.
A social-scheduling platform architected and led from zero to mass adoption, then expanded into native mobile apps, an AR experience, Amazon TV and Alexa, and Apple Watch. The hard part is surface sprawl: five interaction models over one set of business rules that must not fork.
Testing a live build during a client visit in New York. An app that is only ever run in a simulator finds its problems at store review; one that ships to TestFlight and Play internal testing every week finds them while they are still cheap. More about how we work →
Offline is a design decision, not a library. Switch the network off, keep using the app, then switch it back on. Everything queues honestly — and one of these actions will come back to a world that changed while you were gone.
Everything is synced. This is the only state most demos ever show.
Last-write-wins would have resolved that conflict silently, and one of two people would have arrived to a desk somebody else was sitting at. Queued mutations that survive a cold start, a sync path with real conflict resolution, and a UI that says pending rather than pretending — that is the difference between an app that works on a train and one that only works in the office.
Naming this is the whole point. If a requirement below is yours, the honest answer is native for that piece — and going native for one screen is almost always the answer before going native for the app.
The Ministry’s application, built in Flutter and live on both platforms. Right-to-left layout, accessibility that is checked rather than assumed, and a release that had to satisfy a government process before it ever reached Apple or Google. Qatar MoFA case →
Timelines are indicative ranges and depend on scope.
Flutter, React Native or native, argued from your requirements — offline behaviour, hardware access, team skills, three-year maintenance cost — with the conditions that would change the answer. You keep the document either way.
Architecture signed off before code, navigation and auth first, weekly installable builds from the second week so nobody is judging progress from a screenshot.
A written state-of-the-app read first: dependency and framework debt, what store review will object to, what the crash data says. Then stabilise, then release.
Local storage, queued mutations that survive a cold start, sync with real conflict resolution, and UI states that are honest about what is pending.
CI to TestFlight and Play internal testing, signing and provisioning, staged rollout, crash and performance monitoring wired in before launch, and a forced-update strategy decided in advance.
When the plugin does not exist or has been abandoned, we write the native side ourselves — as we do for camera, GPS and Bluetooth in Swift and Kotlin — and maintain it rather than depending on a stranger’s repository.
If your requirements have outgrown cross-platform, we say so and scope the native work — including the option of going native for one screen rather than the whole app.
Two majors behind is the normal state of a shipped app. We read what upgrading costs and what breaks — including what moving to React Native’s new architecture would mean for your codebase — then stage it across releases rather than attempting it in one.
One page, 15 questions about your mobile app you should be able to answer before your next release — when the last submission actually succeeded, what your crash-free session rate is and who reads it, what happens to a queued action on a cold start, which permissions you request without a visible reason, how far behind the framework has fallen, and who holds the signing certificates.
A free 30-minute working session, not a sales call. We tell you which of your requirements is the binding constraint and whether cross-platform is still the right answer. You keep a one-page read either way: the framework recommendation with its conditions, the store-review risks we would fix first, and the one offline behaviour we would design before anything else.
A senior software engineering team that uses AI as an industrial-grade tool — advanced Claude Code workflows in experienced hands.
