Реализация уведомлений об истечении подписки в мобильном приложении
Пользователь забывает о подписке — это факт. Автоматическое списание прошло, сервис продолжает работать, но через месяц карта заблокирована, платёж падает, и приложение молчит. Человек уходит, думая, что подписка просто закончилась. Грамотно выстроенная система уведомлений удерживает этих пользователей ещё до того, как платёж не прошёл.
Серверные события vs. локальные уведомления
Первый вопрос при реализации: откуда знать, когда подписка истекает? Для In-App Purchase (StoreKit) Apple присылает события на сервер через App Store Server Notifications V2. Для собственных серверных подписок — логика на вашей стороне.
StoreKit 2 / App Store Server Notifications V2: Apple шлёт RENEWAL и EXPIRED события на ваш сервер. При получении DID_FAIL_TO_RENEW — первый сигнал, что нужно отправить push. При GRACE_PERIOD_EXPIRED — последний шанс. Важно: Apple самостоятельно отправляет некоторые системные уведомления, но полагаться только на них нельзя — бизнес-логику напоминаний строить нужно самостоятельно.
// Серверная нотификация V2 (декодированный payload)
{
"notificationType": "DID_FAIL_TO_RENEW",
"subtype": "GRACE_PERIOD",
"data": {
"bundleId": "com.example.app",
"transactionInfo": { ... }
}
}
Локальные уведомления: подходят только если сервера нет совсем, или для оффлайн-сценариев. UNUserNotificationCenter с UNCalendarNotificationTrigger — планируем уведомление на дату expiresDate - 3 days. Проблема: если пользователь продлил подписку через веб или другое устройство, локальное уведомление всё равно сработает. Без синхронизации с сервером это даёт ложные срабатывания.
Цепочка напоминаний
Одно уведомление — плохая стратегия. Работающая схема для B2C:
- За 7 дней до истечения: «Подписка истекает 15 апреля — продлите, чтобы не потерять данные»
- За 1 день: конкретный призыв с deeplink на экран управления подпиской
- В день истечения: уведомление с ограниченным временным предложением (если есть)
- Через 3 дня после: реактивация со скидкой (опционально)
Deeplink в уведомлении — обязателен. Push без действия теряет конверсию. На iOS: UNNotificationAction с foreground — открывает приложение и передаёт userInfo. На Android: PendingIntent с нужным Intent.
// iOS: обработка tap по уведомлению о подписке
func userNotificationCenter(_ center: UNUserNotificationCenter,
didReceive response: UNNotificationResponse) async {
let info = response.notification.request.content.userInfo
if info["type"] as? String == "subscription_expiry" {
NavigationRouter.shared.navigate(to: .subscriptionManagement)
}
}
На Android через FCM аналогично: в data payload передаём type: subscription_expiry, в FirebaseMessagingService.onMessageReceived маршрутизируем.
Сегментация и тайминг
Пользователь с месячной подпиской и пользователь с годовой — разные ситуации. Для месячной подписки 7-дневное окно — это 25% оставшегося срока, что агрессивно. Годовая — 7 дней из 365, нормально.
Часовой пояс пользователя критичен: push в 3 ночи — это раздражение и отписка от уведомлений. Firebase FCM позволяет задавать delivery_time с учётом локального времени устройства. Для APNs это делается на уровне сервера через планировщик задач с учётом timezone пользователя.
Процесс работы
Аудит текущей системы подписок: StoreKit / серверные / гибрид.
Настройка App Store Server Notifications V2 или серверных вебхуков для триггеров истечения.
Реализация цепочки push-уведомлений с deeplink на нужный экран.
Тестирование на sandbox-окружении StoreKit (Xcode → StoreKit Testing) и боевой проверкой FCM.
Ориентиры по срокам
Интеграция с готовым сервером уведомлений и StoreKit 2 — 2–3 дня. Реализация серверной логики с нуля, планировщиком задач и сегментацией пользователей — до 1 недели.