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