Ми часто зустрічаємо запити на погодний додаток — здавалося б, стандартна задача: взяти API, показати температуру та іконку. Але за роки розробки ми виявили підводні камені, які перетворюють простий проект на джерело проблем. Який провайдер даних точніший для конкретного регіону — Open-Meteo чи Яндекс Погода? Як зробити карту опадів, яка працює плавно на iPhone 7 без гальм? Як віджет на екрані оновлюється без drain батареї? І як сповіщення про град приходить за 10 хвилин, а не постфактум? Наш інженерний досвід підказує: правильна архітектура та вибір інструментів вирішують 80% проблем. Ми гарантуємо якість завдяки сертифікованим розробникам з досвідом понад 5 років.
Як вибрати провайдера для мобільного додатку погоди?
Вибір провайдера визначає точність, особливо за межами великих міст.
| Провайдер | Прогноз | Оновлення | Особливості |
|---|---|---|---|
| Open-Meteo | 16 днів | 1 год | Безкоштовно, open-source, хороша Європа/СНД |
| OpenWeatherMap | 8 днів | 3 год | Широке покриття, alertи |
| Tomorrow.io | 15 днів | 1 год | Minutecast, hyperlocal |
| Meteoblue | 7 днів | 3 год | Мезомасштабні моделі, гори |
| Яндекс Погода API | 7 днів | 1 год | Точніше для СНД |
Агрегація даних від кількох провайдерів підвищує точність прогнозу в 1.5–2 рази порівняно з одним джерелом. Open-Meteo — чудовий безкоштовний варіант для Європи. Кешування даних знижує навантаження на API в 10 разів порівняно із запитами при кожному відкритті — економія до 60% на трафіку.
На мобілі погодні дані кешуються локально — CoreData/Room для структурованих даних про погоду. TTL кешу: поточні умови — 10 хвилин, годинний прогноз — 1 година, 14-денний — 6 годин.
Чому важливе кешування в мобільному додатку для погоди?
Кешування знижує витрати на API приблизно на 40% та забезпечує автономну роботу віджета. На iOS WidgetKit використовує TimelineProvider для формування записів на кілька годин вперед, щоб віджет показував дані без інтернету. На Android GlanceAppWidgetManager працює через WorkManager.
Як реалізувати карту опадів без гальм?
Найбільш навантажена частина. Тайлові карти опадів — WMS або XYZ-тайли, що оновлюються кожні 5-10 хвилин.
На iOS: MapKit з MKTileOverlay — кастомний клас, який завантажує тайли за шаблоном URL https://tiles.provider.com/radar/{z}/{x}/{y}/{timestamp}.png. Анімація — цикл по масиву timestamps з CADisplayLink або Timer для зміни overlay'ів.
На Android: Mapbox або Google Maps з TileOverlay. Для анімації — змінюємо TileProvider джерело на кожен кадр з fade transition.
Проблема продуктивності: якщо завантажувати тайли по одному на кожен кадр анімації — мерехтіння. Правильно: preload всі кадри в background queue до старту анімації, зберігати в пам'яті NSCache/LruCache, крутити анімацію по готових. Ліміт попереднього завантаження: 6-10 кадрів × 9 видимих тайлів = ~100 тайлів, близько 5-10 МБ в пам'яті.
Оптимізація для старих пристроїв
Використовуємо PNG замість GIF, зменшуємо роздільну здатність тайлів, відключаємо анімацію при низькій продуктивності (визначається по `CADisplayLink.frameInterval`).Віджет домашнього екрану
Порівняємо реалізації для iOS та Android.
| Платформа | Фреймворк | Оновлення | Сховище даних |
|---|---|---|---|
| iOS | WidgetKit + TimelineProvider | Кожні 15–30 хв | App Groups + UserDefaults |
| Android | Glance (Jetpack) + WorkManager | За розкладом | SharedPreferences |
iOS: WidgetKit з TimelineProvider. Entry раз на 15-30 хвилин (система регулює сама). Віджет не може виконувати мережеві запити напряму — TimelineProvider запитує дані в getTimeline(in:completion:), формує масив TimelineEntry на кілька годин вперед. TimelineReloadPolicy.atEnd — перезавантаження після закінчення timeline.
SwiftUI-в'ю для віджета не підтримує жести окрім Link. Три розміри: .systemSmall, .systemMedium, .systemLarge — для кожного своя верстка.
Android: Glance (Jetpack) — Compose-подібний API для App Widgets. Оновлення через GlanceAppWidgetManager + WorkManager задача за розкладом.
Дані між основним додатком та віджетом: iOS — App Groups + UserDefaults(suiteName:). Android — SharedPreferences з провайдером.
Сповіщення про небезпечні явища
Push-сповіщення про град, шторм, ожеледицю — через серверний scheduler. Кожні N хвилин перевіряємо weather alerts від провайдера для всіх підписаних координат користувачів → якщо є новий alert → FCM/APNs. Пріоритет: high для критичних явищ (APNs apns-priority: 10, FCM priority: high).
Для негайних оповіщень (торнадо, екстрені сигнали) — UNNotificationContent з interruptionLevel: .critical (iOS 15+): проходить через режим «Не турбувати».
Геофенсинг для «мені важлива погода в поточному місці»: CLLocationManager.startMonitoringSignificantLocationChanges() — сповіщення при зміщенні на ~500м, без постійного GPS-трекінгу.
Що входить в роботу: покроковий процес
- Аналітика та прототип — визначаємо джерела даних, проектуємо архітектуру кешування.
- Проектування — вибір провайдерів, налаштування API, конфігурація віджета.
- Реалізація — розробка iOS та Android версій, інтеграція карти опадів та сповіщень.
- Тестування — навантажувальне тестування карти, перевірка точності даних.
- Деплой — публікація в App Store та Google Play, налаштування моніторингу.
Ми здаємо проект під ключ: документація по архітектурі, вихідний код з коментарями, інструкції по деплою, доступи до серверної частини, а також підтримка протягом місяця після запуску. Ви отримуєте готове рішення, яке легко підтримувати та масштабувати.
Строки
Базовий погодний додаток (поточні умови, 7-денний прогноз, віджет) — 2-4 тижні. З картою опадів, сповіщеннями про екстремальні явища та кількома локаціями — 6-8 тижнів. Вартість розраховується індивідуально.
Зв'яжіться з нами для безкоштовної оцінки вашого проекту. Отримайте консультацію інженера — ми проаналізуємо вимоги та запропонуємо оптимальне рішення.