Реализация 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+ проектах. Стоимость разработки под ключ зависит от сложности и варьируется от $500–1.5k. Экономия времени при использовании готового решения составляет до 40%.

Сроки

Реализация scheduled notifications с UI управления расписанием, поддержкой reboot на Android и ограничением 64 уведомлений на iOS — 3–5 рабочих дней. Если добавляется серверное планирование через OneSignal или собственную очередь — ещё 2–3 дня. Получите консультацию и точную оценку вашего проекта — свяжитесь с нами.