Apps that work where the network does not

Retrofitting offline support onto an app that assumed connectivity is one of the most expensive rewrites in mobile development, because it touches every screen and every data path. So we decide it at the start.

The pattern we use: a local database on the device is the single source of truth the interface reads from. Every user action writes locally first and enqueues a sync operation. A background worker drains that queue when connectivity allows, with exponential backoff, and conflicts are resolved by an explicit rule agreed with the client — last-write-wins for simple attributes, server-authoritative for anything financial, and a user-facing merge prompt where a genuine judgement is needed.

The user experience of this is that the app simply never blocks. A field engineer completes an inspection in a basement, walks out, and the record uploads without them thinking about it. The interface shows a small, honest sync indicator rather than a spinner and an error.

We test on a rack of real handsets that reflects the Indian installed base — mid-range Android devices from the last four years, not just the newest flagship. A list that is smooth on a Pixel and janky on a ₹12,000 Android phone is a broken list, because most of your users are on the second one.

The recurring performance issues are predictable: over-rendering lists that lack proper virtualisation and key stability, images loaded at full resolution into small thumbnails, heavy work on the JavaScript thread during scroll, and animations driven from JavaScript instead of the native driver. Each has a known fix, and we profile rather than guess — a frame-timing trace tells you exactly which component is costing you frames.

App size matters more than teams expect in markets where storage is scarce and data costs money. We keep release builds lean through code splitting, asset optimisation, ProGuard/R8 shrinking on Android and careful dependency review. An app under 25 MB gets installed and kept; one over 90 MB gets uninstalled when the phone runs out of space.

Teams that cannot release reliably stop releasing, and a mobile product that stops shipping starts dying. So we set up the pipeline in week one, before the first feature.

Every merge produces a build. Internal testers get it automatically through TestFlight and the Play internal track. Release candidates go to a closed group, then to a staged rollout — five per cent, twenty-five, fifty, one hundred — with crash rate and key funnel metrics watched at each gate, and an automatic halt if crash-free sessions drop below a threshold. Over-the-air updates handle anything that does not touch native code, so an urgent fix reaches users the same day.

We also handle the unglamorous store work: listings, screenshots at every required size, privacy declarations, data-safety forms, review responses and the periodic policy changes that Google and Apple issue with little notice. Getting rejected twice on a compliance detail costs a fortnight, and it is entirely avoidable with a checklist.

A phone can be lost, shared, rooted or handed to a colleague. We design assuming all of those happen. Credentials live in the platform keychain or keystore, never in plain preferences. Sensitive local data is encrypted at rest. Sessions expire and can be revoked centrally when a device is reported lost. Certificate pinning protects against interception on hostile networks. Screenshots are blocked on screens showing regulated information where policy requires it.

For applications handling personal data we implement consent capture, data-minimisation in what the app stores locally, and a working delete path — increasingly a legal requirement under India's data protection framework and a straightforward thing to build if designed in rather than bolted on.

Field force applications dominate: attendance with geofencing, task and beat plans, order capture with offline price lists, photographic proof of visit, expense claims and reporting. These typically replace a WhatsApp-and-Excel process and pay for themselves in recovered hours within a year.

Dealer and distributor apps come next: catalogue, scheme visibility, order placement against credit limits, dispatch tracking, ledger and statements. The commercial value is usually in the reduction of order-entry labour and pricing errors rather than in new sales.

Then customer-facing apps where genuine repeat usage justifies an install — loyalty, subscriptions, service booking, patient records. We are honest about this one: if your customers will open the app twice a year, a fast mobile website serves them better and costs a fraction. We have talked several clients out of an app for exactly this reason.

An app is rarely valuable alone; it is valuable because it puts your ERP, CRM or plant data into someone's hand at the moment they need it. We integrate with Tally, SAP, Oracle, Zoho, Salesforce, custom ERPs and plant historians, usually through a thin API layer we build in front of the legacy system so the app never depends on its quirks directly.

That layer also gives us somewhere to put caching, rate limiting, field-level authorisation and audit logging — none of which the legacy system will offer, and all of which you need when a hundred devices start calling it every few minutes.