Деплой Flutter-приложений и особенности платформ
Всем привет! Меня зовут Александр Омельяненко, я Flutter-разработчик в AGIMA. Сегодня расскажу про релиз приложений в сторы. И поскольку работаю с кросс-платформой, речь пойдет как про Android, так и про iOS. Уверен, каждый участник команды должен понимать, что происходит с приложением, когда оно готово. Поэтому всё объясняю подробно: какие сторы использовать, каких подводных камней ожидать, что делать, если релиз отклонили.
Семь этапов релизного процесса
Старт разработки: уже тут есть несколько нюансов, на которые стоит обратить внимание.
Создание аккаунтов в сторах: первым делом решаем, кто будет этим заниматься — мы или заказчик. Я буду рассматривать второй вариант.
Подготовка: пустых аккаунтов недостаточно. Нужно их заполнить, создать там несколько важных файлов, добавить наших специалистов.
Финальная проверка сборки: хорошая практика — проверить, как сборка будет устанавливаться, и убедиться, что приложение будет открываться. В сущности, мы будем имитировать установку приложения из стора. Для Android-сборок мы можем использовать, к примеру, FireBase. У них есть раздел App Distribute. Для iOS-сборок есть TestFlight.
Отправка сборки на проверку: сборку могут отклонить, в этом случае придется решать проблемы или, возможно, искать обходные пути.
Финал разработки: если вдруг при финальной проверке появились какие-то проблемы или сборка отклонена, разработчикам нужно исправить недочеты. Это последние исправления перед деплоем.
Публикация сборки: самый ожидаемый пункт, когда выносим на свет то, над чем так долго работали.
Эта схема показывает, как этапы разработки соотносятся с этапами деплоя. По сути, они взаимосвязаны. Готовиться к деплою можно практически сразу. Почему это так — я объясню чуть ниже.
Подводные камни сторов
AppStore | Первое и самое болезненное: если приложение принадлежит компании, которая попала под санкции, аккаунт могут забанить. То же самое произойдет, даже если среди директоров есть человек под санкциями. Из новостей мы знаем, что такое случалось со Сбером, «Тинькофф» и некоторыми другими. Все мы видим, как они пытались выкрутиться: заводили новые аккаунты, меняли дизайн и т. д. AppStore часто отклоняет сборки, долго их проверяет, а отказы аргументирует довольно сухо и вообще не всегда. У AppStore замороченный процес с подписанием сборки и выдачей нужных прав и сертификатов. Всё намного проще, если за это отвечает человек со стороны заказчика и он постоянно на связи. Но так бывает не всегда. Неудобно платить в РФ и РБ. Чтобы оплачивать аккаунт, приходится использовать сторонние сервисы. |
Google Play | В Google Play тоже могут забанить аккаунт из-за санкций. Например, у нас бывали случаи, когда с AppStore всё было в порядке, а Google Play блокировал. Google Play открывается только через VPN. Мелочь, но неприятно. В Google Play также есть проблема с оплатой из РФ. В целом платформа более дружелюбная, чем AppStore. |
RuStore от VK | Здесь самые быстрые проверки, но, но популярность он только набирает. По сути, это не полноценный стор, а библиотека .apk-файлов. |
AppGallery | Команда AppGallery пошла дальше: у них большой каталог, и только его часть — это .apk-файлы. Если нужно скачать файл, которого у них нет, они перебросят на сторонний сайт, где он есть — например, APKPure, |
Требования к мобильному приложению
Само собой, нам нужно соблюдать все правила сторов. Например, не призывать к терроризму, не продавать оружие и запрещенные вещества и т. п. Но есть и другие особенности, которые нужно учесть на этапе разработки.
Apple | Первое и самое неочевидное: если в мобильном приложение у пользователя есть аккаунт, ему нужно дать возможность его удалить. Зачастую достаточно кнопки «Удалить аккаунт», по нажатии на которую пользователь выйдет из аккаунта, а из локального хранилища удалится токен и остальные данные. Ревьюеры, конечно, могу попробовать авторизоваться еще раз по этим кредам, чтоб проверить, на самом ли деле аккаунт удален, но они так не делают. Правильно сформированный текст пермишенов. Текст должен содержать три ключевые составляющие: — на что разрешение, — зачем это нужно, — где это используется. Например, мы просим предоставить разрешение на доступ к камере. Приложению это необходимо, чтобы вы могли делать фото обьектов и прикладывать их к объявлению. На самом деле правил больше, и они не всегда очевидны. Например, история с авторизацией через сторонние сервисы. Если вы используете такие (vkid/tinkoff id и пр.), то вы обязаны добавить и поддержать авторизацию через Apple ID. |
Google Play, RuStore, AppGallery | У Google есть нюанс — они смотрят на SDK, которые использует приложение. В остальном особых требований нет. Только бюрократия, контент и качество приложения. Сейчас Google становится жестче с правилами. У них, как и у AppStore, уже появилось требование по поводу удаления аккаунта и нормальных описаний к пермишенам. |
Что нужно для первого деплоя
Теперь мы знаем, куда выкладывать приложение и каким требованиям оно должно отвечать. Но это еще не всё, для первого деплоя нам нужно подготовить:
Рабочий код, протестированный и согласованный с заказчиком.
Созданные и оплаченные аккаунты в сторах.
Сами сборки, которые мы будем выкладывать.
Для этого мало iOS-аккаунта. Заказчик должен предоставить ключи, сертификат разработчика и Provision Profile. Ключи и сертификат нужны, чтобы AppStore идентифицировал разработчика, который будет деплоить сборку. Provision Profile — чтобы он ее подписал. Без этого нужный аккаунт не примет сборку. У Google Play всё проще. Нам нужно хранилище .pepk и пароль к нему, если приложение выкладывалось ранее. В ином случае мы это можем создать самостоятельно.
Также нам нужна информация о приложении, в которую входит его описание, почта для обращений, ссылка на политику конфиденциальности, скрины экранов и много чего еще.
Release Note (что нового в сборке), согласованное с заказчиком. Release Note нужно запрашивать заранее, обычно про него вспоминают в последнюю очередь. Иногда бывает, что всё готово, но заказчик никак не согласует — ушел в отпуск или про не на связи. Это тормозит весь процесс.
Данные тестового аккаунта. Если есть аккаунт пользователя, то нужно предоставить тестовые данные, чтобы ревьюер мог авторизоваться и полноценно проверить приложение.
Подготовка к деплою
Теперь мы знаем все азы, пришло время для подготовки. Готовиться к деплою мы начинаем за 3–4 недели до того, как закончим разработку приложения. Почему так рано? Сам процесс деплоя лежит на нас, но создание аккаунтов, их оплата, информация о приложении — на заказчиках, а они могут затянуть.
Первое, что нужно сделать, — скинуть заказчику инструкцию по созданию аккаунта. Чтобы ему было комфортно и легко, мы даем подробную инструкцию со ссылками и скринами. Задача заказчика — создать пустой аккаунт и оплатить его, а мы уже сами его заполним и добавим сборку.
Я уже упомянул, что оплатить картой РФ аккаунт сейчас возможности нет. Поэтому заказчикам приходится выкручиваться. Мы стараемся облегчить им процесс: добавили в инструкцию пару популярных сервисов для оплаты аккаунтов в сторах.
Также на этом этапе мы запрашиваем информацию о приложении. Частично мы собираем ее сами, частично ее подготавливает заказчик.
Не забываем про ключи, сертификат и Provision Profile для AppStore. Этот этап тоже не всегда проходит гладко. Например, головной офис одного из наших заказчиков не в России. При этом мы общаемся с его представителями. Те в свою очередь общаются с заказчиком через чат поддержки. В общем, всё сложно. А нам, например, нужно добавить тестировщиков в аккаунт AppStore, чтобы у них был доступ к TestFlight.
Ну и в самом конце нам нужно собрать сборки, которые мы будем добавлять в сторы. Для iOS это .ipa, а для Google — .aab. Rustore и AppGalery принимают .apk-файлы.
Кроме того, могут появиться непредвиденные обстоятельства. Например, недавно мы обсуждали перевод бэка на сервер заказчика на одном из проектов. До деплоя оставалось три дня. Но на встрече выяснилось, что у заказчика на этот перевод уйдет не меньше недели. Соответственно, весь процесс притормаживается.
Тестирование
Если речь про Flutter для Android, то тут со сборками всё понятно — мы можем просто передавать тестировщику .apk-файл.
Но с iOS всё сложнее. Для тестирования нужен аккаунт в AppStore, и когда он создан, мы можем добавлять сборку в TestFlight. После этого тестировщику нужно установить приложение, которое имитирует установку сборки из стора.
Поэтому нужно держать в голове, что сборка под iOS перед первым деплоем будет тестироваться, только когда заказчик создаст аккаунт в AppStore, даст нам необходимые ключи и сертификаты. Поэтому и важно заранее попросить заказчика создать аккаунт.
Когда у нас нет проблем с доступами, мы можем загрузить наши сборки в TestFlight и FireBase и проверить, корректно ли они устанавливаются и открывается ли приложение на телефоне.
Проверка сборки и деплой
Наконец всё готово, и мы можем деплоить сборку, но есть важное правило:
Мы не раскатываем приложение на пользователей перед выходными и праздниками!
Это опасно, потому что у всех выходные и в случае серьезных ошибок некому будет остановить внедрение. Приложение будет работать с ошибками вплоть до начала рабочей недели. К тому же стоит учитывать, что первый деплой обычно проходит проверку дольше остальных.
Как происходит процесс деплоя:
Мы добавляем сборки на проверку. При добавлении нужно указать процент внедрения в Google Play, то есть на какое количество пользователей опубликовать приложение. Мы обычно указываем 20 процентов. Это нужно, чтобы мы посмотрели на аналитику, крашится ли приложение, есть ли еще какие-то проблемы.
В AppStore нельзя указать количество пользователей в процентах, но возможность поэтапной раскатки на пользователей с ее остановкой есть.
В целом все платформы проверяют сборки на соответствие их правилам и политикам, требованиям безопасности и конфиденциальности, качества и стабильности приложения.
Когда проверка прошла, мы уведомляем об этом заказчика, а после его ока публикуем сборку.
Дальше мы ждем в среднем 1 день, когда наши 20% пользователей Android установят приложение и начнут им пользоваться.
Если никаких проблем нет, мы пишем заказчику, что у 20% никаких проблем не было, и согласовываем 100% раскатку.
На этом деплой завершен, но нам всё равно нужно периодически посматривать на аналитику.
Блокировка аккаунта и отклонения сборок
Сборку могут отклонить, и причины у этого разные. Первая и главная — человеческий фактор. Иногда ошибки можем допустить мы сами, а иногда ошибиться могут ревьюеры. Тут важно помнить, что сборки проверяются живыми людьми. Вот несколько сценариев того, что может пойти не так:
AppleStore часто отклоняет сборки, когда мы добавляем новые фичи, но забываем добавить для них текст пермишенов. Например, если мы добавляем метрику или работу камеры.
На моем веку блокировали дважды. Первый раз — потому что ревьюерам показалось, что в приложении пропаганда алкоголя, хотя было как раз наоборот. Второй раз — из-за санкций.Из забавного — пару раз не пропускали приложение и, когда мы спрашивали о причинах, писали что-то вроде «я не нашел, где это, объясните, где посмотреть, и я апрувну» или «ой, я забыл включить интернет на устройстве».
Google Play может отклонить сборку, если им не нравится использованные SDK. Например, SDK Яндекса или библиотеки Huawei. Также с недавних пор политику конфиденциальности, на которую должна быть ссылка, нужно верстать, PDF больше не подходит.
Конфликт с политикой контента: приложение могут отклонить, если оно содержит контент, который нарушает правила площадки. Обычно в этих случаях речь идет о непристойном содержании, жестокости, дискриминации и подобных, зачастую запрещенных законом штуках.
Недосмотр: сборку отклонят, если мы забудем дать доступы к тестовому аккаунту и ревьюер не сможет войти в аккаунт.
Несоответствие техническим требованиям или плохая производительность.
Самые частые причины для блокировки аккаунта на нашей практике:
Санкции.
Внешние причины. Например, в 2022 году начали массово блокировать аккаунты разработчиков из Беларуси. Это говорит о том, что блокировка может быть неожиданной и не вполне оправданной.
Если аккаунт заблокировали, у нас только один вариант: подать апелляцию и доказательно объяснить, почему блокировка была несправедливой.
Альтернативное решение — PWA
Если приложение заблокировали, или если вы знаете, что его заблокируют, или если заказчик просто не хочет заморачиваться со сторами, есть вариант обернуть приложение в PWA.
Эта технология позволяет веб-приложению имитировать работу мобильного приложения. При этом в нем будут наиболее популярными фичи, такие как пуш-уведомления. А кнопку «Установить» можно добавить куда угодна, включая сайт заказчика.
Надеюсь, статья поможет вам избежать тех проблем, с которыми мы когда-то сталкивались. Если у вас будут вопросы — задавайте в комментариях, попробую ответить. А в целом про Flutter много пишет мой коллега Саша Ворожищев у себя в телеге.
