Нужно ли переносить iOS-зависимости Flutter 3.44? Руководство по выбору на 2026 год

Для нового проекта на Flutter 3.44 сначала оценивайте путь Swift Package Manager; существующий проект не переносите только из-за объявления о планируемом переходе реестра CocoaPods в режим чтения — сначала проверьте плагины и сборочную цепочку в изолированном Mac CI. Такой порядок подходит, если вам важно сохранить воспроизводимую сборку и не менять рабочие зависимости до подтверждения совместимости.

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

Обновлено 4 ноября 2026 года; сведения сверены с документацией Flutter и планом CocoaPods, указанными ниже. Перед изменением графика или поддержки ориентируйтесь на актуальные официальные страницы.

Flutter 3.44: новый проект и существующая кодовая база

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

Для новой кодовой базы Swift Package Manager стоит рассматривать как исходный вариант, если ключевые плагины и нативные библиотеки его поддерживают, а команда умеет диагностировать разрешение пакетов и ошибки Xcode. Так вы не добавляете CocoaPods лишь по инерции, но и не предполагаете заранее, что каждый сторонний пакет готов к смене интеграции.

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

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

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

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

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

Системные требования и границы платформы

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

Для нового проекта проверьте следующие условия:

• Зафиксирована ли версия Flutter и согласуется ли она с выбранным проектным шаблоном.
• Поддерживают ли все необходимые нативные библиотеки Swift Package Manager, включая библиотеки, подключаемые через плагины.
• Может ли команда сопровождать package manifest, разрешение пакетов и диагностику ошибок в Xcode.
• Совпадает ли конфигурация разработки с тем, что потребуется для тестирования, выпуска и подписи.
• Есть ли отдельная macOS-среда, где вы сможете провести чистую проверку, не затрагивая производственный конвейер.

Swift Package Manager управляет пакетами и их описанием; его правила декларации изложены в официальной документации PackageDescription. Сама поддержка Swift Package Manager в конкретном плагине зависит от того, как его автор описал пакет и интеграцию. Наличие декларации пакета не гарантирует, что весь проектный сценарий — включая нативные настройки, тесты и архивирование — заработает без изменений.

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

Совместимость плагинов и ответственность команды

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

Проверяйте не только декларацию зависимостей, но и то, что плагин делает на платформе iOS. Он может предоставлять нативный код, требовать специфическую настройку проекта, подключать дополнительную библиотеку или выполнять действия во время установки. Если документация плагина описывает лишь CocoaPods-интеграцию, не трактуйте успешное разрешение пакета как свидетельство готовности к Swift Package Manager.

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

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

Если плагин не поддерживает Swift Package Manager, выберите реакцию по его роли:

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

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

Матрица выбора для проекта

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

Mac CI: критерии приёмки миграции

Проверку выполняйте в изолированном macOS/Xcode CI, а не только на рабочем компьютере. Под «изолированным» здесь понимается отдельная задача или среда, где результат можно сопоставить с текущей сборкой, не меняя производственный процесс до принятия решения. Если тестировать на среде с уже заполненными кешами, можно пропустить проблему получения зависимостей, которая возникнет на новом агенте.

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

1. Зафиксируйте исходное состояние. Сохраните версию Flutter, используемые настройки Xcode, lock-файлы, список плагинов, скрипты и текущий успешный результат. Секреты подписи не помещайте в открытые логи.
2. Составьте карту зависимостей. Разделите прямые и транзитивные пакеты, отметьте способ подключения каждого нативного компонента и найдите вызовы CocoaPods в скриптах или документации внутренних модулей.
3. Подготовьте отдельный вариант интеграции. Не перезаписывайте рабочую конфигурацию до того, как сможете собрать отдельную ветку или отдельную CI-задачу. Сохраните изменения файлов и команды, чтобы результат можно было повторить.
4. Проверьте разрешение с чистого состояния. Уберите зависимость от прежнего локального кеша в пределах изолированной задачи и сохраните вывод разрешения пакетов. Сравните фактически выбранные версии с ожидаемыми lock-файлами.
5. Выполните компиляцию и тесты. Прогоните сборку приложения и тесты, которыми пользуется проект. Если у приложения есть конфигурации или варианты среды, включите те, от которых зависит выпуск; не считайте один успешно собранный вариант доказательством для остальных.
6. Проверьте архивирование и подпись. Запустите тот выпускной сценарий, который использует ваша команда, и проверьте, что настройки подписи и необходимые секреты доступны в CI. Успешный запуск без подписи не подтверждает готовность к распространению приложения.
7. Сохраните доказательства и решите по критериям. Храните логи, изменения манифестов, lock-файлы и результаты тестов вместе с решением. Переводите производственную сборку только после того, как команда может повторить проверку и объяснить оставшиеся исключения.

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

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

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

Нужно ли каждому проекту переходить с CocoaPods? Нет: новый проект стоит начинать с проверки Swift Package Manager, а для существующего решение зависит от графа зависимостей и CI.

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

Что делать с несовместимым плагином? Уточнить поддержку, рассмотреть замену или оставить CocoaPods на время с установленным условием пересмотра.

Какой результат считать проверкой миграции? Не только разрешение пакетов, но и сборку, тесты, архивирование и подпись в воспроизводимой среде.

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

Часто задаваемые вопросы