Field, service and driver teams lose connectivity: in basements, in car parks, out in the country. An app that does not plan for that fails exactly when it is needed.
We build native iOS apps, cross-platform apps and installable web applications, and connect them to ERP, order systems or your own backend. Which route is cheaper depends on the requirement, not the trend.
Three decisions before the first line of code
The cost does not come from building. It comes from three decisions made casually at the start and paid for permanently afterwards.
Offline-first is an architecture decision, not a buffer added later. The hard problem is not storing but reconciling: who wins when two devices changed the same job offline?
The most expensive line item is rarely the build. It is maintaining two separate codebases forever. Whether that pays off depends on camera, sensors, background work and offline requirements.
Most companies do not need a store listing, they need a mobile process. An installable web app often delivers that faster and without review cycles.
Four areas of work that real projects have shown to be the load-bearing ones.
Job data, photos, signatures and status updates work without a connection and reconcile as soon as the network returns.
When camera, sensors, background processing or deep system integration matter, native is the more honest answer.
React Native or an installable web app, when both platforms need the same functionality and two codebases do not pay for themselves.
A mobile app rarely stands alone. It hangs off inventory, order systems, maps and payments.
Four steps in which the platform decision does not come first, but right after the first question.
01
We first establish what actually has to happen on a phone and where connectivity fails. Only then is the platform question answerable at all.
02
Native, cross-platform or web is recorded with its reasoning and its follow-on costs, so the decision stays reviewable later.
03
Testing happens on real devices with real connection loss, not only in a simulator on stable Wi-Fi.
04
OS updates, review cycles and field defects are part of the product, not an afterthought.
Documented work
Native, cross-platform or both. The notes below describe shipped functionality, not a roadmap.
Native iOS and macOS app with SwiftUI, Swift, StoreKit and camera integration. Published on the App Store.
React Native for iOS alongside a Next.js web application, Firebase and push notifications.
Web and native iOS in one product: Node.js, PostgreSQL, Swift, Apple Maps and Stripe.
iOS with Swift and Android with Kotlin, plus SUNMI point-of-sale hardware and Stripe Connect.
A mobile project is not always worth it. This comparison saves both sides a conversation.
A flat figure would be dishonest, because the same number of screens can mean very different amounts of work. The cost drivers are the offline requirement, how many platforms, the integrations and the ongoing store operation. We would rather cut a small first scope that answers a real question than quote a number that will not hold.
Four questions decide it: do you need camera, sensors or background processing? Does the app have to work without a network? Is a store listing actually required or merely wanted? And is there someone to maintain two codebases permanently? Only after those is the answer a decision rather than a preference.
That jobs, photos, signatures and status changes are captured without a connection and reconcile later without silently overwriting data. The user can see what has not been transmitted yet. The hard part is not local storage but the rule that decides who wins a conflict.
Yes, including review rounds and the usual questions about permissions, privacy declarations and test accounts. A store review can reject a version; that is part of the process and is planned for rather than treated as a surprise.
OS updates, changed store policies and field defects generate continuous work. Skip that and after a year you have an app that no longer launches on new devices. We settle operations before launch, not after.
Describe the workflow that should work on a phone. We will tell you whether it needs a native app or whether there is a cheaper way.