Field Service Mobile App Development
A field technician arrives at a customer's site, opens the app — and sees a blank screen because there's no cellular coverage. Service tickets, equipment history, inspection checklists — everything is frozen. This is where most Field Service apps break: they're built as standard CRUD over REST API without treating offline mode as a first-class scenario.
Key Technical Challenges
Offline-first synchronization. Field workers operate in warehouses, basements, industrial zones — coverage is unstable. You need bidirectional sync queues: user actions are saved locally (SQLite via Room or CoreData), then synchronized when network appears. Version conflicts are the most painful point. If two technicians simultaneously close the same ticket offline, you need a merge strategy. Usually we apply "last-write-wins" with operation logs or CRDTs for certain data types (e.g., comments — append-only).
Photos and media. Work completion reports require "before" and "after" photos. On Android, WorkManager with Constraints.Builder().setRequiredNetworkType(NetworkType.CONNECTED) is the standard way for deferred uploads. But here's the catch: WorkManager doesn't guarantee task execution order on batch uploads. If photo order is critical — number them in the filename and handle this on the server.
On-screen signatures. Canvas API (Android View.onDraw with Path, iOS UIBezierPath via CAShapeLayer) for capturing customer signatures is straightforward until you need high-quality PDF export. Use iText (Android) or PDFKit (iOS) to generate reports directly on the device.
Maps and Routing
The dispatcher sees all field employees on a real-time map — this is WebSocket or MQTT from a broker (mosquitto / EMQX) to the mobile client. Send coordinates in batches every 30 seconds via FusedLocationProviderClient (Android) or CLLocationManager with desiredAccuracy: kCLLocationAccuracyNearestTenMeters (iOS) — not every second to avoid draining battery.
Optimal routing between 10–15 tickets daily is a Travelling Salesman problem that you don't solve on the mobile client. The server does the optimization (Google OR-Tools, Vroom), the mobile app just displays the ready route via Google Maps SDK or MapKit with turn-by-turn navigation via deep link to Maps/Google Maps.
Stack and Architecture
For Field Service apps with a single codebase for iOS and Android, choose Flutter or React Native with Expo. Flutter is preferable when there are requirements for custom widgets (custom equipment inspection forms, drag-and-drop for ticket items). React Native — if the client's team will maintain the code and has JavaScript background.
Architecture: MVVM + Repository pattern. Local database — SQLite (sqflite for Flutter, Room for native Android). Sync layer — separate service that doesn't mix with business logic.
From Practice
Vending machine maintenance app: ~200 technicians, each with 8–15 locations daily. Main mistake in the first version — synchronization triggered on every user action via direct HTTP request. With poor network, the technician would wait 30 seconds after closing each item. We rewrote it with an operation queue (SQLite pending_operations table + WorkManager) — technician works instantly, sync happens in background. Complaints about "app is slow" dropped to zero.
Development Stages
- Audit of existing system (ERP, CRM, dispatch module) — understand what you'll synchronize with
- Design offline data model and conflict resolution strategy
- UI design considering use with gloves and bright sunlight (contrast, large buttons)
- Development and phased integration with backend
- Pilot with a group of technicians (10–20 people) before full rollout
- Publication to App Store and Google Play with MDM profile for corporate devices
Timeline: 6 weeks for simple app (tickets and checklists) to 4–6 months for full platform with dispatch module, routing, and ERP integration. Cost calculated individually after requirements analysis.