#ios #xcode #testflight
#iOS #xcode #тестовый полет
Вопрос:
У меня есть одно приложение, но у меня разные серверные части для производства и тестирования, чтобы изолировать данные между ними. Это означает, что когда я загружаю версию приложения в App Store, она заблокирована, указывая либо на тестовую, либо на производственную серверную часть. Поскольку каждая версия приложения, загруженная в App Store, должна быть своей собственной уникальной версией, у меня будут некоторые версии «только для тестирования», которые никогда не будут запущены в производство, а другие — «только для производства». Есть ли лучший способ справиться с этой ситуацией либо в App Store, либо в самом моем Swift-коде?
Комментарии:
1. Почему вы загружаете тестовую версию в AppStore? Это не то, где они принадлежат… Обычно вы делаете это с помощью некоторых флагов сборки в Xcode, которые настраивают серверную часть для сборки, см., Например medium.com/better-programming /… — ваш Swift-код не должен знать об этом, по крайней мере, напрямую.
2. Настройте выбор сервера в каком-нибудь скрытом меню настроек разработчика, которое будет видно только после ввода волшебного пароля или привязки к определенной учетной записи пользователя.
Ответ №1:
После дополнительной работы с TestFlight я остановился на схеме, согласно которой все сборки для одного и того же выпуска используют одну и ту же версию семантического выпуска и просто меняют номер сборки.
Я могу сделать еще один шаг вперед и использовать разные схемы номеров сборок между тестовыми сборками и производственными сборками. Это сделало бы различие между тестовыми и производственными сборками гораздо более четким в рамках TestFlight.
Другим решением, требующим дополнительной настройки, но создающим еще более четкое разделение, было бы создание отдельных приложений в App Store Connect с намерением, чтобы ваши непроизводственные приложения никогда не были выпущены в общедоступный App Store. Я мог бы увидеть, что это отличное решение, если вашему приложению пришлось проходить через несколько тестовых сред. Это повлечет за собой дополнительные накладные расходы (т. Е. Потребуется гораздо больше сборок и отдельных целевых объектов для обслуживания), но вам никогда не придется беспокоиться о случайной отправке версии вашего приложения, серверная часть которой указывает на тестовую среду, а не на производственную среду. Для получения более подробной информации об этом типе решения я рекомендую https://savvyapps.com/blog/using-testflight-to-distribute-multiple-versions-ios-app .
Комментарии:
1. Я знаю, что это немного устарело, но второе решение здесь — это то, что я в итоге использовал. У меня есть настройка нашего приложения «песочница» с собственным идентификатором приложения, сертификатами, профилями и т.д. Когда я создаю свое приложение с помощью CI / CD, у меня есть отдельные ветви кода «main» и «sandbox». Итак, песочница создается для версии моего приложения «test / qa», которая никогда не выпускается в app Store. Как только мы будем удовлетворены, код изолированной среды будет объединен с main, и мы создадим производственное приложение из этой ветки. Никогда эти двое не встретятся. Также у main никогда не будет версии> версии песочницы. Это работает, но да, это немного больше работы