Реалізація Scheduled Notifications у мобільному застосунку

Заплановані сповіщення — одне з тих завдань, яке здається простим, доки не зіткнешся з обмеженнями платформ. На iOS — ліміт у 64 активних сповіщення, на Android — ризик втрати нагадувань після перезавантаження. Ми розробляємо такі системи вже 7 років і знаємо, як обійти ці підводні камені. У цій статті розберемо, які технології обрати та як уникнути типових помилок.

Одного разу клієнт попросив додати щоденні нагадування в трекер звичок. На перший погляд — тривіальне завдання. Але при тестуванні на iOS виявилося, що застосунок швидко впирається в ліміт 64 сповіщення, а на Android нагадування переставали працювати після перезавантаження пристрою. Довелося перепроектувати архітектуру: на iOS — динамічне перевикористання ідентифікаторів, на Android — перехід з AlarmManager на WorkManager. Досвід коштував кількох безсонних ночей, але в результаті система стала стабільною.

Коли що вибирати

Локальні сповіщення — якщо час прив'язаний до пристрою користувача і не змінюється з сервера. Трекер звичок, нагадування прийняти ліки, будильник-подія.

Серверні scheduled — якщо потрібна централізована логіка: маркетингові розсилки за розкладом, нагадування про подію у всіх учасників, сповіщення про дедлайн з урахуванням часового поясу користувача.

Як вибрати між локальними та серверними сповіщеннями?

Якщо сповіщення пов'язане з дією користувача (наприклад, він сам встановив нагадування) — краще локальне. Якщо сповіщення ініціюється сервером (нове замовлення, дедлайн, масова акція) — серверне. Гібридний підхід: локальне сповіщення може бути «синхронізоване» з сервером через 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).

Типові помилки та як їх уникнути

Що входить у роботу

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