Мотивация для написания этой статьи — не обсудить политические моменты или поругать большие корпорации. Совсем наоборот — поделиться горьким опытом и вариантами решения проблемы. Лучше приложить минимум усилий сейчас, чем спешно предпринимать действия потом. Предупрежден — значит вооружен. Сам я бы сэкономил кучу времени, если бы я наткнулся на такую статью, но, к сожалению, мне не попадалось что‑то вразумительное.

Так случилось, что приложение, которое мы разрабатывали в компании, было удалено из AppStore. Никто не мог подумать, что такое может произойти. Письмо счастья от корпорации никаких разъяснений не давало. Пришлось жить с тем, что есть, и искать пути решения и альтернативы.

Наше приложение сделано на кроссплатформенном фреймворке Ionic в связке с Capacitor на базе Angular. Однако идеи, которые я буду приводить в этой статье, будут справедливы и для других кроссплатформенных фреймворков, а также для нативных приложений.

Жизнь после

Как только приложение удаляют из AppStore, то оно превращается в кирпич, если вы, конечно, заранее не подстелили соломку. Итак, по порядку:

• Нельзя доставить обновление. Пользователи не увидят новых фич, так как не смогут загрузить себе обновление.

• Новые пользователи не смогут скачать приложение.

• Пуш‑уведомления перестают работать/доставляться.

Есть и хорошие моменты. Текущие пользователи по‑прежнему смогут пользоваться приложением, если оно у них есть установлено. Если в вашем приложении высокая отказоустойчивость, все основные функции реализованы, то это может выиграть время.

Доставка обновления

Согласно App Review Guidelines JS‑приложения или HTML5-приложения попадают под категорию mini apps и могут доставлять обновления без дополнительного ревью в App Store. Однако добавление новых функций в нативной части должно проходить через ревью. Данная политика справедлива и для Google Play.

Для Ionic существует плагин CapGo, который может доставлять новую версию. Работает это так. Когда запускается приложение, там открывается webview. В это представление встраивается бандл приложения. Ionic запускает свой локальный сервер, чтобы начать показывать локальные фронтовые файлы. CapGo позволяет проверять новую версию бандла на сервере при каждом заходе. Если обновление есть, то архив качается в фоне и устанавливается при следующем заходе. Причем доставка может производиться шифрованным способом. Уверен, что для других кроссплатформенных фреймворков тоже можно найти похожие решения.

Есть и другой способ. Можно иcпользовать Backend Driven подход для отображения UI. То есть бекенд вам говорит, какие именно компоненты нужно отрисовать и где, и какую логику имплементировать. Можно придумать такой подход самому в приложении или присмотреться к уже готовым решениям на рынке, например, DevKit. Этот способ отлично подойдет для нативных приложений.

Вы можете начать внедрять эти подходы уже сейчас, хотя бы частично. Будьте уверены, что они могут принести плоды, даже если вам ничего не грозит. Доставка обновлений пользователям сразу может существенно сократить Time To Market.

Пуш-уведомления

Пуши доставляются именно на устройство через Apple Notification Service. Поэтому они могут придти даже, если ваше приложение неактивно. Когда приложение удаляется, то теряется токен, поэтому пуши перестают работать. Подробнее можно изучить взаимодействие в этой статье.

Здесь уже ничего не поделаешь, ну почти. Надо понимать, что локальные уведомления вы все еще можете отправлять. Это когда пуш‑уведомление приходит не с сервера, а его отображает ваше приложение. Тут можно придумать следующее взаимодействие: сервер говорит, что нужно отправить, приложение отправляет (показывает уведомление). Это будет работать, если ваше приложение активно или свернуто (то есть продолжает работать в фоне).

Если приложение завершено пользователем, то естественно, у вас нет связи с сервером. В таких случаях, следует делать fallback: бекенд отправит смс‑сообщение. Для организации такого взаимодействия вы должны организовать информирование сервера, о том, какие уведомления вы получили и показали. Тогда если сервер не получит от вас сообщение в течение какого‑нибудь времени, то он отправит смс.

Коммуникация

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

Подготовьте настраиваемые баннеры (или сторис), где вы сможете сообщить важную информацию. Продумайте внутреннее наполнение. Будет полезным уметь встраивать ссылки на другие страницы, где вы сможете более подробно описать ситуацию и донести информацию о дальнейших действиях. Учтите возможность показывать их для определенных пользователей. Это может быть полезно для частичной раскатки.

Версионность API

Может потребоваться, поддерживать старое кирпич‑приложение, хотя у вас есть уже новое. В таком случае, необходимо продумать версионность API, чтобы новые фичи не зависели от старого приложения, не было конфликтов и коализий. На хабре полно ресурсов о том как это можно воплотить в жизнь. Поэтому ничего нового тут не расскажу, просто сухо подсвечиваю проблему.

Отключение

Если вы все‑таки выкатили новое приложение, однако видите по аналитике, что старое приложение продолжают использовать, коммуникация про «невозможность поддержки» не работает (пользователи ходят туда по привычке или просто не видели ваши уведомления), то вам может потребоваться убить старое приложение окончательно. Для этого реализуйте перекрывающий оверлей (модальное окно), который невозможно закрыть, где вы сможете подробно изложить причину отключения. Это вызовет меньше негатива, чем без причины неработающее приложение. К тому же сократит издержки на техническую поддержку.

Новые пользователи

Итак, ваше приложение удалили из AppStore, новые пользователи больше не могут его установить. Как же быть? Тут есть два естественных пути:

• Выпустить новое приложение. Однако никто не гарантирует, что его снова не удалят. В этом сценарии готовьтесь, что вы будете выпускать новое приложение каждый раз (на новое юрлицо), когда приложение удаляют.

• Выпустить PWA. Apple называют их Standalone Web Application. Это установление ярлыка вашего веб‑приложения на рабочий стол.

PWA

В целом, при правильном приготовлении PWA, пользователи даже не заметят отличий от обычного приложения из стора. При открытии такого приложения открывается изолированный контекст браузера с поддержкой нескольких API, которые не доступны в основном браузере Safari. Проверьте сами: многие из известных приложений можно установить как PWA, например, Twitter (X).

Функции, которые доступны, на самом деле уже хороши, чтобы обеспечить работоспособность вашего приложения. Из основного:

• Будут работать пуши. Доступно Push API. Причем доставляются всегда вне зависимости от активности приложения.

• Можно доставлять обновления. Для этого необходимо подключить ServiceWorker. Полный список всех возможностей можно посмотреть на этом ресурсе).

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

Надеюсь, было полезно и вы теперь знаете, что делать. Сами для себя мы выбрали PWA путь — он показался наиболее простым, быстрым и стабильным. Тем более что нам нужен был список API, который PWA может поддерживать уже сегодня, нас вполне удовлетворял.

Если есть еще способы, альтернативы, мысли, идеи — делитесь в комментариях.

Заглядывайте в мой телеграмм‑канал.