Привет! Меня зовут Сергей, я тимлид iOS-команды в Банки.ру. В разработке уже 11 лет — успел поработать и на аутсорсе, и в продуктовых финтех-компаниях. Мы в Банки.ру делаем приложение, которое помогает людям сравнить финансовые продукты от разных банков и страховых компаний и выбрать продукт с лучшими условиями.
Если вы iOS-разработчик и планируете внедрять Live Activities в своё приложение — эта статья для вас. Особенно если обновления LA инициируются событиями на сервере, а не действиями пользователя в приложении. Когда пользователь нажимает кнопку или запускает таймер — приложение само знает об этом и может обновить LA напрямую из кода. Но когда банк одобряет кредит или меняется статус заказа — это происходит на бэкенде, и только сервер знает о событии. В таких случаях без пушей не обойтись. Мы наступили на несколько граблей, нашли неочевидное решение и хотим сохранить вам пару недель отладки.
С чего всё началось
Одним прекрасным осенним днём наши продакт-оунеры пришли с задачей: сделать Live Activity, которая будет вести пользователя по этапам оформления банковского продукта. Например, это может быть оформление кредита (проверка данных → одобрение → подписание документов → выдача средств) или оформление карты (заявка → проверка → изготовление → доставка). В среднем у таких процессов 4-6 шагов, каждый из которых может занимать от нескольких секунд до нескольких минут. Каждый шаг — новое состояние на экране блокировки и в Dynamic Island.
Задача казалась понятной. Мы открыли документацию Apple и пошли разбираться.
Что говорит документация
Опыта с Live Activities у команды не было, поэтому начали с нуля. Apple описывает два способа запускать и обновлять LA:
1. Напрямую через код — activity.request(...) и activity.update(...) вызываются прямо в приложении.
— Push-to-Start token — для запуска LA без открытия приложения
— Update token — для обновления и завершения LA
Для нашего приложения первый способ (обновление через код напрямую) сразу не подходил.
Причина в архитектуре: приложение не знает, когда наступает следующий шаг. Это решает бэкенд на основе ответа от банка или страховой компании. Мы не можем предсказать, через 10 секунд придёт одобрение или через 5 минут. У нас также нет background mode, который позволял бы приложению самостоятельно просыпаться и проверять статус — мы специально избегаем фоновой активности для экономии батареи. Пуш-уведомления решают обе проблемы: сервер сам знает о событии и сам инициирует обновление. Архитектурно это чище — один источник правды на бэкенде.
Обновление напрямую из кода было бы предпочтительнее в другом сценарии: например, если бы шаги определялись локально в приложении (таймер обратного отсчёта, прогресс загрузки файла, счётчик калорий в фитнес-приложении). В таких случаях приложение само контролирует данные и может обновлять LA без участия сервера. Но для нашего случая — когда состояние меняется на бэкенде в непредсказуемые моменты — пуши были единственным рабочим вариантом.
Мы реализовали всё строго по рекомендациям Apple: получаем Push-to-Start token, отправляем на сервер, сервер запускает LA. Получаем Update token, отправляем на сервер, сервер обновляет LA через APNs. Красиво. Чисто. По книжке.
И тут всё пошло не так.
Проблема, которую мы не ожидали
При первых двух запусках Live Activity iOS показывает системные кнопки прямо под активностью. В первый раз — «Запретить / Разрешить», во второй — «Запретить / Разрешить всегда». Только с третьего запуска эти кнопки исчезают (если пользователь дважды нажал «Разрешить»).
И вот в чём ловушка: Update token генерируется и отправляется на сервер только после того, как пользователь нажмёт «Разрешить».
До этого момента — никакого токена. На практике это выглядело так: пользователь начинает оформление, видит первый шаг в Live Activity — и на этом LA замирает. Само оформление продолжается, заявка обрабатывается, но пользователь об этом не знает — следующие шаги в Live Activity не появляются. Чтобы LA начала обновляться, нужно специально выйти на Lock Screen и нажать «Разрешить».
Очевидно, что пользователь сам до этого не додумается. А отвлекать его от оформления ради разрешения на LA — плохой UX. Мы зашли в тупик.
Подсказка пришла от продакт-оунеров
И тут нас выручили те самые люди, которые принесли задачу. Продакты заметили: в Яндекс Картах Live Activity обновляется даже без нажатия на «Разрешить». Как?
Мы начали копать: гуглили, засыпали ИИ вопросами и тестировали приложение Яндекс Карт.
Оказалось, что ограничение касается только обновления через Update token. Если обновлять LA напрямую из кода — разрешение не нужно. Кнопки по-прежнему висят под активностью, но они не блокируют обновление.
Механизм понятен. Но есть проблема: данные о следующем шаге живут на бэкенде. А обновлять мы теперь хотим из кода, не через пуш.
Два варианта решения
Мы рассмотрели два подхода, взвесив плюсы и минусы:
Вариант 1. Background task (пуллинг)
Периодически будить приложение в фоне и спрашивать у сервера: «Есть ли новый шаг?». Если есть — обновить LA из кода.
Потребляет батарею в фоне
Требует отдельного метода для пуллинга
Пуш-сервер должен хранить текущее состояние шагов, чтобы отдать его по запросу.
Сейчас он так не работает: просто получает триггер и сразу шлёт шаг. Значит нужна серьёзная переработка сервера.
Вариант 2. Silent push
Сервер сам присылает данные нового шага внутри silent push (content-available: 1). Приложение просыпается на секунду, читает данные из payload и обновляет LA из кода.
Не нагружает батарею
Пуш-сервер уже умеет отправлять данные о шагах — логику менять почти не нужно
Единственный минус: нет гарантии доставки
Наш выбор пал на Silent push.
Но остался один нетривиальный вопрос: как в обработчике silent push понять, какую именно LA нужно обновить? Их может быть несколько. Об этой хитрости – чуть позже.
Итоговая схема работы
Решение получилось элегантным:
Если у пуш-сервера есть Update token для LA — обновление идёт через него (стандартный механизм Apple).
Если Update token ещё не получен (пользователь не нажал «Разрешить») — обновление идёт через silent push, приложение обновляет LA из кода.
Два механизма работают параллельно и автоматически дополняют друг друга.
Отступление: когда ИИ уверенно ошибается
Небольшая история в сторону. Пока мы разбирались с silent push, я проконсультировался с DeepSeek. Он категорически отверг эту идею. Говорил: «Забудь. Так никогда работать не будет. Используй исключительно Update token». Настаивал на этом несмотря на все мои аргументы.
Что ж. Всё работает :)
Как это устроено внутри
Время разобраться в деталях. Самый нетривиальный вопрос звучит так: когда приходит silent push с данными нового шага, как приложение понимает, какую именно LA нужно обновить?
Ответ прямолинейный — по activityId:
let activity = Activity<Attributes>.activities.first(where: { $0.id == activityId })Но откуда пуш-сервер знает этот activityId? Чтобы ответить, нужно посмотреть на всю систему целиком.
В ней три участника:
Сервис оформления продукта (далее — сервис оформления) — знает про шаги: что и когда должно отобразиться в LA.
Пуш-сервер — умеет формировать payload (json с данными пуша) и отправлять запросы в APNs. Хранит таблицы с токенами и отправленными сообщениями.
Мобильное приложение — запускает LA и знает её
activityId.
Проблема в том, что сервис оформления и мобильное приложение ничего не знают друг о друге напрямую. Они общаются только через пуш-сервер. А activityId — это идентификатор, который генерирует сама iOS на устройстве в момент запуска LA. Сервис оформления о нём ничего не знает.
Нужен общий ключ, по которому все три участника смогут договориться, что речь идёт об одном и том же LA.
Таким ключом стал uuid — идентификатор, который генерирует сервис оформления в момент запуска первого шага. Для конкретного LA этот uuid постоянный: все последующие шаги идут с тем же значением.
Вот как всё работает по шагам.
Шаг 1. Запуск LA
Сервис оформления решает показать первый шаг, генерирует uuid и отправляет его на пуш-сервер вместе с данными шага. Пуш-сервер кладёт uuid в структуру attributes — это неизменяемая часть LA, которая задаётся один раз при запуске и больше не обновляется. Затем отправляет Push-to-Start нотификацию в APNs и создаёт запись в своей таблице:
uuid → (пусто)
iOS получает Push-to-Start и создаёт LA.
Шаг 2. Приложение регистрирует LA
Даже без разрешения пользователя приложение получает доступ к только что созданной LA. Приложение читает из неё два идентификатора: activityId, сгенерированный iOS, и uuid, который пуш-сервер положил в attributes.
for await activity in Activity<Attributes>.activityUpdates {
sendToServer(activityId: activity.id, uuid: activity.attributes.uuid)
}Приложение отправляет оба значения на пуш-сервер. Тот находит запись по uuid и дописывает activityId:
uuid → activityId
Теперь пуш-сервер знает, какой activityId соответствует этому uuid.
Если в какой-то момент пользователь нажмёт «Разрешить», сгенерируется Update token. Приложение отправит его на пуш-сервер в связке с теми же activityId и uuid. Запись пополнится:
uuid → activityId → update token
Шаг 3. Отправка следующего шага
Когда сервис оформления хочет показать второй шаг, он отправляет его на пуш-сервер с тем же uuid, что был в первом. Пуш-сервер находит запись по uuid и смотрит: есть ли update token?
Есть → отправляет обновление стандартным способом через APNs с update token.
Нет → формирует silent push, кладёт в него activityId из записи и данные нового шага (content-state), и отправляет в APNs.
Первый вариант простой, нас интересует второй вариант.
Шаг 4. Приложение обновляет LA из кода
Приложение просыпается в фоне(даже если не было запущено) получив silent push и читает из него activityId. Находит нужную LA среди всех активных и обновляет её напрямую из кода — без какого-либо разрешения:
func updateLiveActivity(activityId: String, userInfo: [AnyHashable: Any]) {
guard let activity = Activity<Attributes>.activities.first(where: { $0.id == activityId }) else {
return
}
guard let contentState = userInfo["content-state"] as? [String: Any],
let data = try? JSONSerialization.data(withJSONObject: contentState),
let updatedContentState = try? JSONDecoder().decode(Attributes.ContentState.self, from: data) else {
return
}
Task { @MainActor in
await activity.update(using: updatedContentState, alertConfiguration: nil)
}
}LA обновляется. Пользователь видит новый шаг.
Что получил пользователь в итоге
С точки зрения пользователя всё выглядит так:
Кнопки «Разрешить / Запретить» появляются — шаги всё равно обновляются. Без каких-либо действий с его стороны.
Если пользователь нажал «Разрешить» — приложение автоматически переходит на стандартный механизм через Update token.
Пользователь не знает о том, что внутри два разных механизма доставки. Он просто видит, что всё работает.
Именно это и было целью.
Спасибо, что дочитали статью. Буду рад пообщаться в комментариях!