5.7 Разработка мобильных приложений

Обзор и мотивация

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

Мобильная среда это отдельная инженерная среда, а не уменьшенная версия веба или настольного компьютера. Устройство работает в кармане, на батарее, по соединениям, которые то есть, то нет. Экраны малы. Операционная система контролирует, что ваше приложение может делать. Существуют две доминирующие платформы (iOS от Apple и Android от Google), у каждой свои языки, правила дизайна и магазин. Вы не можете просто поставлять обновление, когда пожелаете, потому что магазин сначала его рецензирует, а пользователи сами выбирают, когда его установить. Эта глава опирается на фронтенд-разработку (глава 5.6), основы UX (глава 5.1) и доступность (глава 5.3) и использует безопасность приложений (глава 4.2) и CI/CD и поставку (глава 8.1).

Значимость для корпораций и государства высока. Корпорации поставляют клиентские приложения и внутренние приложения для собственного персонала, нередко управляемые через управление мобильными устройствами (MDM: центральное программное обеспечение, настраивающее и защищающее корпоративные устройства). Государства строят приложения для граждан для пособий, здравоохранения, идентичности и платежей и должны обслуживать всех, включая людей на старых устройствах и медленных соединениях, по законам о доступности. В обоих случаях мобильная среда серьёзное долгоживущее обязательство, поэтому относитесь к ней с той же строгостью, что и к любой другой производственной системе.

Ключевые принципы

Проектируйте для устройства: малый экран, батарея и сеть, которая то есть, то нет.
Предполагайте прерывистую связь; работайте сначала офлайн и синхронизируйтесь, когда можете.
Уважайте соглашения дизайна и взаимодействия каждой платформы.
Вы не контролируете время выпуска; его контролируют магазин и пользователь.
Фрагментация нормальна; поддерживайте реальный диапазон устройств и версий ОС.
Храните данные на устройстве безопасно, потому что устройства теряются и крадутся.
Доступность требование, а не завершающий штрих.
Выбирайте подход к сборке на всю жизнь приложения, а не только на день запуска.

Рекомендации

Выбирайте подход к сборке намеренно

Существуют три широких подхода, и каждый подходит разным потребностям.

Нативная разработка означает отдельное написание для каждой платформы с её собственными инструментами: Swift для iOS, Kotlin для Android. Вы получаете лучшую производительность, полнейший доступ к функциям устройства и наиболее верное ощущение платформы ценой построения и сопровождения двух кодовых баз.

Кроссплатформенные фреймворки позволяют одной кодовой базе нацеливаться на обе платформы. React Native использует JavaScript и отрисовывает настоящие нативные компоненты. Flutter использует язык Dart и рисует собственные виджеты. Они сокращают дублированные усилия и могут ускорить поставку, но добавляют зависимость от здоровья фреймворка и могут отставать от новейших возможностей платформ.

Прогрессивное веб-приложение (PWA: сайт, который можно установить и который может работать офлайн) не нуждается в магазине и обновляется мгновенно, но имеет ограниченный доступ к некоторым функциям устройства и более слабое присутствие на домашнем экране.

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

Следуйте руководствам по дизайну платформ

У каждой платформы есть опубликованные подробные соглашения. Apple предоставляет Human Interface Guidelines, а Google предоставляет Material Design. Они охватывают навигацию, жесты, типографику, отступы и системное поведение. Следование им делает приложение знакомым, что снижает усилия пользователей на его изучение. Борьба с ними делает приложение чужим и неловким. Кроссплатформенная кодовая база всё равно должна соблюдать соглашения каждой платформы там, где они различаются, а не навязывать вид одной платформы другой.

Проектируйте с учётом мобильных ограничений

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

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

Публикация идёт через Apple App Store и Google Play, у каждого есть процессы рецензии и политики, которые могут задержать или отклонить выпуск. Закладывайте время рецензии в расписание и читайте политики рано. Поскольку пользователи сами выбирают, когда обновляться, у вас всегда будет много версий в поле одновременно. Держите ваше приложение обратно совместимым со старыми клиентами и версионируйте API (глава 2.3), чтобы старое приложение продолжало работать. Предоставьте способ требовать обновление, когда нужно, например запрос принудительного обновления, когда версия небезопасна или не поддерживается, и пользуйтесь им редко. Корпорации также могут распространять внутренние приложения через MDM или частные каналы вместо публичных магазинов.

Используйте push-уведомления и глубокие ссылки осторожно

Push-уведомления позволяют достигать пользователей, когда ваше приложение закрыто. Используйте их для подлинной ценности, уважайте согласие пользователя и разрешения платформы и избегайте шума, потому что люди отключают уведомления приложений, которые заходят слишком далеко. Глубокие ссылки направляют пользователя прямо на конкретный экран по ссылке или уведомлению. Настройте их так, чтобы ссылка открывала нужное место в приложении и изящно откатывалась к вебу, когда приложение не установлено.

Защищайте приложение и его данные

Воспринимайте устройство как недоверенное и возможно потерянное. Храните чувствительные данные в защищённом хранилище платформы (связка ключей iOS или Android Keystore), никогда в простых файлах. Предлагайте биометрическую аутентификацию (отпечаток или лицо) для разблокировки чувствительных действий, подкреплённую кодом доступа. Рассмотрите закрепление сертификатов (проверку того, что сервер предъявляет ожидаемый сертификат) для высокоценных соединений и планируйте ротацию этих сертификатов. Минимизируйте то, что вы храните на устройстве, защищайте секреты и следуйте более широкому руководству по безопасности приложений (глава 4.2).

Стройте настоящий конвейер тестирования и поставки

Тестируйте на реальных устройствах, а не только на эмуляторах и симуляторах, потому что оборудование, датчики и производительность различаются. Используйте лабораторию устройств или облачную ферму устройств для охвата репрезентативного разброса моделей и версий ОС. Автоматизируйте сборки, тесты, подпись и отправку в магазин через непрерывную интеграцию и поставку (глава 8.1), включая бета-распространение тестировщикам до публичного выпуска. Безопасное управление ключами подписи и учётными данными магазина часть этого конвейера.

Сделайте доступность требованием

Поддерживайте функции доступности каждой платформы: программы чтения с экрана (VoiceOver в iOS, TalkBack в Android), динамический размер текста, достаточный цветовой контраст и большие цели касания. Подписывайте элементы управления, чтобы вспомогательные технологии могли их описать. Тестируйте настоящими вспомогательными средствами, а не только автоматическими проверками. Особенно для государства доступность юридический мандат, а подробности живут в главе о доступности (глава 5.3).

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы
Нативный (Swift, Kotlin)	Лучшая производительность, полный доступ к устройству, настоящее ощущение платформы	Две кодовые базы, выше цена, больше персонала
React Native	Одна кодовая база JavaScript, настоящие нативные компоненты, быстрая итерация	Зависимость от фреймворка, сложность мостов, отставание функций
Flutter	Одна кодовая база, согласованный UI, сильная производительность	Навыки Dart менее распространены, больший размер приложения, собственная модель виджетов
Прогрессивное веб-приложение	Нет магазина, мгновенные обновления, одна веб-кодовая база	Ограниченные функции устройства, более слабое присутствие, пределы платформы
Принудительные обновления	Быстро убирают небезопасные старые версии	Раздражают пользователей при злоупотреблении; могут блокировать доступ
Закрепление сертификатов	Сильная защита от перехвата	Ломается, если сертификаты ротируются без обновления приложения

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

Вопросы для обсуждения с командой

Как долго мы поддерживаем старые клиенты в поле и версионирован ли наш API, чтобы они продолжали работать? Поскольку пользователи сами выбирают, когда обновляться, у вас всегда установлено много версий приложения одновременно, а изменение бэкенда, предполагающее, что все актуальны, сломает длинный хвост старых клиентов. Решите окно обратной совместимости, версионируйте ваши API, чтобы старое приложение продолжало работать, и держите редко используемый путь принудительного обновления для версий, действительно небезопасных. Это важно и для приложений граждан, и для приложений корпоративного персонала, где люди на старых устройствах не могут или не хотят обновляться по вашему расписанию. Принесите ваши текущие данные о распределении версий и спросите, что ломается для старейшего клиента, всё ещё в реальном использовании. Если вы не знаете этого распределения, инструментируйте его, прежде чем выпускать следующее ломающее изменение.
Какова наша планка для отправки push-уведомления и кто решает, что стоит прерывания пользователя? Push-уведомления достигают людей, когда приложение закрыто, что делает их мощными и легко поддающимися злоупотреблению, а пользователи отключают уведомления (или удаляют приложение) продуктов, заходящих слишком далеко. Договоритесь, что считается подлинной ценностью, как пользователи управляют частотой и каналом и как вы уважаете согласие платформы, а не донимаете просьбами о разрешении. Без общей планки каждая команда с метрикой для достижения потянется к push, и весь канал выродится в шум. Принесите уведомления, отправленные за последний месяц, и спросите, за какие пользователь поблагодарил бы вас. Если большинство были рекламными, ужесточите политику, прежде чем это сделает доля отказов.
Настоящий ли наш конвейер мобильной поставки, охватывающий подпись, ферму устройств и бета-распространение, или выпуск это стрессовая ручная суматоха? Мобильная среда добавляет опасности, которых нет в вебе: рецензия магазина может задержать или отклонить выпуск, ключи подписи и учётные данные магазина нужно обрабатывать безопасно, а оборудование и датчики различаются достаточно, чтобы эмуляторы скрывали реальные проблемы. Автоматизация сборок, тестов, подписи и отправки в магазин через CI/CD с бета-распространением тестировщикам и облачной фермой устройств, охватывающей модели, которые ваши пользователи действительно носят, то, что превращает выпуски из героизма в рутину. Решите, кто владеет конвейером и ключами подписи и как время рецензии магазина закладывается в каждый план выпуска. Принесите историю вашего последнего выпуска и сосчитайте ручные шаги. Каждый из них место, где стрессовый выпуск может пойти не так под сроком.
Выбрали ли мы нативный, кроссплатформенный подход или прогрессивное веб-приложение на всю жизнь этого продукта или только на день запуска? Подход к сборке самый большой рычаг над ценой и возможностями мобильного приложения на годы, а выбор, сделанный ради быстрой поставки, может поймать вас в ловушку: нативный подход покупает богатейший доступ к устройству и ощущение платформы ценой двух кодовых баз и двух наборов навыков, тогда как кроссплатформенный подход и PWA делят код, но добавляют зависимость от фреймворка или теряют доступ к некоторым функциям устройства. Для большой команды это решение определяет найм, бюджет сопровождения и то, как быстро вы можете принять каждый ежегодный выпуск ОС, поэтому оно заслуживает явного владельца, а не умолчания, заданного тем, кто написал первый прототип. Принесите требуемые функции устройства, профиль производительности, горизонт сопровождения и навыки, которых вы реально можете нанять, и честно скажите, какие возможности платформы вы потеряли бы при каждом варианте. В корпоративной и государственной среде взвесьте, долгоживущее ли это обязательство, которое должно пережить текучесть персонала и десятилетие смены платформ, и запишите решение и его обоснование, чтобы будущей команде не пришлось гадать, почему кодовая база выглядит так, как выглядит.
Какой диапазон поддержки устройств и версий ОС нужен нашим реальным пользователям и тестируем ли мы на оборудовании, которое они действительно носят, а не на телефонах на наших столах? Фрагментация нормальное состояние мобильной среды: пользователи охватывают широкий разброс размеров экранов, мощности устройств и версий ОС, а приложение, настроенное на флагманах команды, выйдет вялым или сломанным на скромном оборудовании, которым владеет значительная часть вашей аудитории. Выбор диапазона поддержки компромисс между охватом и усилиями, потому что каждая более старая модель и версия ОС, поддержку которых вы обещаете, расширяет матрицу тестирования и бремя сопровождения, поэтому диапазон должен исходить из реальных данных об использовании, а не допущений. Принесите ваше распределение устройств и версий ОС, модели, которые сейчас покрывает облачная ферма или лаборатория, и производительность, которую вы измерили на маломощном оборудовании, а не только на симуляторах. Для приложений граждан это почти не подлежит обсуждению, потому что вы должны обслуживать всех, включая людей на старых устройствах и медленных соединениях, по обязательствам доступности, а для корпоративных парков вам следует тестировать точные защищённые аппараты, которые носит персонал, а не обобщённую выборку.
Какие чувствительные данные живут на устройстве и защищён ли каждый кусок от телефона, потерянного, украденного или оказавшегося в чужих руках? Мобильное устройство путешествует в кармане и теряется или крадётся, поэтому любые данные или секрет, хранимые в простом файле, в одном потерянном телефоне от раскрытия, а радиус поражения растёт с каждым пользователем. Соображения тянут друг против друга: кэширование данных на устройстве то, что делает работающим офлайн-первый подход и держит приложение быстрым, но каждый кэшированный элемент обязательство, которое должно лежать в защищённом хранилище платформы (связка ключей iOS или Android Keystore), быть минимизировано и в идеале закрыто биометрией или кодом доступа. Принесите опись того, что именно приложение сохраняет локально, где хранится каждый элемент, что его разблокирует и используют ли высокоценные соединения закрепление сертификатов с рабочим планом ротации. В корпоративной среде свяжите это с политикой управления мобильными устройствами и удалённой очисткой, а в государственной воспринимайте персональные данные на устройстве как экспозицию приватности и закона, которую нужно обосновать, документировать и защитить при аудите.

Взгляд по секторам

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

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

Крупная организация. В масштабе приложение долгоживущее обязательство по многим командам, поэтому стандартизируйте подход к сборке, шаблон защищённого хранилища, конвейер CI/CD и политику версионирования API, а не позволяйте каждому продукту изобретать их заново. Внутренние приложения для персонала обычно идут через управление мобильными устройствами для установки, настройки, удалённой очистки и политики, тогда как клиентским приложениям нужна ферма устройств, покрывающая реальное использование, и проверяемые доступность и безопасность. Управляйте ключами подписи, учётными данными магазина и временем выпуска централизованно, чтобы ломающее изменение бэкенда никогда не оставило без опоры длинный хвост старых клиентов.

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

Примеры

Стартап. Стартап из трёх человек, строящий приложение для отслеживания привычек, должен был достичь и iOS, и Android, но не мог позволить две нативные кодовые базы или два набора навыков. Они выбрали кроссплатформенный фреймворк, чтобы одна небольшая команда могла поставлять в оба магазина, и с самого начала проектировали офлайн-первым, чтобы пользователь мог записать привычку в метро без сигнала и синхронизировать позже. Они держали токен входа в защищённом хранилище платформы, а не в простом файле, закладывали время рецензии магазина в каждый план выпуска и тестировали на паре дешёвых старых телефонов рядом со своими, что поймало вялую производительность, которую они иначе поставили бы.

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

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

Бизнес-обоснование: мотивы, ROI и TCO

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

По совокупной стоимости владения (TCO) выбор подхода самый большой рычаг. Нативный подход означает оплату двух кодовых баз и двух наборов навыков на всю жизнь приложения. Кроссплатформенный подход меняет часть этого на зависимость, которую нужно держать актуальной. Помимо кода закладывайте бюджет на платежи магазинов и циклы рецензии, лабораторию тестирования устройств или облачную ферму, постоянную поддержку версий ОС по мере ежегодных выпусков платформ и работу по безопасности, которой требует мобильная среда. Цена недоинвестирования проявляется в сбоях на неподдерживаемых устройствах, инцидентах безопасности из-за незащищённых данных на устройстве, отклонённых или задержанных выпусках и пользователях, бросающих медленное или неуклюжее приложение.

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

Антипаттерны и ловушки

Воспринимание мобильной среды как уменьшенного сайта: игнорирование касания, жестов и соглашений платформ.
Допущение идеальной сети: нет обработки офлайна, так что приложение ломается в миг, когда пропадает сигнал.
Тестирование только на новейшем флагмане: сокрытие плохой производительности на устройствах, которые носят реальные пользователи.
Хранение секретов в простых файлах: чувствительные данные раскрыты, когда устройство потеряно или украдено.
Перегрузка уведомлениями: слишком много push, так что пользователи отключают или удаляют приложение.
Игнорирование времени рецензии магазина: планы выпуска, предполагающие мгновенную публикацию и затем срывающиеся.
Нет пути принудительного обновления: небезопасные старые версии живут дальше без способа их вывести.
Разряд батареи и трафика: постоянная фоновая работа и болтливая сеть, которые замечают пользователи.
Доступность как запоздалая мысль: исключение пользователей и, для государства, нарушение закона.
Одна кодовая база, принуждённая выглядеть одинаково везде: приложение, ощущаемое чужим на обеих платформах.

Модель зрелости

Уровень 1: Начальный. Мобильная работа стихийна и реактивна. Приложение построено как сайт, протестировано на собственных телефонах команды и нередко ломается офлайн. Мало думают о защищённом хранении, доступности или сроках рецензии магазина. Выпуски стрессовая ручная суматоха, и никто не владеет подходом к сборке или ключами подписи.

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

Уровень 3: Стандартизация. Хорошая практика документирована и принуждается по организации. Офлайн-первый подход по умолчанию, документированный диапазон поддержки устройств тестируется в лаборатории устройств или облачной ферме, а руководства по дизайну платформ и доступность соблюдаются и проверяются настоящими вспомогательными средствами. Защищённое хранилище, биометрия и версионирование API стандарт, CI/CD автоматизирует сборки, тесты, подпись и бета-распространение, а время рецензии магазина планируется в каждом выпуске.

Уровень 4: Управление. Качество мобильной работы измеряется и контролируется относительно базовых значений. Сбои, холодный запуск и производительность отрисовки экрана, расход батареи и трафика и доли завершения задач непрерывно собираются с реальных устройств и отслеживаются относительно целей, с разбивкой по моделям и версиям ОС, чтобы регрессия на маломощном оборудовании ловилась, а не поставлялась. Доступность и безопасность проверяются, а не предполагаются, доли отказа от уведомлений и принятия обновлений мониторятся, а диапазон поддержки и подход к сборке пересматриваются по этим свидетельствам. Решения «исправить или убрать» для выпуска опираются на метрики, а не на то, как приложение ощущалось на телефоне лидера.

Уровень 5: Оркестрация. Мобильная работа непрерывно улучшается и интегрирована по организации и адаптируется по мере сдвигов ландшафта устройств. Ротация сертификатов, пути принудительного обновления и откат рутинны, диапазон поддержки и подход к сборке пересматриваются по свидетельствам по мере ежегодных выпусков платформ, а весь разброс пользователей и устройств воспринимается первоклассным. Мобильное планирование состыковано с безопасностью, доступностью, API и практикой поставки, так что изменение ОС, новый уровень устройств или сдвиг политики поглощается как рутинная работа, а не авария.

Идеи для обсуждения

Как решить между нативным, кроссплатформенным подходом и прогрессивным веб-приложением для данного продукта?
Какой диапазон поддержки устройств и версий ОС подходит вашим реальным данным о пользователях и как держать его актуальным?
Где офлайн-первый подход существен в вашем приложении и как вы будете обрабатывать конфликты синхронизации?
Когда оправдано принудительное обновление и как избежать несправедливой блокировки пользователей?
Как вы будете тестировать на реальных устройствах в масштабе, отражающем ваших пользователей?
Какие чувствительные данные живут на устройстве и как защищён каждый кусок?
Как соблюдать соглашения каждой платформы из общей кодовой базы?

Главные выводы

Выбирайте подход к сборке (нативный, кроссплатформенный или PWA) на всю жизнь приложения.
Следуйте руководствам по дизайну платформ, чтобы приложение ощущалось знакомым и снижало усилия пользователя.
Проектируйте под мобильные ограничения: офлайн-первый подход, экономия батареи и трафика, фрагментация, малые экраны.
Вы не контролируете время выпуска; планируйте рецензию магазина, версионирование и принудительные обновления.
Используйте push-уведомления и глубокие ссылки сдержанно и с согласия.
Защищайте данные на устройстве защищённым хранилищем, биометрией и, где оправдано, закреплением сертификатов.
Тестируйте на реальных устройствах и автоматизируйте мобильный конвейер через CI/CD.
Делайте доступность требованием, что для государства юридический мандат.

Источники и дополнительное чтение

Apple, Human Interface Guidelines
Google, Material Design guidelines
Apple, App Store Review Guidelines
Google, Google Play developer policies and Android developer documentation
OWASP, Mobile Application Security Verification Standard (MASVS) and Mobile Security Testing Guide
React Native project documentation
Flutter project documentation
Google, web.dev guidance on progressive web apps
U.S. Section 508 and WCAG (Web Content Accessibility Guidelines) references for mobile accessibility
NIST, Guidelines on mobile device security and management