Mobile applications

What you get

Native apps on both platforms that read and write the same data as your web product, released on the same weekly cadence.

How it works

The phones talk to the same API gateway the website uses. Authentication, database, notifications and storage are shared services, so a change to a rule applies everywhere at once.

What we measure

Crash-free sessions, cold start time, push delivery latency, and the size of the offline queue when connectivity is poor.

Native, or cross-platform

This is the first real decision, and it is worth making on the product rather than on preference.

Native Swift and Kotlin give you the platform the day it ships: a new iOS control, a new permissions model, a widget, a watch app. They cost two codebases for the screens, though the web application behind them — API, data model and business rules — stays shared, and that is most of the work on a serious app.

Cross-platform is the right call when the app is mostly forms, lists and content over an API, when the team maintaining it is small, and when looking exactly like the platform matters less than shipping both at once.

What drives the decision in practice is usually hardware and background behaviour. Bluetooth, continuous location, camera pipelines, background audio and anything that must keep running with the screen off are where cross-platform frameworks get expensive — not impossible, but you spend the saving back in native modules and platform bugs.

Offline is a product decision

"Works offline" means very little until someone decides what happens when two people change the same thing on two phones.

Read-only caching is cheap: hold the last response, show it with a timestamp, refresh when the network returns. Offline writes are a different build. They need a queue that survives the app being killed, idempotent requests so a retry cannot create the record twice, and a rule for conflicts — last write wins, server wins, or ask the user. We will push for that rule to be decided by you, early, because it is a business question wearing a technical costume.

What the stores add

Release is not a deploy. Review takes days and can reject a build for reasons that have nothing to do with the code, so the calendar has to allow for it. Both stores require a privacy declaration that matches what the app actually collects, and getting that wrong is a rejection and a resubmission.

Signing keys and store accounts belong to you, registered in your name, not ours. An app you cannot update without us is not an app you own.