Заплановані сповіщення — одне з тих завдань, яке здається простим, доки не зіткнешся з обмеженнями платформ. На 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 дні. Отримайте консультацію та точну оцінку вашого проекту — зв'яжіться з нами.