Короткий ответ: не приравнивайте появление поддержки к рекомендации мигрировать. В официальном описании React Native 0.88 SwiftPM обозначен как экспериментальный путь, который нужно включить. CocoaPods по-прежнему поддерживается. Поэтому выбор зависит не от моды на менеджер пакетов, а от совместимости всех нативных компонентов и возможности вернуться к воспроизводимой сборке.

Здесь важно различать три утверждения:

• «В версии есть поддержка» означает, что можно опробовать соответствующий путь.
• «Поддерживается CocoaPods» означает, что текущую схему не требуется менять только ради обновления.
• «Подходит для моего выпуска» можно утверждать лишь после проверки зависимостей, сборки и фактического процесса публикации вашего приложения.

React Native 0.87 уже описывал SwiftPM как экспериментальную возможность; заметка к версии 0.88 — исходная точка для проверки текущего статуса. Это подтверждает наличие развивающегося направления, но само по себе не доказывает, что каждый сторонний модуль, скрипт или проектный шаблон готов к использованию с ним. Сверяйте выводы с описанием React Native 0.87 и официальным описанием версии 0.88.

У официального обсуждения SwiftPM есть и ценность, и пределы. Предложение по интеграции SwiftPM помогает понять направление работы и мотивацию, но обсуждение проекта не заменяет документацию к конкретной версии и проверку вашего приложения. Если следующий выпуск упоминается как возможное место для изменения статуса или поведения, рассматривайте это как план, а не как уже действующее свойство установленной версии.

Сначала разделите риски по четырем слоям

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

• Зависимости приложения. Часть библиотек может иметь SwiftPM-описание, а часть — оставаться привязанной к Podfile, настройкам CocoaPods или собственным инструкциям подключения.
• Модули React Native. Автоматическое связывание не гарантирует автоматически, что нативная сборка конкретного модуля уже проверена с выбранным способом управления зависимостями. Ориентируйтесь на документацию библиотек и ее указания по платформе.
• Сценарии проекта. Скрипт может запускать команды CocoaPods, рассчитывать на определенное расположение файлов или модифицировать нативный проект. Такие детали легко пропустить, если проверять только манифесты пакетов.
• Выпуск приложения. Успешная локальная компиляция не подтверждает, что ваша подпись, архивирование, передача сборки и внутренние процедуры выпуска по-прежнему работают.

Именно поэтому переход с CocoaPods на SwiftPM нельзя сводить к замене одного файла конфигурации другим. Это изменение источника зависимостей и способа взаимодействия с нативным проектом. Оно может затронуть рабочие инструкции, CI и навыки команды, даже если итоговая сборка приложения выглядит прежней.

Начните с инвентаризации. Цель — не сразу пометить библиотеки как совместимые или несовместимые, а отделить подтвержденные факты от того, что нужно проверить. Официальное руководство React Native по подключению библиотек помогает разобраться с интеграцией сторонних модулей, однако окончательная проверка должна учитывать фактические версии зависимостей вашего проекта.

Создайте реестр с такими полями:

Статус зависимости должен быть одним из трех: подтверждена для пилота, требует проверки или блокирует миграцию до выяснения. Не используйте молчаливое предположение «вероятно, работает»: отсутствие известной ошибки — не свидетельство совместимости.

Для проверки стороннего кода начинайте с документации компонента и его закрепленной версии. Если инструкции говорят только о CocoaPods, спросите сопровождающих о SwiftPM или проверьте самостоятельное подключение в отдельном проекте. Не делайте вывод по тому, что библиотека написана на Swift: язык исходников и способ доставки зависимости — разные свойства.

Когда не стоит вводить второй пакетный путь

Смешивание SwiftPM и CocoaPods может быть временным экспериментом, но не следует считать его безусловно безопасным. Возможность подключить пакет в одном инструменте не означает, что проект корректно разрешает один и тот же компонент через два пути, что настройки нативного проекта не конфликтуют или что сценарии автоматической сборки понимают обе схемы.

До пробного смешивания ответьте на вопросы:

• Для каждого модуля известно, какой инструмент управляет его нативными зависимостями?
• Нет ли одного и того же компонента, подключенного одновременно несколькими способами?
• Понятно, кто создает или обновляет нативные настройки проекта?
• Скрипты сборки не запускают незаметно старую последовательность CocoaPods?
• Можно ли удалить экспериментальные изменения и повторить сборку на исходной схеме?

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

Для нового проекта с небольшим числом нативных зависимостей SwiftPM может быть предметом раннего теста. Для уже выпускаемого приложения это скорее миграционный проект: его нужно отделить от разработки функций и выпуска исправлений. В обоих случаях тестовый результат должен отвечать на конкретные вопросы, а не просто демонстрировать, что открывается Xcode.

Сценарий. Вы начинаете приложение, а в наборе пока есть несколько проверенных нативных компонентов. Вместо того чтобы объявлять SwiftPM постоянным стандартом команды, вы создаете отдельную ветку, включаете экспериментальную интеграцию по официальным инструкциям и проверяете чистую сборку. Если автор одного из важных модулей не подтверждает нужный способ подключения, пилот останавливается до выяснения. При этом CocoaPods остается выбранным путем, если на нем уже основана рабочая конфигурация.

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

Сравнение описывает типы работы, а не гарантированное поведение каждого проекта. Например, наличие Ruby в окружении само по себе не доказывает, что общий переход на SwiftPM будет дешевле: новые правила разрешения пакетов, совместимость плагинов и поддержка команды тоже требуют времени. Аналогично, прежняя стабильность CocoaPods не означает, что всякий проект обязан навсегда оставаться на нем.

Не делайте одновременно два больших изменения: не меняйте пакетный менеджер вместе с настройками подписи, параметрами релиза или способом передачи сборки. Иначе при ошибке будет сложнее понять, на каком этапе появился дефект. Сначала проверьте саму миграцию зависимостей, затем — выпуск.

Проверяйте не один результат, а всю цепочку

В Xcode успешное разрешение зависимостей — только первый рубеж. Документация Apple объясняет, как добавлять зависимости пакетов в приложение, но она не утверждает, что каждый модуль React Native из вашего проекта уже совместим с конкретной экспериментальной интеграцией. Для сборок в CI также учитывайте рекомендации Apple по Swift-пакетам в непрерывной интеграции.

Проверяйте результаты раздельно:

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

Требуемые версия Xcode и macOS должны быть совместимы друг с другом. Проверьте это по официальным системным требованиям Xcode, а не только по тому, что инструмент запускается на знакомом компьютере.

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

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

Практический порядок проверки:

Подготовьте исходную точку. Зафиксируйте коммит, на котором проект собирается текущим способом. Сохраните инструкции по установке зависимостей, настройки нативной части и действующий сценарий выпуска. Не удаляйте lock-файлы и конфигурацию CocoaPods до проверки альтернативы.

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

Соберите перечень неизвестного. Для каждого модуля без подтвержденной поддержки заведите конкретное действие: найти официальную инструкцию, запросить подтверждение автора либо провести тест в минимальном примере. Не заменяйте такую работу предположением, что SwiftPM подойдет всем пакетам.

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

Выполните чистую сборку. Начните с копии проекта без локально сохраненных результатов предыдущих сборок. Зафиксируйте, где именно появляется ошибка: разрешение пакетов, компиляция, запуск или подпись. По одному сообщению «не собирается» нельзя установить, что виноват сам менеджер зависимостей.

Проверьте функцию приложения. Запустите сценарии, которые затрагивают нативные библиотеки: уведомления, доступ к устройству, аналитические или другие используемые функции. Состав таких сценариев зависит от приложения; важен не полный список функций рынка, а проверка того, что реально включено у вас.

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

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

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

Для проверки нужен macOS с подходящей версией Xcode — это может быть ваш рабочий Mac, выделенная машина команды или отдельная удаленная среда. Windows и Linux могут оставаться удобными для общей части разработки, но не подменяют проверку фактической iOS-сборки в macOS. Если собственного Mac нет, удаленную среду можно рассмотреть как способ провести тест, не меняя сразу весь рабочий процесс. Подбор доступного варианта можно начать с каталога Mac-сред.

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

Удобно разделить приемку на действия, которые приводят к отдельным доказательствам:

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

Фиксируйте для каждого результата коммит, версии инструментария и обнаруженные ограничения. Если проект собирался на удаленном Mac один раз, формулируйте итог узко: «этот коммит с этим набором зависимостей прошел такую проверку». Не превращайте его в универсальное утверждение, что SwiftPM совместим со всеми приложениями React Native.

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

Используйте следующие ветви решения:

• Если важные нативные зависимости подтверждены, чистая сборка воспроизводится, поведение приложения проверено, выпускной путь не сломан и откат подготовлен, то расширяйте пилот постепенно. Сначала переведите ограниченную часть проекта или отдельную ветку, а затем повторите приемку для основного релизного маршрута.
• Если зависимости проходят сборку, но поведение приложения или публикация не проверены, то не объявляйте миграцию завершенной. Оставьте SwiftPM в тестовой ветке, а CocoaPods — в выпускном процессе до закрытия пробелов.
• Если ключевая библиотека зависит от CocoaPods, скрипт нельзя надежно адаптировать или чистую сборку пока нельзя повторить, то отложите переход. Зафиксируйте, какие условия должны измениться для повторной оценки.
• Если вы начинаете новый проект и зависимости простые, то испытайте SwiftPM до того, как команда встроит CocoaPods в инструкции и CI. При этом не называйте экспериментальный путь обязательным стандартом: решение зависит от проверок и планов выпуска.
• Если проект уже выпускается и текущая схема предсказуемо работает, то не меняйте ее ради соответствия предполагаемому будущему направлению React Native. Сначала получите достаточные доказательства на вашей кодовой базе.

Официальные планы дальнейшего развития полезны как повод назначить повторный пересмотр, но не как основание для миграции сегодня. Повторно проверьте ситуацию, когда React Native изменит обозначение экспериментальной поддержки, опубликует новые инструкции или когда обновятся критичные для вас библиотеки. До этого не переносите обещание будущего поведения на установленную версию.

Частые вопросы

Подходит ли SwiftPM в React Native 0.88 для производственного приложения?
Не считайте его универсальной заменой CocoaPods. В React Native 0.88 поддержка экспериментальная и включается отдельно. Новый проект с проверенными зависимостями можно использовать для ограниченного пилота. Для выпускаемого приложения сначала подтвердите весь набор библиотек и нативных модулей, чистую сборку и реальный процесс публикации. Пока эти проверки не пройдены, сохраните проверенный путь сборки.

Что проверить в нативных зависимостях перед миграцией?
Инвентаризируйте основные библиотеки, модули React Native, внутренние пакеты, автоматическое связывание и скрипты. Для каждого компонента выясните, заявлена ли поддержка SwiftPM именно для используемой версии и каким способом он подключается. Отдельно проверьте lock-файлы, команды CocoaPods и изменения нативного проекта. Неподтвержденные компоненты помечайте как неизвестные, а не как совместимые.

Можно ли держать SwiftPM и CocoaPods в одном проекте?
Только после отдельной проверки конкретной схемы. Важно понимать, какой инструмент управляет каждой зависимостью и нет ли дублирующего подключения или конфликтующих изменений проекта. Экспериментируйте в отдельной ветке, не меняйте одновременно настройки выпуска и заранее проверьте возврат к исходному состоянию. Не воспринимайте возможность смешивания как подтверждение, что этот вариант надежен для вашего проекта.

Как проверить сборку без собственного Mac?
Воспользуйтесь доступной средой macOS, подходящей для вашего Xcode, и повторите реальную последовательность: чистое получение зависимостей, iOS-сборка, запуск в симуляторе и нужный выпускной тест. Сверьте системную совместимость инструментария и заранее определите, как передавать исходники и хранить секреты. Удаленная среда полезна как отдельный тестовый контур, но единичный успешный запуск не доказывает повторяемость публикации.

Для большинства действующих приложений на CocoaPods более разумно сохранить рабочую схему, чем одновременно рисковать зависимостями, настройками проекта и выпуском. Локальный компьютер может не подходить для независимого чистого теста; общая CI-среда — не всегда удобна для изолированной проверки Mac-настроек; эксперимент в релизной ветке создает ненужное давление на выпуск. Если вам нужно именно проверить React Native iOS-зависимости и сборочный процесс без покупки отдельной машины, аренда удаленного Mac может дать отдельную среду для такого теста. Сначала сопоставьте задачу с доступным вариантом на странице оформления Mac, затем проверьте нужные версии Xcode и macOS и проведите приемку по шагам выше. Если вам необходима постоянная интенсивная работа или физические интерфейсы конкретного компьютера, сравните аренду с собственной машиной: удаленная среда подходит не для каждого процесса.