Mobile App Development

The mobile apps we build are for people standing up: an inspector on a construction site, a welder at a fabrication station, a technician behind a repair counter. Those places have weak signal or none, gloves on hands, and no patience for a spinner. So we build offline-first. The app keeps its own copy of the data it needs and syncs with the server when it can, instead of treating every lost connection as an error.

To be upfront: our default is a Progressive Web App built with React, not separate Swift and Kotlin codebases. One codebase installs on Android, iPhone and desktop, and for Android we package it as a store-ready app when you want a Play Store listing. For most business apps that's the better trade. If yours needs deep native features, we'll say so early.

Who this is for

Teams whose work happens outside the office and whose data can't wait for Wi-Fi: field inspection, quality control, shop-floor tracking, maintenance and service, retail counters, sales visits. Also companies that already have a web system and want a phone-friendly version that keeps working in a basement or a steel hall.

How we work

1. See where it's used. We start with how the app is used on a normal day: which device, what connection, how many taps before the user gives up. This changes design more than any feature list.
2. Decide what works offline. Not everything needs to. We pick which data lives on the device, which actions can be queued, and how conflicts are resolved when two people edit the same record.
3. Build on the real stack. Service worker caching for the app shell, local storage (IndexedDB or SQLite in the browser) for data, and a sync layer back to the API.
4. Test on real phones. We test with flight mode on, on cheap Android devices as well as new ones, and in both right-to-left and left-to-right layouts.
5. Pilot, then roll out. A small group uses it for real work first. Then we publish: install from the browser, an Android package, or both.

The stack we actually use

Frontends are React with TypeScript, on Next.js or Vite. For offline caching we use service workers through Serwist or vite-plugin-pwa. When the app has to write data offline and sync it back, we use PowerSync, which keeps a local SQLite database on the device in sync with PostgreSQL on the server. Backends are FastAPI. For Android we use Trusted Web Activity packaging, which gives a signed APK or AAB that opens the PWA full-screen with no browser bar.

Work you can look at

Probe361 puts inspection and welding standards (AWS, API, ASME, with Persian translations) on an inspector's phone. It caches pages for offline use, stores favorites locally in IndexedDB, sends push notifications, and ships to Android as a packaged app from the same codebase. Fidar MES runs shop-floor stations on PowerSync, so operators keep logging progress through network drops and everything syncs on reconnect. And Mobile Master, our repair-shop system, is installable on the counter tablet, with voice entry at the point of sale and public tracking links customers open on their own phones.

Further reading

• True offline vs fake offline in inspection apps
• Why shop-floor software still has to work offline

Frequently asked questions

Do you build native iOS and Android apps?

Our default is a PWA with one React codebase, packaged for Android when you want it in the Play Store. We don't maintain separate Swift and Kotlin codebases. If your app depends on features a PWA can't reach well, we'll tell you in the scoping call rather than half-build it.

Can the app really work with no internet?

Yes, for the parts we design to. The app shell is cached, the data the user needs is stored on the device, and changes wait in a local queue or database until the connection returns. Fidar's shop-floor stations and Probe361's saved standards both work this way.

What happens if two people edit the same record offline?

We decide that per data type before building. Some records take the last write, some keep both versions for review, and some actions are simply blocked offline because a conflict would be expensive. It's part of the design, not something we find out in production.

Can it be published on Google Play?

Yes. We package the PWA as a signed Android app (Trusted Web Activity), which is how Probe361 ships on Android. On iPhone, users install it from Safari with "Add to Home Screen".

Can we add a mobile app to our existing web system?

Usually. If your system has an API we can build the mobile front on top of it. If it doesn't, we can add a small API layer first.

How much does it cost?

It depends mostly on how much has to work offline and on sync rules, so we quote after the scoping call. There's no fixed price list.