Мобильное приложение

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

Главная сложность мобильной разработки

В отличие от веб-релиза, мобильный релиз представляет собой раздачу на тысячи независимых устройств, и каждое устройство забирает обновление тогда, когда решит само. На этом пути стоят два барьера, которые вам не подчиняются: проверка магазина и привычка пользователя обновляться. Скачанную версию отозвать нельзя. Отката не существует, есть только публикация следующей версии, а она снова проходит проверку. Отсюда следуют три вывода: сервер обязан оставаться совместимым со старыми клиентами, которые вы уже не измените; приложение должно уметь сказать пользователю, что эта версия больше не поддерживается; а ошибки в поле должны быть видны удалённо, потому что пользователь не сообщает об ошибке, он удаляет приложение. Если эти три вещи не заложены в первый релиз, позже они обходятся дороже.

Какие решения принимаются в мобильном проекте

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

Выбор между кроссплатформенной и нативной разработкой

Flutter и React Native собирают iOS и Android из одной кодовой базы; Swift и Kotlin пишут каждую платформу отдельно. Решение определяют три критерия: насколько приложение обращается к возможностям устройства (камера, Bluetooth, фоновая геолокация), сколько платформенного ощущения требует интерфейс и кто будет сопровождать приложение после передачи. Содержать одну команду вместо двух чаще всего оказывается решающим для деловых приложений. Проект Welldone служит примером этой стороны: полевое приложение написано на Flutter, панель управления на React, сервисы на .NET. В поле требовалось сканирование QR-кода для поштучной упаковки и мгновенный статус заказа, а не платформенное взаимодействие. Выбор кроссплатформы при этом не означает, что нативного кода не будет вовсе. Разрешения, регистрация уведомлений и фоновое поведение разбираются на каждой платформе отдельно.

Контракт с бэкендом и совместимость версий

API мобильного приложения является контрактом, и на другой его стороне находится клиент, которого вы не можете обновить. В вебе интерфейс и сервер выкатываются вместе, на мобильных так не выходит. Отсюда правило: поле не удаляется, поле не переименовывается, новое обязательное поле не добавляется. Если изменение необходимо, добавляется новое поле, а старое какое-то время продолжает заполняться, и версия, на которой заполнение прекращается, фиксируется письменно. Сервер также должен уметь сообщить минимальную поддерживаемую версию приложения, потому что решение закрыть окно поддержки принимается на сервере, а не в клиенте. И в Togodo, и в Welldone напротив мобильной части стоят сервисы на .NET. Когда проблема заключается не в контракте, а в нагрузке, то есть в числе одновременных пользователей и стоимости запросов, работа уходит с мобильной стороны в Масштабирование бэкенда.

Работа офлайн и синхронизация

Офлайн не является функцией, которую добавляют потом: это решение, меняющее модель данных с самого начала. При описании объёма отвечают на три вопроса. Какие экраны открываются без соединения? Запись, сделанная без сети, ставится в очередь или блокируется? Чья версия побеждает, когда одну и ту же запись меняют два устройства в разное время? Если ответ на третий вопрос не записан, данные портятся молча, и замечают это через месяцы. Поддержка офлайна означает небольшую локальную базу и слой синхронизации внутри приложения, и это настоящая статья затрат. В полевых приложениях, которые работают на складах, в подвалах и в машинах, где связь ненадёжна, пропуск этой статьи заканчивается тем, что приложением просто не пользуются. Внутри офиса та же поддержка бывает лишней сложностью, поэтому решение следует за потребностью, а не за умолчанием.

Уведомления и фоновые задачи

Push-уведомление не является функцией приложения: это цепочка из вашего сервера, служб уведомлений Apple и Google, устройства и операционной системы, за которой остаётся последнее слово. Уведомление может потеряться на любом звене: пользователь откажет в разрешении, система задержит доставку ради экономии батареи, устройство будет выключено. Поэтому ни один рабочий процесс не опирается только на уведомления; пользователь, пропустивший уведомление, должен увидеть ту же информацию, когда откроет приложение. Фоновые задачи тоже ограничены. Операционная система будит приложение тогда, когда решит сама, а не когда нужно вам, и функция, построенная на фоновой задаче с расчётом на регулярный запуск, работает на тестовом устройстве и отказывает в поле. Проект Togodo служит примером здесь: для приложения социальных мероприятий были разработаны обмен сообщениями в реальном времени и push-уведомления.

Публикация в магазинах и причины отказа

App Store и Google Play представляют собой два разных процесса с разными правилами, формой проверки и сроками. В календаре релиза время проверки стоит отдельной строкой, потому что оно вам не подчиняется, а первая отправка обычно оказывается самой медленной. Частые причины отказа можно снять заранее: неполная или расходящаяся с фактами декларация о приватности, отсутствие способа удалить аккаунт, отсутствие рабочего тестового аккаунта для проверяющего, обязательный вход без обоснования, разрешения, запрошенные без поясняющего текста, и неполные материалы страницы магазина. Каждая из них, исправленная постфактум, стоит целого круга проверки, поэтому все они входят в чек-лист перед отправкой. Сама страница в магазине тоже входит в поставку: заголовок, описание, ключевые слова, скриншоты. Автоматическая сборка сокращает цикл; в проекте Welldone автоматизация CI/CD построена на Jenkins, а подробности относятся к разделу DevOps и CI/CD.

Принудительное обновление и необратимость релиза

Механизм минимальной поддерживаемой версии закладывается в первый релиз, а не добавляется позже. Работает он просто: при запуске приложение сообщает серверу свою версию, сервер отвечает, поддерживается ли она, и если нет, пользователь видит блокирующий экран со ссылкой на магазин. Без этого механизма вывести старую версию из обращения нечем, остаётся только ждать. Когда механизм есть, им пользуются сдержанно, потому что принудительное обновление останавливает человека посреди работы: его берегут для уязвимостей, для ошибок, портящих данные, и для изменений контракта, которые больше нельзя поддерживать. Поэтапная раскатка служит вторым предохранителем: версия открывается части пользователей, вы следите за долей падений и останавливаете раскатку, если дело идёт плохо. Остановка защищает только тех, кто ещё не установил. Поэтому отчёты о падениях и ошибках включаются вместе с первым релизом: узнать о проблеме в поле из отзывов в магазине означает узнать о ней позже всех.

Почему старые версии становятся проблемой

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

Объём сопровождения после релиза

Сопровождение на мобильных не сводится к исправлению ошибок. Мобильное приложение перестаёт работать со временем, даже если к его коду никто не прикасается, потому что почва под ним меняется несколько раз в год. Календарь состоит из постоянных пунктов: изменения поведения в ежегодных крупных выпусках операционных систем, правила магазинов о целевой версии сборки и декларациях приватности, истекающие сертификаты подписи и профили обеспечения, обновления сторонних библиотек. Когда срок сертификата истекает, приложение продолжает работать, но новую версию опубликовать уже нельзя, то есть вы теряете саму способность чинить ошибки. Рядом стоит постоянное наблюдение: отчёты о падениях, записи о зависших экранах и отзывы в магазине. Отзыв в магазине служит не маркетинговым показателем, а источником сведений об ошибках. Принять действующее приложение и развивать его тоже относится к обычной работе. В Togodo имевшееся приложение было работоспособным, но экраны управления мероприятиями, сообщений и профиля пользователя имели пробелы: для действующей платформы спроектировали новые экраны, разработали обмен сообщениями в реальном времени и выполнили работы по SEO и ASO (оптимизации видимости в магазинах приложений).

Как мы выбираем правильный формат

Решение опирается на четыре вопроса. Если задачу способен закрыть браузер, то есть нужно показать содержимое, собрать форму или представить отчёт, адаптивное веб-приложение выходит в свет быстрее и не ждёт проверки магазина. Если спрос ещё не проверен, проверка проходит сначала в разделе разработка MVP, потому что присутствие в магазине не служит доказательством спроса. Если это внутренний инструмент с известным кругом пользователей и сценарий не требует камеры, сканирования QR, работы офлайн или доступа к оборудованию, веб-панель приводит к результату быстрее. Если единственная причина в уведомлениях, сначала оцениваются почта, SMS и веб-уведомления, потому что брать на себя актив, требующий постоянного сопровождения ради одного канала, дорогое решение. Как только ответы на эти четыре вопроса найдены, правильный формат становится очевиден сам собой.

Аккаунты, ключи подписи и передача

Владение на мобильных состоит не только из исходного кода: это ещё аккаунты и ключи. Аккаунты магазинов открываются на имя вашей компании, потому что страница приложения, отзывы, оценки и история загрузок привязаны к аккаунту, а перенос аккаунта представляет собой отдельную работу. Ключи подписи важны ещё сильнее. При потере ключа подписи Android или сертификатов iOS обновить ту же страницу магазина невозможно: пользователям придётся установить новое приложение, то есть вы теряете накопленную базу. Поэтому ключи с начала проекта хранятся там, где вы их контролируете. Исходный код лежит в вашем репозитории со всей историей, а сервер и база данных работают на аккаунтах, открытых на ваше имя. Документ передачи тоже входит в поставку: как приложение собирается локально, как отправляется в магазины, какие разрешения запрашиваются и зачем, какова политика минимальной поддерживаемой версии.

Два работающих приложения

Два проекта ниже работают; подробности каждого лежат на его собственной странице в разделе историй успеха.

• Welldone: Полевое приложение на Flutter, панель управления на React и сервисы на .NET для промышленной прачечной. Заказы, отгрузка, размещение на стеллажах и упаковка собраны на одной платформе; в поле сканируют QR-код и упаковывают поштучно, статус заказа обновляется мгновенно, общение команды идёт через ту же платформу. Инфраструктура построена на .NET и MySQL, автоматизация CI/CD выполнена на Jenkins. Приложение Welldone Helper доступно для загрузки в App Store и Google Play.
• Togodo: Действующее приложение социальных мероприятий было доработано. Спроектированы новые экраны для списка мероприятий, профилей и управления сообществом; пользователи создают мероприятия, присоединяются к ним и приглашают друзей. Разработаны обмен сообщениями в реальном времени и push-уведомления, выполнены работы по SEO и ASO, а улучшения производительности исправили поведение под высокой нагрузкой. Мобильная часть на Flutter, серверная на .NET.