Si mantienes una app Flutter con destino iOS o macOS, tienes una fecha que apuntar en el calendario: el 2 de diciembre de 2026 el registro (trunk) de CocoaPods pasa a ser de solo lectura. Y desde Flutter 3.44, Swift Package Manager (SwiftPM) ya es el gestor de dependencias por defecto, no una opción experimental. La combinación de ambas cosas no rompe tus builds actuales de golpe, pero sí marca el final de una era y obliga a planificar. Este es el estado real del asunto y cómo lo abordaríamos, con sus matices.
Qué ha cambiado exactamente (y qué no)
Conviene separar dos hechos que a menudo se mezclan:
-
CocoaPods entra en modo mantenimiento. Su trunk (el registro central de pods) será de solo lectura a partir del 2 de diciembre de 2026. Traducción: lo que ya está publicado seguirá ahí y tus builds existentes seguirán funcionando, pero no se publicarán nuevas versiones ni nuevos pods en el registro después de esa fecha. No es un apagón; es una congelación.
-
Flutter 3.44 hace de SwiftPM el gestor por defecto para apps iOS y macOS. En releases anteriores (SwiftPM llegó como soporte inicial en Flutter 3.24) tenías que activarlo tú; ahora viene activado de serie. Cuando compilas o ejecutas tu app, el CLI de Flutter migra automáticamente la configuración e intenta resolver dependencias vía SwiftPM.
La lectura honesta: no es una emergencia para mañana, pero es una migración inevitable. Cuanto más esperes, más probable es que te pille con prisas o con un plugin sin soporte justo cuando necesitas publicar.
Qué significa para tu app
Si eres desarrollador de aplicaciones (no de plugins), la mayor parte del trabajo es automática. El flutter CLI reescribe la integración del proyecto Xcode para usar SwiftPM al construir. Para la inmensa mayoría de apps con dependencias populares, la migración es transparente.
El problema no está en tu código: está en tus dependencias.
El punto crítico: los plugins
Aquí es donde recomendamos poner el foco. Un plugin de Flutter tiene que declarar soporte explícito para SwiftPM (añadir un Package.swift y reestructurar sus fuentes). Y no todos lo han hecho:
- En el momento del anuncio, solo el 61% de los 100 plugins de iOS más usados habían migrado a SwiftPM.
- Para las dependencias que aún no lo soportan, Flutter hace fallback temporal a CocoaPods y te imprime un aviso listando exactamente qué plugins no están soportados.
- Los paquetes sin soporte SwiftPM reciben una puntuación más baja en pub.dev hasta que migren.
Es decir: hoy sigues necesitando CocoaPods instalado en tu máquina de build mientras alguna de tus dependencias no haya migrado. El riesgo real no es que tu app deje de compilar el 3 de diciembre —los pods ya publicados seguirán resolviéndose—, sino quedarte atado a una versión concreta de un pod que ya nadie va a actualizar (sin parches de seguridad, sin compatibilidad con nuevas versiones de iOS/Xcode) porque su plugin nunca completó la migración.
Plan de migración con criterio
No hace falta reescribir nada de golpe. Este es el orden en el que lo haríamos:
- Inventaría tus dependencias iOS/macOS. Actualiza a Flutter 3.44+, compila y lee el aviso del CLI: te dice literalmente qué plugins siguen dependiendo de CocoaPods. Esa lista es tu backlog de riesgo.
- Clasifica cada plugin no migrado. ¿Está mantenido activamente? ¿Hay un PR abierto añadiendo
Package.swift? ¿Existe una alternativa que ya soporte SwiftPM? Un plugin sin actividad y sin soporte SwiftPM es deuda técnica con fecha de caducidad. - Prioriza los que tocan seguridad y ciclo de release. Pagos, autenticación, push, analytics: si alguno de estos depende de un pod que va a quedar congelado, súbelo a lo alto de la lista.
- Prueba en una rama. La migración automática es buena, pero verifica builds de release, firmado y CI antes de tocar
main. Si algo se rompe, puedes desactivar SwiftPM temporalmente poniendoenable-swift-package-manager: falseen el bloqueconfigde la secciónflutterde tupubspec.yaml, y reportar el bug en GitHub. - Revisa tu pipeline de CI. Si usas cachés de Pods, runners con CocoaPods preinstalado o pasos manuales de
pod install, tendrás que adaptarlos. Herramientas como Xcode Cloud ya integran SwiftPM de forma nativa.
Cuándo NO migrar todavía
Ser honestos incluye decir cuándo conviene esperar:
- Si dependes de un plugin crítico que aún no soporta SwiftPM. Forzar la migración cuando el fallback a CocoaPods ya te funciona no aporta nada y añade riesgo. Mejor presiona (o contribuye) para que ese plugin migre, y muévete cuando esté listo.
- Si estás en mitad de una release importante. Una migración de dependencias no es el cambio que quieres meter la semana antes de publicar. Planifícala en un sprint tranquilo.
- Si tu setup de Podfile es complejo (targets múltiples, post_install hooks, pods con configuraciones a medida). Aquí la migración automática puede no cubrir todos los casos y conviene hacerla con calma y tests.
Lo que no recomendamos es ignorarlo hasta noviembre. La ventana cómoda es ahora: quedan meses para que los plugins que te faltan completen su migración y para hacer la transición sin presión.
Resumen de escenarios
| Tu situación | Recomendación |
|---|---|
| App con dependencias populares, todas migradas | Migra ya; la transición es casi transparente |
| Alguna dependencia sin SwiftPM, pero mantenida | Migra el resto; usa fallback y planifica el plugin pendiente |
| Dependencia crítica abandonada, sin SwiftPM | Prioriza buscar alternativa o fork; no es solo migración, es riesgo |
| Podfile complejo / CI a medida | Migra en rama con tests de release antes de tocar producción |
| En mitad de una release grande | Espera al siguiente sprint; no metas esto en caliente |
Conclusión
La desaparición de CocoaPods como estándar no es una crisis, pero sí una cuenta atrás. El trabajo pesado —la migración de la app— es automático; el trabajo inteligente es auditar tus dependencias, detectar qué plugins se van a quedar congelados y decidir con criterio qué migrar, qué sustituir y qué puede esperar. Esa es la diferencia entre llegar a diciembre con la casa en orden o resolviéndolo con prisas.
En Dribba llevamos desde 2017 en el directorio oficial de Flutter Partners de Google —somos la única agencia española en él— y mantenemos apps Flutter en producción en las que este tipo de migraciones de infraestructura forman parte del día a día. Si quieres una auditoría de dependencias de tu app o ayuda para planificar la transición a SwiftPM sin frenar tu roadmap, hablamos sobre tu proyecto Flutter.
