Какое ожидаемое поведение приложения при переходе по пуш-уведомлению после выхода пользователя из аккаунта?

Что проверяют

Умеете ли вы выводить ожидаемое поведение из требований безопасности и UX. Следом обычно спрашивают, какие варианты этого сценария вы бы проверили и что будет, если после выхода в аккаунт войдёт другой человек.

Как отвечать

Скажите, что поведение задают требования, и предложите разумный вариант по умолчанию:

• токен отвязывается при выходе: бэкенд удаляет связь токена FCM или APNs с пользователем, и личные пуши на устройство больше не приходят;
• старые уведомления из шторки убираются: на Android через NotificationManager.cancelAll(), на iOS через removeAllDeliveredNotifications() у UNUserNotificationCenter;
• если пуш всё-таки открыли: приложение проверяет сессию, личный контент не показывает ни на мгновение и ведёт на экран входа с понятным сообщением;
• после входа того же пользователя: хорошо, если приложение сохранило диплинк и откроет нужный экран;
• после входа другого пользователя: контент прежнего аккаунта не открывается, человек попадает на главный экран;
• публичный контент (акция, статья): открывается и без входа, если так задумано.

Дальше матрица проверок: приложение закрыто, в фоне, открыто; выход кнопкой, истечение сессии, выход на другом устройстве, удаление аккаунта; пуш пришёл до выхода или после; в момент выхода нет сети, и отвязка токена не дошла до сервера. Отдельно проверьте, что текст пуша на заблокированном экране не раскрывает личных данных.

Инструменты: тестовые пуши через консоль Firebase или API FCM, на симуляторе iOS xcrun simctl push, для диплинков на Android adb shell am start с нужным URI.

Где спотыкаются

Проверяют только «открыл пуш, увидел экран входа». Самые серьёзные баги в соседних кейсах: мелькнувший на долю секунды личный экран или диплинк, который после входа другого пользователя открывает данные первого.

Не проверяют сервер. Если бэкенд не отвязал токен, пуши с личными данными продолжают приходить на устройство, где уже никто не залогинен.

Придумывают ожидаемый результат сами. Если сценарий в требованиях не описан, правильный ход: задать вопрос аналитику или продакту, зафиксировать решение и только потом заводить баг.