Mobile Application Development for Gardeners
Gardener app — intersection of several technical domains: plant and disease recognition via CV models, local scheduled watering notifications, geolocation for weather data, offline mode (dacha often lacks internet). None of these components complex alone — complexity in correct integration of everything.
Plant and Disease Recognition
Central feature everyone wants. Two paths: own CoreML/TFLite model or third-party service API.
Plant.id API and PlantNet API — most mature options. Plant.id returns not only name but diseases with confidence score and treatment recommendations. Standard integration: photo encoded to base64, sent via POST, response contains suggestions with probability. Important: Plant.id requires well-lit leaf or flower photo — wide shot gives low accuracy. Need early user training on what to photograph.
struct PlantIdentificationRequest: Encodable {
let images: [String] // base64
let modifiers: [String] // ["crops_fast", "similar_images"]
let plant_language: String // "ru"
let plant_details: [String] // ["common_names", "url", "description", "treatment"]
}
On-device variant via CoreML: models from iNaturalist (open database) or trained on PlantVillage dataset (leaf diseases — 54,000 images, 38 classes). Lower accuracy than cloud, but completely offline.
Watering Schedule and Notifications
Sounds simple — practice main mistake: developers set UNUserNotificationCenter notifications with fixed time and wonder why users complain about missed watering. Problem — notifications don't recalculate when rainfall changes.
Correct logic: every morning request weather forecast (OpenWeatherMap API or Apple WeatherKit), if rain > 5mm forecast — skip watering and cancel notification via UNUserNotificationCenter.removePendingNotificationRequests. Requires BGAppRefreshTask (iOS) or WorkManager (Android) for morning background task.
On Android WorkManager with PeriodicWorkRequest and NetworkType.CONNECTED constraint — correct solution. Not direct AlarmManager — Android 12+ requires SCHEDULE_EXACT_ALARM permission users won't grant.
Offline and Plant Database
Local plant database (name, description, care rules, planting calendar) stored in SQLite. For 500–1,000 records — Room on Android, Core Data or GRDB on iOS. Plant images — cached on first view with LRU policy (Kingfisher on iOS, Coil on Android).
Dacha without internet — real scenario. All basic functions (add plant, view tips, set reminders) must work offline. Sync on connection restore — via queue of deferred operations.
Weather Integration
OpenWeatherMap — standard for such apps, Free tier covers up to 1,000 requests daily. WeatherKit on iOS (iOS 16+) — more accurate and doesn't require own key, but only Apple platforms.
For garden app important not just temperature but humidity, uvi (UV index), rain (precipitation per 1 and 3 hours) — these fields available in current OWM endpoint.
Implementation Process
Define feature set: which plants (vegetables only or garden + houseplants), need social component (tip sharing, community), require offline disease database. Strongly affects scope.
Development: offline database → adding plants → watering schedule with notifications → weather integration → recognition. Recognition last because API keys and billing require separate agreement.
Timeline Estimates
App with plant database, watering schedule and weather — 5–7 weeks. With plant/disease recognition and offline mode — 9–12 weeks.