Запланированные уведомления — одна из тех задач, которая кажется простой, пока не столкнешься с ограничениями платформ. На 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+ проектах. Стоимость разработки под ключ зависит от сложности и варьируется от 50 000 до 150 000 рублей. Экономия времени при использовании готового решения составляет до 40%.
Сроки
Реализация scheduled notifications с UI управления расписанием, поддержкой reboot на Android и ограничением 64 уведомлений на iOS — 3–5 рабочих дней. Если добавляется серверное планирование через OneSignal или собственную очередь — ещё 2–3 дня. Получите консультацию и точную оценку вашего проекта — свяжитесь с нами.