ERP Mobile App Development for Android and iOS

Field apps, not consumer apps

The mobile work we do is for people holding a phone in a quarry pit, on a crusher yard, at a site gate or halfway up a half-built structure. They are wearing gloves, the screen is in direct sunlight, and the nearest tower is a long way off. That environment decides almost every design choice: large targets, few taps per record, no dependence on a spinner resolving.

This is enterprise mobile app development rather than app-store product design. Nobody is being persuaded to install it. The measure of success is whether a weighbridge operator or a site engineer can finish a record faster on the phone than on the paper slip it replaces.

Offline-first is the requirement, not a nice-to-have

Every app we build for the field writes to a local SQLite store first and treats the server as something that may or may not be reachable. Records are queued, given a device-side identity, and pushed when the connection returns. Conflicts are resolved against explicit rules agreed during design — last-write-wins is almost never the correct answer for a billing document.

The Offline Weighment Billing App is the clearest case: it raises a weighbridge ticket with no connectivity at all, prints or shares it, and reconciles into the ERP later. If that had needed a signal, the plant would have gone back to the slip book within a week.

Apps we have already shipped

• SyvaSoft Dashboard — an MIS and dashboard app for iDempiere ERP, giving owners and managers production, dispatch and outstanding figures from wherever they are. Published on the Apple App Store.
• ConsTrak EDC — electronic data capture for construction sites.
• Offline Weighment Billing App — weighbridge ticketing with no connectivity, synchronised on reconnect.
• Wheel Loader Mobile App — loading records captured by the operator in the yard.
• Security Guard Mobile Application — gate verification and vehicle movement capture.
• Site Engineer App, part of ConstrakERP360 — measured work, material consumption and machine hours logged from site.

What goes into an app besides the forms

Role-based access, so a guard, a loader operator and a general manager open the same build and see different things. Camera capture with the photograph geotagged and timestamped at the point of capture, because a photograph without coordinates settles no argument later. GPS for trip and route records. Barcode and QR scanning for vehicles, bins, tickets and material. Push notifications for approvals and exceptions. Biometric login using the device's own fingerprint or face unlock, which is what stops shared handsets turning into shared accounts.

Integration is where the time goes

The app is the visible part. Behind it sits a REST API layer against iDempiere, ERPNext or whatever system is already in place, with authentication, pagination, incremental sync endpoints and a sync log you can read when a device claims it uploaded something. We build that layer as an upgrade-safe extension of the ERP rather than by editing core source, for the same reason we do it on every other engagement.

Publishing and ownership

Apps go to Google Play and the Apple App Store under the client's own developer account. We set the account up, prepare the listings, handle review responses and hand back the keystore and signing credentials. Source code is delivered with the project. An app you cannot rebuild without the original vendor is a liability rather than an asset.