Заплановані сповіщення — одне з тих завдань, яке здається простим, доки не зіткнешся з обмеженнями платформ. На iOS — ліміт у 64 активних сповіщення, на Android — ризик втрати нагадувань після перезавантаження. Ми розробляємо такі системи вже 7 років і знаємо, як обійти ці підводні камені. У цій статті розберемо, які технології обрати та як уникнути типових помилок.
Одного разу клієнт попросив додати щоденні нагадування в трекер звичок. На перший погляд — тривіальне завдання. Але при тестуванні на iOS виявилося, що застосунок швидко впирається в ліміт 64 сповіщення, а на Android нагадування переставали працювати після перезавантаження пристрою. Довелося перепроектувати архітектуру: на iOS — динамічне перевикористання ідентифікаторів, на Android — перехід з AlarmManager на WorkManager. Досвід коштував кількох безсонних ночей, але в результаті система стала стабільною.
Коли що вибирати
Локальні сповіщення — якщо час прив'язаний до пристрою користувача і не змінюється з сервера. Трекер звичок, нагадування прийняти ліки, будильник-подія.
Серверні scheduled — якщо потрібна централізована логіка: маркетингові розсилки за розкладом, нагадування про подію у всіх учасників, сповіщення про дедлайн з урахуванням часового поясу користувача.
| Локальні | Серверні | |
|---|---|---|
| Залежність від мережі | Не потрібна | Потрібна |
| Керування | На пристрої | На бекенді |
| Максимум сповіщень | 64 (iOS) / без обмежень (Android) | Без обмежень |
| Повторюваність | Календарні/часові тригери | Cron / черга задач |
| Приклад | Нагадування «встати» щодня о 9:00 | Розсилка «акція закінчиться через годину» всім користувачам |
Як вибрати між локальними та серверними сповіщеннями?
Якщо сповіщення пов'язане з дією користувача (наприклад, він сам встановив нагадування) — краще локальне. Якщо сповіщення ініціюється сервером (нове замовлення, дедлайн, масова акція) — серверне. Гібридний підхід: локальне сповіщення може бути «синхронізоване» з сервером через push-заглушку.
Серверна відправка за розкладом
OneSignal підтримує scheduled delivery прямо в API:
{ "app_id": "YOUR_APP_ID", "include_aliases": { "external_id": ["user_44521"] }, "contents": { "ru": "Зустріч з командою через 15 хвилин" }, "send_after": "YYYY-MM-DD HH:MM:SS UTC", "delayed_option": "timezone", "delivery_time_of_day": "9:00AM" } delayed_option: "timezone" — доставити у вказаний час доби з урахуванням часового поясу кожного отримувача. Корисно для «доброго ранку» розсилок.
Для власного бекенду — cron job або задача через Celery/BullMQ:
// Node.js + BullMQ const notificationQueue = new Queue('notifications', { connection: redis }); async function scheduleNotification(userId, content, sendAt) { const delay = sendAt.getTime() - Date.now(); await notificationQueue.add( 'send_push', { userId, content }, { delay, attempts: 3, backoff: { type: 'exponential', delay: 5000 } } ); } attempts: 3 з exponential backoff — обов'язково. FCM іноді повертає 503, потрібно повторити спробу.
Локальне планування на iOS
// Нагадування щодня о 8:00 func scheduleHabitReminder(habitId: String, name: String) { let content = UNMutableNotificationContent() content.title = name content.body = "Не забудьте відзначити виконання" content.sound = .default content.userInfo = ["habit_id": habitId] var components = DateComponents() components.hour = 8 components.minute = 0 let trigger = UNCalendarNotificationTrigger(dateMatching: components, repeats: true) let request = UNNotificationRequest( identifier: "habit-\(habitId)", content: content, trigger: trigger ) UNUserNotificationCenter.current().add(request) { error in if let error { print("Schedule failed: \(error)") } } } // Змінити час нагадування (видалити старе, додати нове) func rescheduleReminder(habitId: String, newHour: Int, newMinute: Int) { UNUserNotificationCenter.current() .removePendingNotificationRequests(withIdentifiers: ["habit-\(habitId)"]) // ... створюємо новий request з оновленими компонентами } Apple рекомендує не перевищувати 64 запланованих сповіщення на застосунок (UNUserNotificationCenter).
Чому WorkManager кращий за AlarmManager на Android?
AlarmManager точний, але не переживає reboot. WorkManager переживає reboot, але час виконання приблизний (±15 хвилин на Android 12+ через Doze). Вибір залежить від вимог до точності. Для нагадувань, де точність не критична (наприклад, «випити води»), WorkManager — надійне рішення.
// WorkManager — для некритичних за часом нагадувань fun scheduleHabitReminder(habitId: String, reminderHour: Int, reminderMinute: Int) { // Обчислюємо delay до наступного спрацювання val now = Calendar.getInstance() val target = Calendar.getInstance().apply { set(Calendar.HOUR_OF_DAY, reminderHour) set(Calendar.MINUTE, reminderMinute) set(Calendar.SECOND, 0) if (before(now)) add(Calendar.DAY_OF_YEAR, 1) } val delayMs = target.timeInMillis - now.timeInMillis val workRequest = OneTimeWorkRequestBuilder<ReminderWorker>() .setInitialDelay(delayMs, TimeUnit.MILLISECONDS) .setInputData(workDataOf( "habit_id" to habitId, "next_reminder_hour" to reminderHour, "next_reminder_minute" to reminderMinute )) .build() WorkManager.getInstance(context) .enqueueUniqueWork("habit-$habitId", ExistingWorkPolicy.REPLACE, workRequest) } // У Worker — показуємо сповіщення та плануємо наступне class ReminderWorker(context: Context, params: WorkerParameters) : Worker(context, params) { override fun doWork(): Result { val habitId = inputData.getString("habit_id") ?: return Result.failure() showNotification(habitId) // Плануємо наступний день scheduleHabitReminder( habitId, inputData.getInt("next_reminder_hour", 8), inputData.getInt("next_reminder_minute", 0) ) return Result.success() } } ExistingWorkPolicy.REPLACE — якщо користувач змінив час нагадування, стара задача замінюється новою.
Керування нагадуваннями в UI
Користувач повинен бачити заплановані нагадування та керувати ними. На iOS:
// Завантажити всі заплановані нагадування func loadPendingReminders() async -> [ScheduledReminder] { return await withCheckedContinuation { continuation in UNUserNotificationCenter.current().getPendingNotificationRequests { requests in let reminders = requests.compactMap { ScheduledReminder(from: $0) } continuation.resume(returning: reminders) } } } Відображаємо у списку з можливістю редагувати час або видалити. При видаленні — removePendingNotificationRequests + видалення з WorkManager (Android).
Типові помилки та як їх уникнути
Чек-лист: що перевірити перед деплоєм
- Переконайтеся, що на iOS не перевищено ліміт 64 сповіщень. Перевикористовуйте ідентифікатори.
- На Android протестуйте роботу після перезавантаження пристрою.
- Для повторюваних сповіщень використовуйте WorkManager з переплануванням у Worker.
- Перевірте роботу в Doze-режимі (Android) та Low Power Mode (iOS).
- Переконайтеся, що часовий пояс обробляється коректно.
Що входить у роботу
У розробку scheduled notifications під ключ входить:
- Проектування архітектури сповіщень (локальні/серверні/гібрид)
- Реалізація планувальника на iOS (UNUserNotificationCenter) та Android (WorkManager або AlarmManager)
- Інтеграція серверної черги (BullMQ, Celery) або OneSignal
- UI керування розкладом (список, додавання, редагування, видалення)
- Тестування на реальних пристроях: Doze-режим, перезавантаження, зміна часового поясу
- Документація з доступу та експлуатації
Гарантуємо стабільну роботу сповіщень — перевірено на 50+ проектах. Вартість розробки під ключ залежить від складності та визначається після аудиту.
Строки
Реалізація scheduled notifications з UI керування розкладом, підтримкою reboot на Android та обмеженням 64 сповіщень на iOS — 3–5 робочих днів. Якщо додається серверне планування через OneSignal або власну чергу — ще 2–3 дні. Отримайте консультацію та точну оцінку вашого проекту — зв'яжіться з нами.