Как перенести проекты iOS и CI/CD на M1 Mac

Кремниевые процессоры Apple — это революция в мире процессоров для настольных ПК. Переход от архитектуры Intel x86_64 к архитектуре Apple arm64 прошел для потребителей довольно гладко благодаря эмулятору Rosetta 2, который позволяет переводить команды x86_64 в arm64 без существенной потери производительности. Однако разработчикам также нужно было полагаться на эмуляцию, потому что, когда новая архитектура была впервые выпущена в конце 2020 года, большинство инструментов и библиотек для разработчиков не поддерживали архитектуру arm64. И это может привести либо к нестабильной работе, либо к сбоям в некоторых случаях.

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

Кроме того, мы не можем не упомянуть, что ваш любимый поставщик CI/CD, компания Codemagic, выпустила для публики первые машины для сборки Mac mini M1! Некоторые из наших клиентов уже опробовали мощные сборочные машины с новыми эффективными чипами, и время сборки значительно сократилось. Итак, давайте обсудим миграцию с Intel на M1: миграцию конвейера CI/CD для вашего проекта со старого доброго x86_64 на новый блестящий arm64.

В этой статье рассматриваются следующие темы:

• Требования

• Работа с новой архитектурой

• Обновление сторонних зависимостей

• Время сборки для Mac mini M1 и Mac Pro

Итак, приступим!

Требования для перехода на M1

На момент написания для переноса ваших рабочих процессов на новую виртуальную машину Apple M1 в Codemagic вы должны использовать Xcode 13.3+, так как он предустановлен в базовом образе машины сборки macOS M1. Xcode 13.3.1 (13E500a) является последней версией и используется по умолчанию, когда вы устанавливаете «13.3», «13.3.1», «edge» или «latest» в файле «codemagic.yaml» или выбираете его в настройки сборки в редакторе рабочих процессов для приложений Flutter.

Когда в 2020 году Apple объявила о выпуске собственного кремния, она начала двухлетний переход на новую архитектуру. Разработчики могут воспользоваться пакетом Developer Transition Kit (DTK) для тестирования, обновления и переноса своих приложений на процессор Apple.

Вначале разработчики использовали эмуляцию Rosetta для использования приложений, созданных для Mac с процессором Intel. Многие зависимости CocoaPods и пакеты Swift были несовместимы с архитектурой arm64 в первые месяцы. Когда разработчики начали переходить и получать новейшие устройства серии M1 и M1 Pro/Max/Ultra, они запросили проекты с открытым исходным кодом и различные SDK для поддержки архитектуры arm64.

Теперь, когда мы находимся почти в конце перехода, многие популярные проекты с открытым исходным кодом, такие как Alamofire, Kingfisher или Firebase SDK, добавили поддержку кремниевых машин Apple. Теперь вам больше не нужно использовать эмуляцию Rosetta в большинстве случаев, и вы можете воспользоваться преимуществами чистой вычислительной мощности эффективных чипов Apple.

Работа с новой архитектурой

В то время как архитектура iPhone уже является «arm64», Intel использовала симуляторы «x86_64». Симуляторы новых устройств серии M1 также работают на архитектуре «arm64».

Apple предоставила [подробную статью] (https://developer.apple.com/documentation/technotes/tn3117-resolving-build-errors-for-apple-silicon) для устранения ошибок построения архитектуры на Apple Silicon.

Xcode уже предоставляет параметры сборки архитектуры по умолчанию, которые помогают вам создавать и поставлять на всех платформах. Одним из параметров является Сборка только активных архитектур, логическое значение со значением по умолчанию Да для отладки и Нет для конфигураций выпуска. Xcode автоматически строится для выбранной архитектуры, если установлено значение Да. Таким образом, если вы используете компьютер Apple Silicon, он строится для симулятора arm64, а если вы работаете с компьютером Intel, он строится для симулятора x86_64.

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

Перейдите к своему проекту, выберите цель и выберите Настройки сборки. В разделе Архитектуры установите для параметра Создать только активную архитектуру значение ДА для отладочных сборок. Это гарантирует, что компилятор сгенерирует двоичный файл только для одной архитектуры.

Сделайте то же самое и для стручков:

Если вы установите значение NO, Xcode создаст проект для всех допустимых архитектур. Однако вы можете увидеть ошибку, которая выглядит примерно так:

Не удалось найти модуль «ColorKit» для цели «x86_64-apple-ios-simulator»; найденный:

arm64-apple-ios-simulator, по адресу: /Users/rudrankriyam/Library/Developer/Xcode/DerivedData/Musadora-ccjzyuildzfnokedenrcjqixspxo/Build/Products/Debug-iphonesimulator/ColorKit.swiftmodule

Установка для параметра Build Active Architecture в Xcode значения YES также значительно сокращает время сборки, поскольку вы компилируете одну архитектуру вместо двух. Это беспроигрышная ситуация для вас!

Обновление сторонних зависимостей

Ваш проект может использовать CocoaPods, Carthage и/или Swift Package Manager для управления сторонними зависимостями.

Управлять CocoaPods просто, если вы используете Homebrew на Mac M1:

заварить, установить какаоподы

Если вы используете Carthage, лучшим решением будет использование XCFrameworks. Это помогает создавать только допустимые архитектуры, необходимые для создания приложения:

обновление Карфагена --use-xcframeworks

Возможно, вам потребуется обновить модули или пакеты до последней версии. Это увеличивает вероятность получения поддержки универсального двоичного файла (который содержит исполняемый код для архитектур x86_64 и arm64), чтобы вы могли без проблем перейти с компьютера Intel на компьютер Apple Silicon.

В этом посте мы используем пример проекта с комбинацией сторонних зависимостей. Мы используем как CocoaPods, так и диспетчер пакетов Swift.

Зависимости проекта в виде пакетов Swift:

• Зимородок

• Свининжект

• Аламофайр

Зависимости проекта как подов:

• СвифтЛинт

• AppsFlyerFramework

В исходном проекте используется старая версия фреймворка для демонстрации ошибки, возникающей, когда XCFramework не поддерживает архитектуру arm64.

модуль «AppsFlyerFramework», «6.2.0»

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

ld: в /Users/rudrankriyam/Downloads/Silicon/Pods/AppsFlyerFramework/iOS/AppsFlyerLib.framework/AppsFlyerLib(AFSDKKeychainFactory.o),

сборка для симулятора iOS, но ссылка в объектном файле, созданном для iOS,

файл '/Users/rudrankriyam/Downloads/Silicon/Pods/AppsFlyerFramework/iOS/AppsFlyerLib.framework/AppsFlyerLib'

для архитектуры arm64

Вам нужна архитектура arm64 для запуска проекта в симуляторе. Но эта версия фреймворка его не поддерживает.

Чтобы решить эту проблему, выполните поиск в репозитории фреймворка и проверьте, не выпустили ли они версию, которая добавляет поддержку arm64. Как упоминалось ранее, многие приоритетные платформы и проекты с открытым исходным кодом обеспечивают поддержку работы на новейших кремниевых чипах. К счастью, поддержка arm64 была добавлена ​​для этой платформы в версии 6.3.0, и мы можем обновить Podfile, чтобы получить последнюю версию.

модуль «AppsFlyerFramework»

После того, как вы введете команду pod update, вы сможете успешно запустить проект на устройствах M1 и компьютерах Intel.

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

Несмотря на множество зависимостей, обеспечивающих быструю поддержку, используемая вами структура может быть устаревшей. Это также может быть проприетарный фреймворк, который не дает вам доступа к исходному коду. Предположим, вы не увидите никаких обновлений для этих фреймворков/пакетов в обозримом будущем. В этом случае вы можете ознакомиться с этой статьей [«Взлом нативных двоичных файлов ARM64 для запуска в симуляторе iOS»] (https://bogo.wtf/arm64-to-sim.html). Как следует из названия, это хак, чтобы все заработало, и мы рекомендуем использовать этот экстремальный обходной путь только в крайнем случае.

Время сборки для M1 Mac mini и Intel Mac Pro

Вы можете черпать вдохновение в проектах с открытым исходным кодом, которые были успешно перенесены, и работать над новыми чипами. Взгляните на несколько примеров таких проектов [здесь] (https://blog.codemagic.io/open-source-ios-projects-to-learn-better-practices/).

Чтобы понять разницу во времени сборки между машинами M1 и Intel и получить лучшее представление о превосходной эффективности и скорости M1 Mac mini, мы собрали и запустили тесты на официальной [Wikipedia iOS] (https://github.com/ приложение nevercode-rudrank/wikipedia-ios). Это демонстрирует реальный сценарий с сотнями тестов. Это приложение с открытым исходным кодом, которое вы можете изучить самостоятельно.

| Название теста | Мак мини М1 | Мак Про |

| Установка скриптов | 17 с | 163с |

| Строительный проект | 254с | 280с |

| Запуск тестов | 270с | 395с |

| В целом | 573с | 883s |

Вы можете увидеть существенные различия в числах, особенно при выполнении тестов — они выполняются значительно быстрее на машинах сборки M1. После многократного запуска одних и тех же тестов для этого приложения общее время сборки сократилось на 35–40%. Разрыв между числами увеличивается при выполнении множества сборок и значительно экономит время для более быстрого процесса итерации.

Вывод

Силиконовые чипы Apple — это будущее оборудования Mac, и с этого момента оно становится только лучше. Популярные фреймворки с открытым исходным кодом и SDK уже поддерживают новые чипы, поэтому переход на них стал намного проще, чем год назад.

Напоминание: мини-машины для сборки M1 Mac уже доступны на Codemagic. Если вы пользуетесь планом с оплатой по мере использования, просто используйте instance_type: mac_mini_m1, чтобы попробовать их. Если у вас тарифный план Professional и вы хотите настроить пробную версию Mac mini M1, обратитесь к нашей команде инженеров по работе с клиентами, чтобы помочь вам быстро получить экологичные сборки на новых машинах!

Зарегистрируйтесь, чтобы попробовать машины для сборки Mac mini M1

Также опубликовано в [блоге Codemagic] (https://blog.codemagic.io/migrating-intel-m1-silicon/) и написано Рудраком Риямом.