Mobile App Development for Smart Agriculture

We encounter fields of 100 hectares—not apartments with smart light bulbs. Sensors scattered over kilometers, GSM connectivity not everywhere, battery replacement once a year is a requirement, not a wish. A mobile app for agri-IoT is built around several real constraints: low connectivity, long data cycles (every 15–60 minutes from a LoRaWAN node), high cost of error (lost harvest). With 10+ years in agri-development, we have accumulated experience that guarantees a reliable turnkey solution.

Which communication protocols are suitable for agri-IoT?

LoRaWAN is the main protocol for field sensors over large areas. Range up to 15 km in open field, power consumption in milliwatts, packets 51–222 bytes depending on Spreading Factor. LPWAN alternatives: NB-IoT (requires carrier network, but two-way communication), Sigfox (limit of 140 messages per day).

For greenhouses and facilities with infrastructure — Zigbee/Thread, Wi-Fi, wired Modbus. For mobile assets (machinery, animals) — GPRS/LTE with GPS tracker.

Data from LoRaWAN nodes goes through Network Server (TTN, ChirpStack, Helium) → Application Server → MQTT or REST → mobile app.

Data architecture: rare updates, rich analytics

A LoRaWAN sensor updates data every 15–60 minutes. The mobile app shows not only current values but also trends, anomalies, predictions. This requires server-side aggregation and storage in a Time Series DB.

Data structure for a soil sensor:

{ "deviceEui": "0004A30B001C3A4D", "applicationId": "crop-monitoring-prod", "timestamp": "2024-07-15T08:30:00Z", "location": {"lat": 51.2345, "lon": 23.4567}, "payload": { "soilMoistureVwc": 28.5, "soilTemperatureC": 18.2, "soilElectricalConductivity": 0.45, "batteryPercent": 87, "signalRssi": -98, "snr": 4.2 } } 

On the mobile side — Kotlin Flow with RoomDB for offline work:

@Dao interface SensorReadingDao { @Insert(onConflict = OnConflictStrategy.REPLACE) suspend fun insertAll(readings: List<SensorReading>) @Query(""" SELECT * FROM sensor_readings WHERE device_eui = :eui AND timestamp >= :from ORDER BY timestamp DESC """) fun observeReadings(eui: String, from: Long): Flow<List<SensorReading>> @Query(""" SELECT CAST(strftime('%s', datetime(timestamp/1000, 'unixepoch', 'start of day')) AS INTEGER) * 1000 AS day, AVG(soil_moisture_vwc) AS avg_moisture, MIN(soil_temperature_c) AS min_temp, MAX(soil_temperature_c) AS max_temp FROM sensor_readings WHERE device_eui = :eui AND timestamp >= :from GROUP BY day ORDER BY day """) fun getDailyAggregates(eui: String, from: Long): Flow<List<DailyAggregate>> } 

Field map and zonal management

A key screen in the agri-app is a map with field polygons and sensor markers. Using Flutter with flutter_map (Leaflet-based, free without API key) or Google Maps:

class FieldMapWidget extends StatelessWidget { final List<Field> fields; final List<SensorDevice> sensors; @override Widget build(BuildContext context) { return FlutterMap( options: MapOptions(center: LatLng(51.23, 23.45), zoom: 13), children: [ TileLayer( urlTemplate: 'https://tile.openstreetmap.org/{z}/{x}/{y}.png', // Or agri-layers: Sentinel-2 NDVI via EO Browser ), PolygonLayer( polygons: fields.map((f) => Polygon( points: f.boundary, color: _fieldColorByStatus(f), borderColor: Colors.white, borderStrokeWidth: 1.5, )).toList(), ), MarkerLayer( markers: sensors.map((s) => Marker( point: LatLng(s.lat, s.lon), builder: (_) => SensorMarker(sensor: s), )).toList(), ), ], ); } Color _fieldColorByStatus(Field field) { final ndvi = field.latestNdvi; if (ndvi == null) return Colors.grey.withOpacity(0.3); if (ndvi < 0.3) return Colors.red.withOpacity(0.4); if (ndvi < 0.5) return Colors.yellow.withOpacity(0.4); return Colors.green.withOpacity(0.4); } } 

NDVI (Normalized Difference Vegetation Index) is obtained from Sentinel-2 imagery via the Copernicus Data Space API or Planet API. Images every 5–12 days under cloudless conditions — automatically downloaded on the backend and calculated pixel by pixel.

How to ensure offline mode for field sensors?

A LoRaWAN gateway in the field may not have constant internet access. Some data is synced in batches when connectivity appears. The app shows “last update 2 hours ago” and doesn’t panic. It is critical to handle timestamps correctly: the sensor data has its own timestamp, which may differ significantly from the delivery time to the server.

For offline work, we use local storage with synchronization via background tasks. On iOS — Background Fetch, on Android — WorkManager. Conflicts are resolved by the “newer timestamp wins” principle.

Notifications for agri-thresholds

For agri-IoT, threshold alerts are critical: “Soil moisture below 25% on field North-3” or “Frost expected by 04:00, 3 sensors show temperature below 2°C”. Logic on the backend, delivery via FCM/APNs.

Nuance of mobile notifications for farmers: the phone is often in the pocket during work, so concise informative texts without unnecessary words are needed. The first line of the notification should be the main point: “Field East: humidity 18%, need irrigation”.

What is included in the work?

• Audit of sensor fleet and agronomic requirements.
• Architecture design: server side, mobile app, integrations.
• Turnkey implementation: iOS (Swift, SwiftUI) and Android (Kotlin, Jetpack Compose) or cross-platform (Flutter/React Native).
• Integration with LoRaWAN network, MQTT, REST API.
• Development of field map with NDVI layers.
• Configuration of threshold notifications.
• Testing and deployment to App Store and Google Play.
• Training for agronomists and technical support.

We use LoRaWAN and NDVI — proven industry standards.

Development timelines

Cost is calculated individually after analyzing your sensors and tasks. Consult us to discuss your project details.

Our engineers are certified in mobile development and agri-IoT. With 10+ years, we have completed 50+ projects for agriculture. Contact us — we'll help turn data into harvest.