Локальные уведомления для iOS и Android — реализация под ключ

Локальные уведомления в мобильном приложении: iOS и Android

Клиент пожаловался, что напоминания в трекере привычек перестали работать после обновления iOS. Причина — превышен лимит в 64 уведомления, и система молча их удалила. Мы переписали планировщик с приоритетной очередью: ближайшие 64 держим в системе, остальные перепланируем при каждом открытии. Этот способ мы применяли в более чем 30 проектах. Локальные уведомления — единственный тип, не требующий сервера. Приложение само планирует их через системный API: по времени, по триггеру календаря или при входе в геозону.

Мы — команда мобильных разработчиков с 5-летним опытом и более 50 реализованных проектов. Сертифицированные специалисты по iOS и Android. Реализуем локальные уведомления под ключ: от схемы триггеров до публикации в сторах. Оценим ваш проект за 1 день — просто напишите нам. Закажите внедрение и получите гарантию на код 3 месяца.

Как обойти лимит в 64 уведомления на iOS?

UNUserNotificationCenter позволяет запланировать не более 64 уведомлений одновременно. Для трекеров привычек, будильников или календарей этого недостаточно. Решение — динамическая очередь. Храните все запланированные напоминания в локальной БД (Core Data или Realm). При запуске приложения выбирайте ближайшие 64 и регистрируйте их. При срабатывании или отмене — обновляйте очередь. Пользователь никогда не догадается о лимите. Вот пример планирования по времени:

import UserNotifications

// 1. По времени (через N секунд)
let content = UNMutableNotificationContent()
content.title = "Напоминание о встрече"
content.body = "Встреча с командой через 15 минут"
content.sound = .default
content.badge = 1

let trigger = UNTimeIntervalNotificationTrigger(timeInterval: 900, repeats: false)
let request = UNNotificationRequest(identifier: "meeting-reminder-123",
                                    content: content,
                                    trigger: trigger)
UNUserNotificationCenter.current().add(request)

// 2. По дате/времени (повторяющееся каждый день в 9:00)
var dateComponents = DateComponents()
dateComponents.hour = 9
dateComponents.minute = 0
let dailyTrigger = UNCalendarNotificationTrigger(dateMatching: dateComponents, repeats: true)

// 3. По геозоне
let region = CLCircularRegion(center: CLLocationCoordinate2D(latitude: 50.45, longitude: 30.52),
                               radius: 200,
                               identifier: "office-zone")
region.notifyOnEntry = true
region.notifyOnExit = false
let geoTrigger = UNLocationNotificationTrigger(region: region, repeats: false)

Почему после перезагрузки Android уведомления пропадают?

AlarmManager сбрасывается при выключении устройства. Если не обработать BOOT_COMPLETED, все напоминания исчезнут. Мы всегда добавляем BroadcastReceiver на BOOT_COMPLETED, который читает активные напоминания из Room и перепланирует их через AlarmManager. Для периодических задач без точного времени используем WorkManager — он автоматически восстанавливается после reboot. Вот пример точного аларма:

val alarmManager = context.getSystemService(AlarmManager::class.java)
val intent = Intent(context, NotificationReceiver::class.java).apply {
    putExtra("title", "Напоминание о встрече")
    putExtra("body", "Встреча через 15 минут")
    putExtra("notification_id", 123)
}
val pendingIntent = PendingIntent.getBroadcast(context, 123, intent,
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE)

alarmManager.setExactAndAllowWhileIdle(
    AlarmManager.RTC_WAKEUP,
    triggerAtMillis,
    pendingIntent
)

NotificationReceiver — BroadcastReceiver, который строит и показывает уведомление:

class NotificationReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val notification = NotificationCompat.Builder(context, "reminders_channel")
            .setSmallIcon(R.drawable.ic_notification)
            .setContentTitle(intent.getStringExtra("title"))
            .setContentText(intent.getStringExtra("body"))
            .setPriority(NotificationCompat.PRIORITY_HIGH)
            .setAutoCancel(true)
            .build()

        NotificationManagerCompat.from(context)
            .notify(intent.getIntExtra("notification_id", 0), notification)
    }
}

На Android 12+ точные алармы требуют разрешения SCHEDULE_EXACT_ALARM. Для повторяющихся — WorkManager с PeriodicWorkRequest проще и надёжнее.

Как выглядит пошаговая реализация?

1. Проектирование схемы уведомлений. Определяем типы триггеров: время, календарь, геозона. Для каждого — контент, звук, значок, категория. Учитываем сценарии: одноразовые, повторяющиеся, с отменой.
2. Настройка каналов. На Android создаём каналы (NotificationChannel), на iOS — категории (UNNotificationCategory). Это позволяет пользователю управлять важностью и группировкой.
3. Разработка планировщика. На iOS — UNUserNotificationCenter с приоритетной очередью. На Android — AlarmManager для точных + WorkManager для периодических. Добавляем обработку BOOT_COMPLETED.
4. Тестирование. Проверяем на реальных устройствах: сон, перезагрузка, регион, лимиты. Используем TestFlight и Firebase App Distribution.
5. Оптимизация под сторы. Учитываем требования к разрешениям (точные алармы, фоновая геолокация) и оформляем код для ревью.

Сравнение iOS и Android

Типичные сценарии и их реализация

Как обработать нажатие на уведомление?

На iOS нужно реализовать UNUserNotificationCenterDelegate и метод userNotificationCenter(_:didReceive:withCompletionHandler:). На Android — указать PendingIntent с action, который открывает нужный экран по deep link (App Links или scheme). Проконсультируйтесь с нами по интеграции — мы поможем настроить правильную навигацию.

Что входит в нашу работу

• Проектная документация: схемы триггеров, диаграммы состояний.
• Исходный код с комментариями на Swift и Kotlin.
• Настройка сертификатов и ключей (APNs, Google Play Store).
• Тестовый билд через TestFlight/Firebase App Distribution.
• Помощь с публикацией и модерацией.
• Гарантия на код 3 месяца.

Сроки

Реализация базового функционала (время + календарь) на одной платформе — 3 рабочих дня. С геозонами и двуплатформенная версия — до 6 дней. Сроки могут меняться в зависимости от сложности, но мы всегда даём точную оценку после анализа вашего проекта. Свяжитесь с нами, чтобы обсудить ваш проект и получить бесплатную оценку. Закажите реализацию локальных уведомлений прямо сейчас — ваши пользователи точно не пропустят важное.

val geofence = Geofence.Builder()
    .setRequestId("office-zone")
    .setCircularRegion(50.45, 30.52, 200f)
    .setExpirationDuration(Geofence.NEVER_EXPIRE)
    .setTransitionTypes(Geofence.GEOFENCE_TRANSITION_ENTER)
    .build()

val request = GeofencingRequest.Builder()
    .setInitialTrigger(GeofencingRequest.INITIAL_TRIGGER_ENTER)
    .addGeofence(geofence)
    .build()

geofencingClient.addGeofences(request, geofencePendingIntent)

https://developer.apple.com/documentation/usernotifications/handling_notifications_and_notification-related_actions

Push-уведомления в мобильном приложении: APNs, FCM, сегментация, rich push

Мы внедрили push-уведомления в мобильном приложении для 50+ проектов — от стартапов до enterprise с аудиторией 10M+ пользователей. Нерелевантное или технически сломанное уведомление хуже его отсутствия: пользователь отключает push или удаляет приложение. Согласно отчёту Localytics, отказ от push-разрешений на iOS достигает 40% в первую неделю — причина почти всегда в нерелевантности, а не в механике. Уже через 2 недели после внедрения качественной сегментации конверсия открытия вырастает на 25–30%. Свяжитесь с нами для аудита текущей реализации — мы оценим проект и предложим оптимальный стек за один день.

Как работает инфраструктура: APNs и FCM

APNs — единственный канал доставки на iOS. Всё остальное (OneSignal, Braze, Airship) — обёртки поверх него. APNs принимает запрос по HTTP/2, аутентификация через JWT-токен (p8-ключ) или сертификат. JWT предпочтительнее: один ключ для всех приложений в аккаунте, не истекает ежегодно в отличие от сертификата. Подробнее — на Wikipedia.

Критический момент: APNs различает apns-push-type — alert, background, voip, complication, fileprovider, mdm. Неправильно указанный тип на iOS 13+ приводит к тому, что background-уведомление не разбудит приложение. Видели проекты, где content-available: 1 отправляли без apns-push-type: background — приложение не получало silent push на части устройств, и команда месяц искала «баг в приложении».

FCM на Android работает через Google Play Services. Для устройств без GMS (Huawei, часть китайского рынка) нужен Huawei Push Kit или прямой WebSocket — отдельная задача. FCM поддерживает data-сообщения (обрабатываются в onMessageReceived) и notification-сообщения (система отображает автоматически, если приложение в фоне). Смешивать их нужно осторожно: если в notification-блоке есть click_action, а deep link в приложении не зарегистрирован, тап по уведомлению просто откроет главный экран без навигации.

Почему сегментация — основа эффективных push-уведомлений?

Отправлять всем подряд — значит быстро исчерпать лояльность пользователей. Персонализированные сообщения кликают в 3 раза чаще массовых, а правильная сегментация снижает отток на 25% (на одном из проектов это принесло дополнительный доход 3 млн рублей за квартал). Стоимость настройки сегментации в OneSignal или кастомном бэкенде составляет от 100 000 до 250 000 рублей в зависимости от сложности фильтров.

Нормальная сегментация строится на нескольких уровнях.

Топики — для широких категорий: «новые акции», «обновления статуса заказа». Пользователь подписывается через FirebaseMessaging.getInstance().subscribeToTopic("orders"). Просто, но нет гибкой фильтрации.

Сегменты по атрибутам — через OneSignal, Braze или кастомный бэкенд. Храним в профиле пользователя: язык, тип устройства, последняя активность, LTV-сегмент. Уведомление уходит только тем, у кого last_active < 7_days и plan = premium. OneSignal позволяет строить такие фильтры в интерфейсе без кода.

Персонализированные — по конкретному device_token. Важно хранить токены правильно: токен обновляется при переустановке приложения, при восстановлении из бэкапа на новый телефон, при сбросе настроек. На iOS используем UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, сохраняем на бэкенд при каждом запуске, не только при первом. Иначе через 3 месяца 30% токенов в базе устаревшие.

Что такое rich push и как он повышает конверсию?

Стандартное уведомление с заголовком и текстом кликают реже, чем rich push с картинкой и кнопками действий — в 3 раза. Но реализация rich push — отдельная работа на каждой платформе.

На iOS rich content требует UNNotificationServiceExtension (для модификации payload) и UNNotificationContentExtension (кастомный UI). Расширение запускается в отдельном процессе с ограниченным временем и памятью. Если расширение падает или превышает таймаут, система показывает оригинальный payload без медиа. Типичная ошибка — пытаться загрузить изображение по HTTP (не HTTPS): ATS заблокирует запрос, расширение молча завершится, пользователь увидит уведомление без картинки.

На Android с API 26+ уведомления привязаны к NotificationChannel. Если канал создан с IMPORTANCE_LOW, звук и вибрация недоступны. Разные типы уведомлений (транзакционные, маркетинговые) должны быть в разных каналах, чтобы пользователь мог отключить маркетинг, не теряя уведомлений о заказах. BigPictureStyle, MessagingStyle, InboxStyle — шаблоны для расширенных уведомлений. MessagingStyle с Person и аватарками — лучший выбор для чатов.

Как отследить доставку и конверсию push-уведомлений?

Отправить уведомление — полдела. Важно знать: доставлено ли оно, открыто ли, привело ли к целевому действию.

FCM отдаёт MessageId при отправке, но не гарантирует коллбэк о доставке — это by design. Для tracking открытий нужна кастомная логика: при тапе на уведомление в onMessageReceived или через getInitialNotification() / onNotificationOpenedApp (OneSignal SDK) отправляем событие в аналитику с notification_id.

OneSignal предоставляет встроенную аналитику доставки и CTR. Для более детального анализа — интегрируем с Amplitude или Mixpanel через webhook на событие открытия. Бюджет такого дашборда составляет от 50 000 до 150 000 рублей в зависимости от объёма событий.

Как мы внедряем push-уведомления: типовой процесс

1. Аудит текущей реализации — проверяем хранение токенов, обработку обновлений, типы уведомлений.
2. Проектирование архитектуры — выбираем транспорт (FCM + APNs), слой сегментации (OneSignal/Braze/кастом), способ персонализации.
3. Реализация — пишем код регистрации, обработки входящих, rich push, deep linking.
4. Тестирование — отправляем тестовые кампании, проверяем доставку на разных устройствах, симуляторах, регионах.
5. Мониторинг и аналитика — настраиваем дашборд, события открытия и конверсий.
6. Документация и обучение — передаём команде материалы по эксплуатации.

Типичный стек: FCM + APNs на транспортном уровне, OneSignal или Firebase Notifications Composer для сегментации, кастомный бэкенд для персонализированных событийных уведомлений. Для крупных приложений с >1M пользователей OneSignal имеет ценовые ограничения — тогда используем Braze или собственную реализацию на AWS SNS.

Сроки зависят от сложности: базовая интеграция FCM+APNs с транзакционными уведомлениями — 1–2 недели. Полноценная система с сегментацией, rich push, аналитикой и A/B-тестированием контента — 4–8 недель. Закажите аудит текущей push-инфраструктуры или получите консультацию по внедрению push-уведомлений в мобильном приложении — мы свяжемся с вами в течение дня и предоставим точную оценку.