14.05.2026 09:00
KolesinS 0 6500 Источник

Привет! Меня зовут Сергей, я тимлид iOS‑команды в Банки.ру. В разработке уже 11 лет — успел поработать и на аутсорсе, и в продуктовых финтех‑компаниях. Мы в Банки.ру делаем приложение, которое помогает людям сравнить финансовые продукты от разных банков и страховых компаний и выбрать продукт с лучшими условиями.

Если вы iOS‑разработчик и планируете внедрять Live Activities в своё приложение — эта статья для вас. Особенно если обновления LA инициируются событиями на сервере, а не действиями пользователя в приложении. Когда пользователь нажимает кнопку или запускает таймер — приложение само знает об этом и может обновить LA напрямую из кода. Но когда банк одобряет кредит или меняется статус заказа — это происходит на бэкенде, и только сервер знает о событии. В таких случаях без пушей не обойтись. Мы наступили на несколько граблей, нашли неочевидное решение и хотим сохранить вам пару недель отладки.

С чего всё началось

Одним прекрасным осенним днём наши продакт‑оунеры пришли с задачей: сделать Live Activity, которая будет вести пользователя по этапам оформления банковского продукта. Например, это может быть оформление кредита (проверка данных → одобрение → подписание документов → выдача средств) или оформление карты (заявка → проверка → изготовление → доставка). В среднем у таких процессов 4–6 шагов, каждый из которых может занимать от нескольких секунд до нескольких минут. Каждый шаг — новое состояние на экране блокировки и в Dynamic Island.

Задача казалась понятной. Мы открыли документацию Apple и пошли разбираться.

Что говорит документация

Опыта с Live Activities у команды не было, поэтому начали с нуля. Apple описывает два способа запускать и обновлять LA:

1. Напрямую через код — activity.request(...) и activity.update(...) вызываются прямо в приложении.

2. Через пуш‑уведомления:

  • 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? Чтобы ответить, нужно посмотреть на всю систему целиком.

В ней три участника:

  1. Сервис оформления продукта (далее — сервис оформления) — знает про шаги: что и когда должно отобразиться в LA.

  2. Пуш‑сервер — умеет формировать payload (json с данными пуша) и отправлять запросы в APNs. Хранит таблицы с токенами и отправленными сообщениями.

  3. Мобильное приложение — запускает 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.

Пользователь не знает о том, что внутри два разных механизма доставки. Он просто видит, что всё работает.

Именно это и было целью.

Спасибо, что дочитали статью. Буду рад пообщаться в комментариях!

Комментарии (0)