Каждой теме соответствует фактор, описывающий идеальное состояние разработки приложений для iOS.

Это чувство, когда вы берете старый проект из Git, а он не компилируется ...

Несмотря на то, что этот проект находится в App Store, готовый к производству, предыдущий разработчик не поддерживал его должным образом. Возможных причин множество - устаревшая версия Swift, внешние зависимости, отсутствие сертификатов…

iOS-фактор был вдохновлен знаменитой Двенадцатифакторной платформой приложений,
методологией написания высококачественных веб-сервисов. iOS-фактор использует ту же структуру и аналогичные принципы, переписанные и примененные к процессам разработки iOS-приложений.

Его цель - предоставить сборник лучших практик для создания высокопроизводительных приложений для iOS.

Каждая тема покрывается фактором, который описывает идеальное состояние того, как может выглядеть определенная категория процесса разработки приложения для iOS.

Эта статья представляет собой резюме. Вы также можете прочитать полную серию. Проект стартовал Феликс Краузе.

TL;DR

  1. Зависимости: явное объявление и изоляция зависимостей.
  2. Конфигурация: без конфигурации в коде, поставляется с конфигурацией по умолчанию и позволяет обновлять OTA.
  3. Девелопер / продакшн: старайтесь, чтобы разработка, тестирование и производство были как можно более похожими.
  4. Развертывание: автоматизируйте развертывание, чтобы вы могли выпустить его с любой машины.
  5. Предпочитать локальное удаленному: приложение iOS должно быть достаточно интеллектуальным, чтобы работать без серверной части, где это возможно.
  6. Обратно совместимые API.
  7. Управление версиями приложений: автоматизируйте сборку вашего приложения и номера версий для единообразия.
  8. Откаты: откат сборки, которая вызывает проблемы.
  9. Сохранение данных: следуйте рекомендациям Apple при хранении данных.

1. Зависимости

В идеале ваши инструменты сборки никогда не полагаются на неявное существование общесистемных пакетов.

Он полностью и точно объявляет все зависимости через манифест объявления зависимостей. Сюда входят точные версии Xcode, CocoaPods и fastlane.

Преимущество явного объявления зависимостей заключается в том, что оно упрощает настройку для разработчиков, которые не знакомы с приложением, а также имеет надежную систему сборки, которая также может повторно запускать прошлые сборки с воспроизводимым образом.

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

2. Конфигурация

Иногда приложения хранят конфигурации как константы в коде. Это нарушение iOS-фактора, которое требует строгого отделения конфига от кода. Конфигурация существенно различается в зависимости от развертывания, а код - нет.

Есть много способов ввести значения конфигурации во время сборки:

  • Файлы конфигурации (например, файлы JSON или YAML).
  • CocoaPods-keys, чтобы правильно скрыть ключи и применить их к вашему приложению iOS во время сборки.
  • Индивидуальное решение (например, с использованием фазы сборки).

Поскольку развертывание на платформе iOS происходит значительно медленнее, чем развертывание сервера, вам может потребоваться способ быстрого обновления конфигурации по беспроводной сети (OTA), чтобы быстро реагировать на проблемы.

Обновления конфигурации OTA являются мощными и позволяют мгновенно:

  • Запустите A / B-тесты, чтобы включить определенные функции или изменения пользовательского интерфейса только для части ваших активных пользователей.
  • Поверните ключи API.
  • Обновите веб-хосты или другие URL-адреса, которые изменились.
  • Удаленно отключать функции или скрывать кнопки.

Возможные подходы к внедрению OTA-обновлений конфигурации:

  • Реализуйте собственное решение.
  • Фирменные веб-сервисы, такие как Firebase Remote Config.
  • Сервис с открытым исходным кодом вроде FeatureFlags.

3. Паритет разработчиков и продуктов

Исторически сложилось так, что между разработкой (разработчик вносит изменения в приложение на своем локальном компьютере в режиме реального времени) и производством (приложение, развернутое в App Store, доступ к которому получают конечные пользователи) имел место существенный разрыв.

  • Временной разрыв: разработчик может работать над кодом, на запуск которого уходит дни, недели или даже месяцы.
  • Нехватка персонала: все разработчики iOS пишут код, только один человек знает, как развернуть приложение.
  • Пробел в инструментах. Разработчики могут использовать промежуточный сервер, на котором работает версия, отличная от производственной. Разработчики могут использовать версию Xcode, отличную от той, которая использовалась для развертывания.

Приложение с iOS-фактором предназначено для непрерывного развертывания за счет сохранения небольшого разрыва между разработкой и производством.

Глядя на три описанных выше пробела:

  • Сделайте временной промежуток небольшим. Разработчик может написать код и развернуть его всего через несколько дней.
  • Сделайте кадровый разрыв небольшим. Разработчики, написавшие код, активно участвуют в его развертывании и наблюдают за его поведением в производственной среде. Наилучшим образом это становится возможным благодаря полной автоматизации процесса выпуска вашего приложения для iOS и размещению ноу-хау в объявлениях кода вместо документации.
  • Сделайте зазор между инструментами небольшим. Делайте разработку и производство как можно более похожими. Следуйте принципам фактора зависимости iOS-фактора и используйте файл .xcode-version, а также явно определяйте все остальные зависимости.

4. Развертывание

Как описано в факторе зависимости, репозиторий кода должен включать все зависимости, необходимые для сборки, тестирования и выпуска приложения iOS.

К сожалению, поскольку Xcode должен работать на macOS, мы не можем использовать Docker или контейнеры.

На данный момент лучший подход, который мы можем использовать, как разработчики iOS, - это:

  • Автоматизируйте установку Xcode с помощью Xcode :: Install.
  • Используйте файл .xcode-version, чтобы указать точный выпуск Xcode.
  • Определите все зависимости в файлах конфигурации (см. Фактор d ependencies).
  • Автоматизируйте весь процесс развертывания с помощью инструмента развертывания, такого как fastlane.
  • Автоматическая подпись кода (например, codeigning.guide).
  • Выполняйте развертывание часто, в идеале по еженедельному графику.

5. Предпочитайте локальное перед удаленным

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

Такой подход приводит к разочарованию пользователя, когда приложение используется в ситуации с неидеальным интернет-соединением.

Приложение должно выполнять как можно больше бизнес-логики и вычислений на устройстве по ряду причин:

  • Конфиденциальность: избегайте отправки данных на удаленный сервер.
  • Скорость: отправка данных на сервер и ожидание ответа требует времени и может привести к сбою (например, нестабильный WiFi).
  • Использование данных: пользователи часто имеют ежемесячные лимиты данных.
  • Масштабирование: если ваше приложение становится вирусным, вы несете ответственность за масштабирование серверных служб.
  • Срок службы батареи: использование мобильных данных требует значительных затрат для срока службы батареи.
  • Надежность: в некоторых странах по-прежнему существуют ненадежные соединения LTE / 3G.

Если вашему приложению требуется подключение к Интернету для всего (например, приложения социальной сети или приложения для совместного использования), ваше приложение все равно должно работать (в режиме только для чтения) без подключения к Интернету для доступа к историческим данным (например, недавние поездки, недавние прямые сообщения) .

6. Обратно совместимые API

Хотя большинство ваших конечных пользователей обновят последнее обновление в течение нескольких недель, всегда найдется подмножество пользователей, которые этого не сделают.

Основная концепция заключается в том, что вы не обновляете существующий API, а вместо этого добавляете новый и позволяете им работать параллельно.

https://your-api.com/1.0/drivers.json
https://your-api.com/1.1/drivers.json

7. Управление версиями приложений

Номера версий и сборки работают вместе, чтобы однозначно идентифицировать конкретную отправку приложения в App Store :

  • Номер версии (CFBundleShortVersionString) - отображается как Version в Xcode. Ее также называют маркетинговой версией: версия, которая видна конечному пользователю. Он должен увеличиваться с каждым выпуском общедоступного магазина приложений.
  • Номер сборки (CFBundleVersion) - отображается как Build в Xcode: увеличивающийся номер.

В сегодняшнем процессе разработки для iOS нет причин изменять эти числа вручную.

Нет необходимости использовать сторонние инструменты, в Xcode есть встроенный инструмент agvtool. (Подробнее).

8. Откаты

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

Используя поэтапные выпуски, вы можете постепенно развертывать сборку в производственной среде, начиная с подмножества активных пользователей.

Основное преимущество этого подхода - встроенный способ приостановить развертывание до того, как оно достигнет большого количества пользователей, что позволяет заменить двоичный файл.

Однако даже с поэтапными выпусками невозможно полностью отозвать сборку.

Как и в случае поэтапных выпусков, сборки App Store и TestFlight можно обновить только следующим образом:

  1. Вернитесь в своей системе управления версиями в состояние, к которому вы хотите выполнить откат.
  2. Увеличьте номер версии или сборки вашего проекта.
  3. Создавайте и совместно разрабатывайте свое приложение.
  4. Распространяйте свое приложение через службу бета-тестирования или в App Store.
  5. Пользователь должен обновить приложение на своем телефоне.

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

Альтернатива: отказаться от старой сборки:

  1. Получите доступ к старой сборке (.ipa файл) до того, как была введена регрессия.
  2. Обновите номер версии / сборки в файле Info.plist.
  3. Отказаться от сборки.
  4. Распространяйте его как новую сборку.

Однако отказ от приложений iOS часто создает больше проблем, особенно потому, что инструменты командной строки Xcode не предлагают хорошего способа сделать это.

9. Сохранение данных

Хранение данных и конфигураций в соответствии с рекомендациями Apple имеет решающее значение для жизненного цикла вашего приложения, особенно когда речь идет о синхронизации iCloud, обновлении до нового телефона и восстановлении телефона из резервной копии.

Убедитесь, что вы соблюдаете официальные Рекомендации Apple по хранению данных для iOS:

  • Documents: используйте этот каталог для содержимого, созданного пользователями, оно будет зарезервировано.
  • Caches: используйте этот каталог для данных, которые можно регенерировать.
  • tmp: используйте этот каталог для временных файлов.
  • Используйте атрибут do not back up для файлов.

Никогда не храните конфиденциальную информацию пользователя (например, пароли или сеансы) в этих каталогах. Вместо этого используйте API связки ключей.

Заключение

Это живой проект, поддерживаемый сообществом разработчиков iOS.

Вы можете найти полный исходный код на GitHub, обновить существующие страницы или добавить новые факторы.