11 ноября 2026 года проект Swift официально подтвердил дату, которую CocoaPods анонсировал ещё в 2024 году: после двухлетнего переходного периода 2 декабря 2026 года центральный реестр CocoaPods trunk перестаёт принимать новые поды и новые версии уже опубликованных подов. С 1 по 7 ноября прошёл тестовый прогон read-only режима, и автоматика CocoaPods уже один раз отработала в этом состоянии, чтобы к декабрю не осталось сюрпризов.
Что именно меняется 2 декабря
CocoaPods trunk — публичный реестр подов, через который команда pod install годами тянула тысячи сторонних библиотек для iOS. После 2 декабря трунк навсегда переходит в режим «только чтение»: существующие поды и их прежние версии остаются доступны и продолжают устанавливаться как раньше, но ни одной новой версии или нового пода в реестр больше не попадёт. Авторы библиотек, которые ещё публикуют обновления через CocoaPods, с этого момента физически не смогут этого делать, разве что через собственный приватный источник спецификаций.
Для проектов, которые уже используют CocoaPods, сборки не ломаются мгновенно: зависимости из Podfile.lock как устанавливались, так и будут устанавливаться. Проблема копится постепенно: новые версии SDK, исправления безопасности и совместимость с новыми Xcode у библиотек, которые остаются только на CocoaPods, просто перестанут приходить.
Почему это не абстрактная новость для инди-студий
- Firebase ещё в октябре 2026 прекратил публиковать новые версии Apple SDK через CocoaPods: для многих приложений с аналитикой и push это уже рабочая реальность, а не теория.
- Xcode 27 и связанный тулинг активно двигаются в сторону Swift Package Manager как основного способа подключения зависимостей. Это тот же вектор, что и сворачивание CocoaPods.
- Чем больше у проекта сторонних подов без активного мейнтейнера, тем выше риск застрять на устаревшей версии именно той библиотеки, которую сложнее всего заменить вручную.
Прямой разрыв сборки 2 декабря маловероятен почти ни у кого. Но каждый квартал без миграции — ещё один шаг к ситуации, когда критичная зависимость просто не получает обновлений под новый iOS, пока её не перенесут на SwiftPM вручную.
Что делать уже сейчас
Swift Package Manager к этому моменту умеет почти всё, что раньше требовало CocoaPods, включая управление бинарными фреймворками и приватными пакетами. Миграция технически несложная, но требует ревизии каждого пода по отдельности: часть библиотек уже официально переехала на SwiftPM, часть придётся оборачивать вручную или искать альтернативу. Разумный порядок: сначала аудит Podfile, затем перенос независимых друг от друга зависимостей по одной, с проверкой сборки после каждой.
Источники: Swift.org — What's new in Swift: November 2026 Edition (11 ноября 2026), CocoaPods Blog — CocoaPods Trunk Read-only Plan.
Если в бэклоге накопилось несколько проектов на CocoaPods и разбирать миграцию своими силами некогда, стоит заказать разработку приложения под ключ — в YUSMP Group такие миграции зависимостей делают частью сопровождения проекта, а не отдельным авралом перед дедлайном.