Logistics Company Mobile App Development
A mobile app for logistics encompasses multiple roles simultaneously: field driver, warehouse manager, customer awaiting delivery, and office operator. Development starts not with code, but with mapping these roles and their intersection points — otherwise you get scattered screens instead of a unified system.
Order Management and Route Optimization
A logistics company processes dozens or hundreds of deliveries daily. The key driver problem is the optimal order to visit points. This is the Travelling Salesman Problem (TSP), solved for practical volumes using heuristics: nearest neighbor, 2-opt, or ready-made APIs.
Google Routes Optimization API (formerly Route Optimization AI) accepts a list of addresses and constraints (time windows, load capacity) and returns an optimized route. Google's OR-Tools is an open source library for server-side use. For small volumes (up to 20-30 points), calculation can be done on client; for larger volumes — a server service.
Delivery time windows are important business parameters. Customer ordered "between 2 PM and 4 PM." If the driver arrives at 5:30 PM — complaint. The routing algorithm must account for these windows and warn dispatchers of unrealistic schedules.
Barcode and QR Scanning
Delivery confirmation via scanning is standard in logistics. MLKit Barcode Scanning (Google, on-device) and Vision Framework (Apple, VNDetectBarcodesRequest) — faster and more accurate than Zxing. MLKit recognizes QR, Code128, EAN-13, DataMatrix without internet, critical for warehouses with poor coverage.
Integration: CameraX (Android) or AVCaptureSession (iOS) with continuous preview and targeting overlay. Important: auto-close preview after successful scan and vibration as tactile confirmation.
Inventory and Warehouse
Warehouse module — separate flow. Worker scans a box, sees its contents and status, can change location or mark damage. Offline operation is essential: warehouse may be in basement without LTE. Room (Android) / Core Data (iOS) as local storage with synchronization on network recovery via WorkManager / BackgroundTasks.
Sync conflicts — if two workers edited one item offline — need conflict resolution strategy: last-write-wins, or explicit conflict UI ("data changed on server, choose version").
Tracking and Customer App
Customer wants to see their package location right now. Either separate app or public web page with tracking by order number. For mobile customer app: map with courier marker, movement animation (interpolation like taxi passenger app), push notifications on status change.
Delivery status model: created → picked_up → in_transit → out_for_delivery → delivered / failed. Each transition — push notification. failed with reason and option to reschedule delivery.
Analytics and Reporting
Manager module: dashboard with KPIs — percentage of on-time deliveries, average time per point, delayed routes on heat map. Heatmap via Google Maps TileOverlay with custom tile provider or Mapbox HeatmapLayer. Data — aggregation from backend API, cached locally with TTL 5-10 minutes.
Stack and Architecture
Clean Architecture is mandatory with this complexity: different roles → different modules → common core. Flutter with modular structure (feature_core, feature_driver, feature_warehouse, feature_client) — each module compiles separately, accelerating builds and allowing teams to work in parallel.
Push: FCM for Android and APNs for iOS through unified backend (Firebase Admin SDK or Expo Notifications). Maps: Google Maps SDK or Mapbox, choice depends on client geography.
Phases: business process audit → role model → API design → parallel module development → integration → load testing → release.
Timeline: 16 to 28 weeks for complete logistics system. Cost calculated individually.