Как "выжить" при разработке мобильного приложения
Рекомендации, представленные в статье, помогут "выжить" при разработке мобильного ПО и будут вам особенно полезны, если вы этой разработкой руководите. Даются советы как относительно архитектуры, так и в плане процессов.
Перед публикацией приложения обязательно пройдите его модерацию заранее. Саму публикацию после модерации в любое время можно спокойно провести. Не забывайте о публикации прила на всех альтернативных сторах. Еще есть понятие частичного апдейта, что позволяет уменьшать вес загружаемого обновления. Всё это влияет на конверсии по загрузке прила, -- вроде бы копейки, но терять их неохота.
Сделайте автосборку разных версий приложения: это придаст мобилке аккуратности и исключит человеческий фактор при сборке для многочисленных сторов, тест- и продакшн-версий с разными ключиками для используемых api в тестовом и продакшн моде.
Это одна из ключевых проблем работы с мобильными прилами -- команды вынуждены тратить ресурсы на поддержку огромного числа уже вышедших версий, если не хотят получить от пользователей хейт и сохранить продажи. Причем хейт от пользователей заразен и снижает конверсию на привлечении новых пользователей. Выкатив новую версию мобилки, нужно быть готовым, что она будет юзаться пользователями минимум год-полтора. Со всеми опечатками и глючащими экрана, которые крешат весь прил (например, платёжная система вдруг начала глючить). Не забываем юзать крешлитикс, чтобы видеть все такие креши.
Как с этим жить?
Выстройте аккуратненькую систему роутинга для всех ключевых экранов -- тогда можно будет меню всего прила забирать с бекенда (с кешированием разумеется). Каждый пункт меню с бекенда приходит с названием, оформлением и статусом о том, рабочий он или нет. Например, при попытке перейти на экран, который вдруг оказался нерабочим, можно на бекенде указать алерт вместо него "Ой! Что-то случилось, но разработчиков уже заперли в офисе и они не выйдут, пока не починят!"
На такое меню можно прикреплять ссылочки на gzip экраны с html, в которых можно обновлять тексты, рекламные и маркетинговые материалы. Ими можно временно замещать нерабочие экраны. Умный прил в прозрачном режиме экраны выкачивает и кеширует у себя, чтобы отображать мгновенно. Не забудьте свериться с политиками аппстора/гуглплея о том, какие экраны можно таким образом загружать.
Обращаясь к бекенду надо бы указывать версию прила, а настроенный хорошими ребятам умный бекенд в ответ передаст ряд алертов, предназначенных для этой версии (например, о том, что в данной версии прила недоступна функция, вышедшая в новых версиях и для их использования прил надо обновить).
С запросами к бекенду надо быть аккуратным -- они по возможности должны быть асинхронными, чтобы сам прил на рендере экранов не тормозил. Такие тормоза ужасно бесят!
На бекенде хорошо бы поставить clickhouse, в котором логировать абсолютно все запросы и ответы мобилки. Очень помогает в расследовании инцидентов.
Переведите все библиотеки, которые возможно, в облако. Многие разработки используют сторонние библиотеки, в том числе и платные. Они могут в любой момент превратить ваш прил в тыкву. А если в это время ещё и аппстор/гуглплей вдруг заблокирует обновление, потребовав какие-то недостащие юридические документы, вечер перестанет быть томным.
Чтобы использование стало безопасным, вы можете библиотеку поставить в виртуалку в облаке и сделать своим собственным небольшим облачным сервисом. iOs виртуалочка будет дорогой и неоправданной, а вот андроидную сам бог велел -- и сам андроид и сам андроидные либы насквозь дырявые -- погружать их в облако можно миллионом разных способов.
Договоритесь с девопсами, чтобы они через кубер регулировали количество инстансов и их балансировку по нагрузке. Таким образом вы избавитесь от громадного геморроя. Ну и от вендор-лока тоже спасете себя -- бизнес будет благодарен!
Например, библиотеки по идентификации людей и валидации паспортов отлично ставятся в такое облако, с которым через бекенд уже взаимодействует мобилка. Если у подобных библиотек есть своя собственная облачная версия, то лучше конечно использовать сразу её.
На уровне архитектуры важно воспринимать всю массу работающих приложений целиком, как неотъемлемую часть системы.
Больше полезных материалов смотрите на моем телеграм-канале: https://t.me/ctorecords.
