Принципы основаны на известной методологии от heroku, адаптированы под реалии айос разработки (Отсутствие контейнеров, ревью которые занимают несколько дней и тормозят развертывания, работа Xcode только на маке). Эта статья является коротким введением, полную серию можете найти на iOS-factor, так же доступен русский перевод. Проект iOS-factor с открытым исходным кодом на github, постоянно дорабатывается и приветствует новые идеи. Я так же принял участие в его развитии. Проект основан Феликсом который является создателем fastlane. Приложение объявляет все свои зависимости полностью и точно с помощью манифеста декларации зависимостей.
Это включает себя конкретную версию Swift, Xcode, CocoaPods, Carthgae и Fastlane. Так же все зависимости в podfile и cartfile должны указать конкретную версию. Одним из преимуществ явного объявления зависимостей является то, что это упрощает настройку приложения для новых разработчиков. С помощью указание конкретных зависимостей, вы сможете воспроизвести билд который использовался 6 месяцев назад, зная что он соберется потому что билд будет использовать такую же версию Xcode, CocoaPods и Swift. Ограничение — Поскольку разработка iOS не может быть заключена в контейнер, как это уже используется для веб-разработки, мы ограничены сторонними инструментами, пытающимися выполнить это требование, пока Apple не предоставит официальное решение. Существует стороннее коммерческое (закрытое) решение, называемое Veertu это позволяет вам создавать виртуальные среды MacOS на оборудовании Apple. Код не зависит от окружения, а конфигурация зависит. Поэтому код должен храниться в репозитории, а конфигурация в окружении. Проверкой того, правильно ли разделены конфигурация и код приложения, является факт того, что кодовая база приложения может быть в любой момент открыта в свободный доступ без компрометации каких-либо приватных данных. Существует множество способов ввода значений конфигурации во время сборки Поскольку развертывания на платформе iOS значительно медленнее, чем на серверах, вам может потребоваться способ обновления конфигурации по воздуху (OTA — over the air) для быстрого реагирования на проблемы. Обновления конфигурации OTA позволяют вам мгновенно: Некоторые потенциальные подходы при реализации OTA-обновлений: Исторически существуют значительные различия между разработкой (разработчик делает живые изменения на локальном развёртывании приложения) и работой приложения (развёртывание приложения в App Store с доступом к нему конечных пользователей).
Эти различия проявляются в трёх областях: Решение: Как описано в принципе Зависимости, репозиторий кода должен включать все зависимости, необходимые для создания, тестирования и развертывания iOS приложения. К сожалению, из-за того, что Xcode должен работать на MacOS, мы не можем использовать контейнеры как на вебе. Запуск macOS в виртуальной среде сопряжен с техническими и юридическими проблемами.  Прямо сейчас лучший подход, который мы, разработчики iOS, можем использовать: Многие компании используют концепцию Release trains: расписание, в котором выходит новая версия вашего приложения. Весь код, который был объединен с вашей основной веткой (master или release) в тот момент, когда релизный поезд «уходит» будет отправлен в App Store. Этот подход реализуется большинством крупных приложений для iOS. В последние годы некоторые группы разработчиков начали использовать подходы, которые требуют меньше усилий по разработке, за счет снижение качества user experience, перенеся больше логики на бэкэнд и сделав приложение iOS тонким клиентом, показывающим результаты сервера. Приложение должно выполнять как можно больше бизнес-логики и вычислений на устройстве по целому ряду причин: Если вашему приложению требуется подключение к Интернету для всего функционала (например, приложение для социальных сетей или приложение для обмена поездками), оно должно по-прежнему работать (в режиме только для чтения) без подключения к Интернету для доступа к историческим данным (например, недавние поездки, недавние прямые сообщения). Хотя большинство ваших пользователей будут обновляться до самого последней версии в течение нескольких недель, всегда найдутся пользователи, которые этого не сделают. Это может иметь несколько причин. Часто это связано с используемой версией iOS, которую они не всегда могут обновить из-за возраста устройства. Основная концепция заключается в том, что вы не обновляете существующий API, а вместо этого добавляете новый и позволяете им работать параллельно Версия и номер билда используются вместе что бы идентифицировать конкретное приложение в аппсторе В сегодняшней разработки под iOS нет причин, по которым вы должны вручную менять эти цифры. Вместо этого вам нужна надежная и автоматизированная система, обеспечивающая актуальность версий. Xcode имеет встроенный инструмент под названием agvtool. App Store изначально не допускает откатов, поэтому в этом разделе описывается, как добиться аналогичных результатов, используя доступные способы. Поэтапные релизы — Используя поэтапные выпуски, вы можете медленно выкатить сборку в прод, начиная с маленького количества активных пользователей Однако даже в случае поэтапных выпусков невозможно полностью отозвать сборку: после того, как сборка установлена ​​на устройстве пользователя, единственным способом изменить эту сборку является распространение новой с обновленным номером версии / билда. Как и в случае поэтапных выпусков, сборки App Store и TestFlight можно обновлять, только выполнив следующие действия: Вышеуказанные шаги могут быть выполнены вручную, однако рекомендуется полностью автоматизировать процесс, чтобы иметь возможность быстро реагировать. Альтернатива: “пере-подписать” старую сборку Однако “подпись” приложений iOS часто создает больше проблем, особенно потому, что инструменты командной строки Xcode не предлагают хорошего способа сделать это. Хранение данных и конфигурации в соответствии с рекомендациями Apple имеет решающее значение для жизненного цикла вашего приложения, в частности, когда речь идет о синхронизации iCloud, обновлении до нового телефона и восстановлении телефона из резервной копии. Обязательно следуйте официальным Apple iOS Data Storage Guidelines: Никогда не храните конфиденциальную информацию пользователя (например, пароли или сеансы) в этих директориях. Вместо этого используйте Keychain API. iOS Developer