Уровень: middle/senior мобильная разработка Стек: React Native, Expo SDK 54, expo-notifications, react-native-callkeep, react-native-voip-push-notification, expo-task-manager, FCM, APNs, PushKit Что внутри: deep linking из killed state, suppression активного чата, двойной "назад" после открытия из пуша, VoIP push + CallKit на iOS, Android channels с разной важностью, cold start navigation timing

Преамбула

Это десятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет.

Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync(). Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё.

В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.

Архитектурный обзор

У меня в lib/push-notifications.ts единственный источник правды по пушам. Хук usePushNotifications(), который монтируется в корневом layout приложения. В нём регистрация токена, два listener'а (foreground и tap), обработка cold start.

Параллельно есть отдельная инфраструктура для звонков:

lib/voip-push.ts это iOS VoIP PushKit. Другой push-канал на iOS, не обычные APNs. Используется для звонков потому что VoIP push:

• Доставляется с высоким приоритетом даже когда устройство в режиме экономии заряда

• Может разбудить приложение из убитого состояния для отображения CallKit

• Не показывает баннер сам — приложение должно вызвать CallKit.displayIncomingCall() в течение нескольких секунд иначе iOS забанит ваш VoIP token

lib/call-notification-handler.ts это обработка входящего звонка из background. На iOS регистрирует TaskManager-таск, который вызывает CallKit.displayIncomingCall() при получении push. На Android это отдельная нативная активность.

Три файла потому что iOS и Android устроены принципиально по-разному, и попытка унифицировать их через общий слой даёт абстракцию которая ничего не упрощает.

Грабля 1: пуш приходит когда юзер уже в чате

Это самая частая ошибка в самописных мессенджерах. Юзер открыл чат с Иваном, читает переписку. Иван присылает новое сообщение. У юзера всплывает push-баннер "Иван: привет".

Это раздражает. Юзер уже видит сообщение в открытом чате, push-баннер дублирует. В Telegram такого нет.

Решение, suppress пушей для активного чата. У меня есть lib/active-chat.ts, глобальный синглтон который держит ID текущего открытого чата:

let _activeChatId: string | null = null;

export const activeChat = {
  set(chatId: string | null) {
    _activeChatId = chatId;
  },
  get(): string | null {
    return _activeChatId;
  },
};

Chat screen в useEffect устанавливает activeChat.set(chatId) при монтировании и activeChat.set(null) при размонтировании.

Дальше handler пушей проверяет этот ID:

Notifications.setNotificationHandler({
  handleNotification: async (notification) => {
    const data = notification.request.content.data ?? {};

    // Сообщение для активного чата — подавляем
    if (data.chatId && data.chatId === activeChat.get()) {
      return {
        shouldShowAlert: false,
        shouldPlaySound: false,
        shouldSetBadge: false,
      };
    }

    return {
      shouldShowAlert: true,
      shouldPlaySound: true,
      shouldSetBadge: false,
    };
  },
});

shouldShowAlert: false означает пуш не покажется как баннер. shouldPlaySound: false означает звук тоже не сыграет. Сообщение всё равно придёт в чат через WebSocket — это другой канал, просто без баннера.

Это работает только когда приложение на переднем плане. Когда приложение в фоне или убито, handler не вызывается, OS показывает пуш сама. Но в этом случае юзер и не в чате, он вне приложения, и пуш правильно его извещает.

Грабля 2: дублирующийся экран чата в стеке

Юзер находится в чате с Иваном. Сворачивает приложение. Иван присылает сообщение. Юзер тапает по пушу. Что должно произойти?

Большинство туториалов скажут — router.push('/chat/' + chatId). После этого стек навигации выглядит так:

[главный экран] → [chat/ivan старый] → [chat/ivan новый]

Юзер нажимает "назад" в свежеоткрытом чате и попадает в старый экран чата с устаревшим состоянием. Двойное "назад" чтобы вернуться на главный. Это ломает UX.

Решение работает по двум сценариям:

const tryNavigate = () => {
  // Сценарий 1: этот чат уже открыт
  const active = activeChat.get();
  if (active === chatId) {
    if (messageId) {
      // Обновляем params текущего экрана — useEffect внутри загрузит
      // сообщения вокруг messageId
      router.setParams({ messageId });
      return true;
    }
    // Юзер и так в нужном чате, ничего не делаем
    return true;
  }

  // Сценарий 2: схлопнуть стек до корня, потом открыть чат
  try {
    router.dismissAll();
  } catch {}
  router.push(chatPath);
  return true;
};

router.dismissAll() — это API expo-router 6, закрывает все модальные экраны и возвращает стек к корню (tabs). После этого router.push(chatPath) добавляет чат поверх. Финальный стек:

[главный экран] → [chat/ivan]

Одно "назад" возвращает на главный.

Сценарий 1 более тонкий. Если юзер уже в нужном чате, но пуш ссылается на конкретное сообщение (messageId), мы не дёргаем навигацию, а обновляем params текущего экрана. Внутри chat screen есть useEffect([messageId]) который вызывает loadMessagesAround(messageId), это пагинирует чат к конкретному сообщению.

Грабля 3: cold start navigation timing

Юзер получил пуш про новое сообщение. Приложение убито системой (iOS прибил из-за памяти, Android из-за оптимизации заряда). Юзер тапает пуш. Что происходит?

OS запускает приложение с нуля. JavaScript bundle загружается, React-навигатор монтируется, layout инициализируется. И тут же мы пытаемся выполнить router.push('/chat/...').

Проблема. Navigator может быть ещё не готов. На свежем cold start первые 300-500мс роутер монтируется, и попытка навигации в этот момент тихо падает (или приводит к navigation в null).

Решение, retry с exponential backoff:

let attempts = 0;
const maxAttempts = 5;

const attempt = () => {
  attempts++;
  if (tryNavigate()) {
    console.log('[Push] Navigation successful on attempt', attempts);
    return;
  }
  if (attempts < maxAttempts) {
    setTimeout(attempt, 300 * Math.pow(2, attempts - 1));
  }
};

// Первая попытка с задержкой чтобы navigator успел смонтироваться
setTimeout(attempt, Platform.OS === 'android' ? 600 : 300);

Задержки: 300мс (iOS) или 600мс (Android) для первой попытки. Если не получилось, 300мс, 600мс, 1.2с, 2.4с, 4.8с. Обычно срабатывает с первой или второй попытки.

Почему Android медленнее? Эмпирически у меня на iOS свежее открытие до готовности роутера 200-300мс, на Android 400-600мс. Зависит от устройства, но Android в целом медленнее на cold start из-за того что Hermes/JSC bundle разворачивается медленнее.

Cold start pending notification обрабатывается отдельно:

// После регистрации, через 800мс пытаемся обработать pending notification
setTimeout(async () => {
  const initialNotification = await Notifications.getLastNotificationResponseAsync();
  if (initialNotification) {
    handleNotificationTap(initialNotification);
  }
}, 800);

getLastNotificationResponseAsync() возвращает уведомление которое запустило приложение, если оно было запущено из пуша. Если приложение запустили обычным тапом по иконке, возвращает null.

VoIP push на iOS — это другая планета

Обычные APNs для звонков не подходят по двум причинам:

Низкая приоритезация в Low Power Mode. Если у юзера 5% заряда, iOS откладывает обычные пуши на минуты. Звонок через минуту это не звонок.

Не разбудит killed app. Обычный пуш показывается системой, приложение остаётся убитым. Для звонка нужно запустить приложение чтобы открыть WebRTC-соединение.

Решение, PushKit + CallKit. VoIP-пуш доставляется с приоритетом, разбудит killed app, и приложение обязано в течение ~5 секунд вызвать CallKit.displayIncomingCall(). Иначе iOS забанит ваш VoIP token.

// 1. Настроить CallKit
await CallKeep.setup({
  ios: {
    appName: 'ONEMIX',
    supportsVideo: true,
    maximumCallGroups: '1',
    maximumCallsPerCallGroup: '1',
    includesCallsInRecents: false,
  },
});

// 2. Подписаться на получение VoIP push token
VoipPushNotification.addEventListener('register', (token: string) => {
  _voipToken = token;
  api.updateVoipToken(token);
});

// 3. Подписаться на получение VoIP push notification
VoipPushNotification.addEventListener('notification', (notification: any) => {
  // AppDelegate уже показал CallKit UI natively
  // здесь можем инициализировать WebRTC если нужно
});

// 4. Запросить регистрацию VoIP token
VoipPushNotification.registerVoipToken();

Ключевая тонкость. VoIP token хранится отдельно от обычного APNs token, и отправляется на бэкенд через отдельный API эндпоинт. Бэкенд должен знать какой пользователь имеет какой VoIP token, и слать VoIP-пуши через отдельное соединение с APNs (с заголовком apns-push-type: voip).

И есть race condition. VoIP token может прийти до того как юзер залогинился в приложении. Если просто проигнорировать, бэкенд не узнает что у юзера есть устройство для звонков.

Решение, кэшировать token локально и при логине синхронизировать:

let _voipToken: string | null = null;

VoipPushNotification.addEventListener('register', (token: string) => {
  _voipToken = token;
  api.updateVoipToken(token).catch(() => {
    // ignore — синхронизируем позже через syncVoipToken
  });
});

// После login:
export async function syncVoipToken(): Promise<void> {
  if (Platform.OS !== 'ios') return;
  if (!_voipToken) return;
  await api.updateVoipToken(_voipToken);
}

После логина мы вызываем syncVoipToken() который догоняет токен на бэкенд.

iOS background task для звонков из killed state

Самая болезненная история. Звонок когда приложение полностью убито. iOS не запустит JS-runtime по обычному пушу. Чтобы открыть CallKit screen, нужен специальный background task.

import * as TaskManager from 'expo-task-manager';

export const INCOMING_CALL_TASK = 'INCOMING_CALL_TASK';

TaskManager.defineTask(INCOMING_CALL_TASK, async ({ data, error }) => {
  if (error) {
    console.error('[Push] Background task error:', error);
    return;
  }

  const notification = data as { notification: Notifications.Notification };
  const payload = notification.notification.request.content.data;

  if (payload?.type === 'incoming_audio_call' ||
      payload?.type === 'incoming_video_call') {
    // Показываем CallKit screen НАТИВНО
    await showNativeIncomingCall({
      uuid: payload.uuid,
      callerName: payload.callerName,
      hasVideo: payload.type === 'incoming_video_call',
    });
  }
});

// При запуске приложения регистрируем task
const isRegistered = await TaskManager.isTaskRegisteredAsync(INCOMING_CALL_TASK);
if (!isRegistered) {
  await Notifications.registerTaskAsync(INCOMING_CALL_TASK);
}

defineTask объявляется на верхнем уровне модуля, не внутри функции. Это требование TaskManager. Он сериализует задачи при killed state, и им нужны ссылки на функции которые существуют до запуска приложения.

registerTaskAsync подписывает task на push notifications. Когда приходит VoIP-пуш с type=incoming_call, iOS запускает этот task в фоне без открытия приложения, и наша функция вызывает showNativeIncomingCall() — это native-функция (моя обёртка над CallKeep) которая показывает CallKit screen.

Если юзер ответит на звонок в CallKit, тогда приложение запустится полноценно, и WebRTC-соединение инициируется.

Android channels с разными importance

Android позволяет создавать разные категории уведомлений с разным поведением. У меня их две:

await Notifications.setNotificationChannelAsync('messages', {
  name: 'Сообщения',
  importance: Notifications.AndroidImportance.HIGH,
  vibrationPattern: [0, 250, 250, 250],
  sound: 'default',
  enableVibrate: true,
  showBadge: true,
});

await Notifications.setNotificationChannelAsync('calls', {
  name: 'Звонки',
  importance: Notifications.AndroidImportance.MAX,
  vibrationPattern: [0, 500, 200, 500, 200, 500],
  sound: 'default',
  lockscreenVisibility: Notifications.AndroidNotificationVisibility.PUBLIC,
  bypassDnd: true,
  allowBubbles: true,
});

Различия:

Importance: HIGH для сообщений (баннер с heads-up notification), MAX для звонков (full-screen intent).

Vibration: для звонка длиннее и в несколько импульсов, должно работать в кармане.

bypassDnd: true для звонков, звонок пройдёт даже в режиме "Не беспокоить". Для сообщений false, DnD должен подавлять сообщения.

lockscreenVisibility: PUBLIC для звонков, отображается полностью на lock screen. Сообщения PRIVATE, содержание скрыто, видно только имя приложения.

Эти настройки фиксированные для channel. После создания их можно изменить только удалив и пересоздав channel (что сбрасывает пользовательские настройки). Поэтому хорошо подумать до деплоя.

Что бы я сделал по-другому

Раздельные модули для iOS и Android. Сейчас push-notifications.ts один на обе платформы, с кучей if (Platform.OS === 'ios') внутри. По мере роста файла (441 строка) это становится трудночитаемо. Если бы начинал, сделал бы push-ios.ts и push-android.ts с общим интерфейсом.

Persistent queue для pending navigation. Сейчас pending notification обрабатывается через setTimeout(attempt, 800). Это работает, но если за эти 800мс юзер нажмёт на что-то ещё, навигация прервётся. Правильнее, очередь действий, которая выполняется когда роутер готов.

Server-side проверка active chat. Suppression активного чата у меня на клиенте. Это означает что бэкенд всё равно шлёт пуш, а клиент его подавляет. Это лишняя нагрузка на APNs/FCM и расход энергии устройства. Правильнее, клиент сообщает бэкенду "сейчас активный чат X", и бэкенд не шлёт пуши для этого чата. Это сложнее в реализации но эффективнее.

Метрики доставки. У меня нет понимания процента доставленных пушей. Apple даёт частичную статистику в App Store Connect, Google в Firebase. Я их не интегрировал, но это критично для долгосрочной поддержки. Если у 30% пользователей пуши не доходят (например из-за агрессивной экономии заряда на Xiaomi/Huawei), я об этом не узнаю.

Заключение

Push-уведомления это одна из самых недооцененных частей мобильной разработки. Туториал показывает основу за 10 строк кода. Production-реализация это 700+ строк с десятком edge cases которые ловятся в боевой эксплуатации.

В мессенджере с реальным трафиком push становится основным каналом доставки для пользователей не в приложении. Если что-то ломается, пользователь не узнает о новом сообщении и просто перестанет пользоваться приложением. Это бесшумная потеря retention.

Главное что я понял за время работы с пушами. iOS и Android устроены принципиально по-разному, и попытка унифицировать их через общий слой даёт абстракцию которая ничего не упрощает. Лучше принять платформенные различия и писать платформенный код.

В Telegram-канале пишу мелкие наблюдения по горячему. Если интересно: https://t.me/SkillTrackr.

Это десятая статья из серии. В предыдущих был мобильный клиент ONEMIX: трёхуровневый кэш, Double Ratchet E2E, WebRTC звонки, vanilla Electron, outbox-паттерн. Backend: FastAPI монолит. И сторонние проекты: AI-агент Лира, мнение про вайб-кодинг, двухэтапный AI-арбитр.

Если интересны конкретные куски как именно устроен AppDelegate native code для VoIP, как работает PushKit при reboot устройства, как обходить Xiaomi-блокировки на FCM — пишите, разберу в комментариях.