Flutter 3.47 iOS CI: приёмка SwiftPM — чек-лист 2026

Сборка на рабочем Mac проходит, но CI после обновления Flutter не может получить Swift-пакеты или выпустить подписанный архив.

Решение: Flutter 3.47 iOS CI следует принимать по сценариям: сначала подтвердите, какие плагины используют SwiftPM, а какие требуют возврата к CocoaPods, затем повторите разрешение зависимостей, сборку и архив на чистом Mac. Успешная сборка только на машине разработчика не является основанием для полного переключения.

Материал пригодится разработчикам Flutter-приложений, которые проверяют совместимость плагинов перед обновлением.
CI-инженерам — для проверки зависимостей, архива и подписи на Mac-узле.
Авторам Flutter-плагинов — чтобы подтвердить поддержку SwiftPM и документировать необходимый резервный путь.

Последнее обновление: 31 октября 2026 года. Сведения сверены с заметками о выпуске Flutter, официальными инструкциями по SwiftPM для приложений и руководством Apple по CI со Swift-пакетами. Условия и дата перевода репозитория CocoaPods в режим только для чтения ниже приведены как объявленный план, а не как уже наступившее событие.

Зафиксируйте исходное состояние проекта

По официальным материалам Flutter, начиная с Flutter 3.44 Swift Package Manager стал стандартным механизмом управления зависимостями для iOS и macOS; официальный список выпусков указывает Flutter 3.47 как стабильную версию на дату проверки. Эти сведения задают отправную точку, но сами по себе не говорят, что конкретный репозиторий уже использует SwiftPM: существующий проект мог сохранить прежнюю конфигурацию, а команда могла внести ручные изменения.

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

В основной ветке зафиксируйте коммит, версию Flutter и Xcode, состояние рабочего дерева, активную схему сборки и способ запуска CI. Запишите также, есть ли в проекте изменения интеграции, созданные автоматически при переходе, и какие настройки редактировала команда вручную. Это позволяет отличить поведение инструмента от локальной адаптации.

Руководство Flutter для разработчиков описывает SwiftPM как стандартный путь начиная с Flutter 3.44 и объясняет миграцию приложений. Сопоставьте его с конфигурацией конкретного проекта, а не с предположением «новая версия SDK уже всё переключила». Если в репозитории нет очевидного признака используемого механизма, подтвердите вывод командами Flutter и журналом CI, где видно, как именно обнаруживались и разрешались зависимости.

План перевода репозитория CocoaPods в режим только для чтения назначен на 2 декабря 2026 года. Это будущая дата относительно проверки 31 октября 2026 года: учитывайте её при планировании, но не описывайте как уже действующее ограничение. Актуальный статус перед изменением процесса нужно перепроверить в официальной документации Flutter.

Проверьте приложение и плагины отдельно

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

Затем пройдите зависимости по списку: собственный код, сторонние плагины и транзитивные пакеты. Для каждого плагина установите, заявлена ли поддержка SwiftPM в документации автора и какие пакеты должны быть доступны. Руководство Flutter для авторов плагинов помогает сверить структуру и требования к объявлению поддержки; общие правила разработки Flutter-пакетов и плагинов полезны для проверки того, как пакет включён в приложение.

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

Чистую проверку выполняйте на том же коммите, который предназначен для релиза. Используйте отдельное рабочее пространство без прежних кэшей SwiftPM и артефактов предыдущей сборки; получайте исходники и зависимости штатным способом, доступным CI. Сохраните вывод разрешения и убедитесь, что он соответствует lock-файлу. Если репозиторий приватный, проверьте доступы на самом узле, не подменяя их локальными сохранёнными учётными данными.

Определите путь для плагинов без поддержки SwiftPM

Flutter документирует возврат к CocoaPods для плагинов, которые ещё не поддерживают SwiftPM. Это резервный путь, а не гарантия универсальной совместимости: поведение зависит от конкретного плагина, конфигурации проекта и того, какие зависимости фактически обнаружил Flutter CLI.

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

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

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

Принимайте add-to-app как отдельный сценарий

Если Flutter встраивается в существующее iOS-приложение, не переносите без проверки выводы из обычного Flutter-проекта. Хост-приложение управляет частью настроек и может иметь собственные схемы, цели сборки, правила разрешения пакетов и команды CI.

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

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

Проведите проверку архива, тестов и подписи

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

Официальная документация Flutter по развёртыванию iOS-приложений описывает выпуск и требования платформы. Инструкции Apple по сборке Swift-пакетов и использующих их приложений в CI помогают отдельно проверить автоматизацию разрешения и сборки пакетов. Применяйте эти указания к фактической версии Xcode и настройкам проекта, а не воспринимайте ссылку на документацию как замену тестов.

Для частных Git-зависимостей или пакетов, требующих аутентификации, проверьте наличие доступа на CI-узле и конфигурацию Git, которой пользуется сборка. Учетные данные должны поступать через защищённый механизм CI. Не печатайте токены, приватные URL с секретами, содержимое ключей или переменные с чувствительными значениями в логах. В журнале оставляйте только достаточные сведения о том, что аутентификация прошла или завершилась ошибкой.

Для архивной проверки сохраняйте коммит, использованные настройки, журнал Xcode и итог экспорта. Секреты и закрытые ключи в отчёт не включайте. Если подпись формируется отдельным этапом, проверяйте его результат отдельно от сборки: приложение может успешно собраться, но не пройти экспорт из-за профиля, сертификата или несоответствия выбранной конфигурации. Результат «архив создан» и результат «артефакт подписан и готов к распространению» — разные утверждения, поэтому подтверждайте их разными свидетельствами.

Выберите границы миграции по результатам

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

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

• Если все нужные плагины документируют поддержку SwiftPM, зависимости разрешаются на чистом Mac, а тесты и архив проходят в CI, то переключайте проверенный сценарий на SwiftPM и сохраняйте журналы как базовый результат.
• Если конкретный плагин требует CocoaPods и его резервная сборка подтверждена логами, то оставляйте этот путь для соответствующего сценария и фиксируйте его причину; не объявляйте весь проект полностью переведённым.
• Если зависимость не разрешается без старого кэша, автор не подтверждает поддержку либо архив не проходит, то приостановите расширение миграции и сначала устраните или документируйте блокирующее условие.
• Если Flutter встроен в существующее iOS-приложение, то принимайте отдельно сборку хост-проекта; успешный результат обычного Flutter-приложения для этого недостаточен.

Планируемое изменение статуса репозитория CocoaPods — повод заранее проверить, какие проекты зависят от этого инструментария, но не основание удалять рабочую интеграцию до проверки. Flutter указывает дату перевода репозитория в режим только для чтения — 2 декабря 2026 года; на момент последней проверки это будущая дата. Сверьте объявление перед изменением внутренних инструкций и сохраните доказательства текущей сборки, чтобы команда могла отличить будущий план от уже вступившего в силу ограничения.

Частые вопросы о приёмке SwiftPM

Использует ли проект на Flutter 3.47 SwiftPM автоматически?

Flutter указывает, что Swift Package Manager стал стандартным способом управления зависимостями iOS и macOS начиная с Flutter 3.44. Однако это не доказывает, что каждый проект, обновлённый до Flutter 3.47, уже переключён: проверьте конфигурацию репозитория, миграционные изменения и вывод CLI. В CI зафиксируйте обнаруженный путь разрешения зависимостей.

Как поступит Flutter, если плагин не поддерживает SwiftPM?

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

Как проверить разрешение Swift-пакетов без старого кэша?

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

Что проверить в IPA после миграции с CocoaPods?

Подтвердите восстановление зависимостей, сборку требуемой схемы, тесты, создание архива и экспорт IPA с нужной подписью. Сохраните журналы и сведения о результате, не раскрывая ключи и учётные данные. Для Flutter add-to-app запустите проверку через точку входа хост-проекта, поскольку сборка отдельного Flutter-модуля не подтверждает готовность интегрированного приложения.

Выберите Mac-среду под объём проверки

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

У текущего процесса без доступного Mac обычно есть конкретные ограничения: Linux-узел не заменяет сборочную среду Xcode; локальный компьютер может скрывать отсутствующие зависимости кэшем; разовые проверки затрудняют воспроизведение состояния и сохранение журналов. Это аргументы в пользу временного Mac CI, но не для всех команд. Если нужен постоянный узел под непрерывную нагрузку, важны физические интерфейсы или предсказуемое долгосрочное использование, собственный Mac может оказаться практичнее аренды.

Для временной приёмки сначала сравните расписание проекта с доступностью команды и требованиями к доступу. Условия можно посмотреть на странице тарифов RUVCLOUD; если временная среда нужна для чистой проверки сборки, варианты аренды Mac доступны на странице заказа Mac. Выбирайте аренду не вместо процесса контроля, а как среду, где можно воспроизвести зависимостную цепочку и получить архивные доказательства.

В результате решение по Flutter 3.47 iOS CI должно опираться на поддержку плагинов, чистое разрешение SwiftPM и проверенный архив, а не на успешный запуск на одном компьютере. Если Mac-среды пока нет, рассмотрите временную аренду RUVCLOUD для проверки представительного проекта; после теста решите, достаточно ли разовых прогонов или команде нужен собственный постоянный Mac-узел.