El 2 de diciembre de 2026 el registro de CocoaPods pasa a ser de solo lectura. A partir de esa fecha nadie publica versiones nuevas de un pod. Antes, en octubre, Firebase deja de publicar su SDK de Apple en CocoaPods. Si tu empresa tiene una app Flutter en producción, la pregunta que toca responder es corta: ¿tengo que hacer algo antes de diciembre?

La respuesta honesta es "casi seguro que sí, pero menos de lo que parece, y nada se te va a romper esa mañana". El matiz está en ese "casi" y en ese "menos", y es donde se concentra el trabajo real.

Qué ha cambiado y en qué fechas

Flutter 3.44, estable desde mayo de 2026, convirtió Swift Package Manager (SPM) en el gestor de dependencias por defecto para iOS y macOS. El soporte existía como opción desde Flutter 3.24, en agosto de 2024, y se activaba con flutter config --enable-swift-package-manager. Desde la 3.44 viene de serie.

En octubre de 2026 Firebase deja de publicar versiones nuevas de su SDK de Apple en CocoaPods; Firebase 12 es la última versión mayor que llega por esa vía. Y el 2 de diciembre de 2026 el trunk de CocoaPods pasa a solo lectura: no se publican pods nuevos ni actualizaciones de los existentes.

Lo que no pasa: tu app no deja de compilar el 3 de diciembre. Las versiones de pods ya publicadas siguen descargándose e instalándose, y un build que funciona hoy seguirá funcionando. CocoaPods entra en modo mantenimiento, no desaparece de golpe.

Por qué "no se requiere acción" no es toda la verdad

La documentación de Firebase lo dice claro: para la mayoría de proyectos Flutter no hace falta hacer nada especial, porque al actualizar a la última versión de Firebase el gestor de dependencias de la capa Apple migra solo a SPM. Es cierto. Y es la parte fácil.

El problema no es Firebase. Son el resto de tus plugins.

Una app Flutter de producción no vive solo de Firebase. Lleva un plugin de cámara, otro de notificaciones, uno de pagos, el de analítica, el de deep links, el de biometría. Cada plugin con código nativo publica su integración iOS, y no todos han migrado a SPM al mismo ritmo. Cuando construyes tu app, Flutter resuelve por SPM lo que puede y hace fallback a CocoaPods para los plugins que todavía no lo soportan. Te avisa con un warning que lista cuáles son.

Ese fallback es lo que te mantiene a flote hoy y lo que se convierte en deuda el 2 de diciembre. Si uno de esos plugins no migra nunca a SPM y necesita un arreglo después de esa fecha, ese arreglo no va a existir por la vía del pod: te quedas en su última versión publicada. Para un plugin con mantenimiento activo es cuestión de esperar a que publiquen la versión SPM. Para un plugin medio abandonado, es un riesgo que tienes que ver venir ahora, no en febrero cuando necesites un parche de seguridad.

Hay además un detalle técnico que muerde: mezclar CocoaPods y SPM en el mismo target puede generar ciclos de dependencias y errores de compilación. No es que convivan sin fricción. Cuantos más plugins muevas a SPM, menos superficie de conflicto te queda.

Cómo saber en diez minutos si tu app está lista

No hace falta auditar nada a mano. El propio tooling te lo dice:

  1. Actualiza a Flutter 3.44 o superior en una rama aparte. Si ya estás ahí, mejor.
  2. Haz un flutter build ios limpio y lee la salida. Flutter imprime qué plugins siguen resolviéndose por CocoaPods porque aún no tienen Swift package.
  3. Para cada plugin de esa lista, mira su repositorio: ¿hay una versión reciente con soporte SPM, un issue abierto, un PR en marcha? Eso te dice si es cuestión de actualizar o si el plugin está parado.
  4. Revisa las dependencias nativas que gestionas tú por CocoaPods, fuera de los plugins de Flutter. Esas las migras a mano o las sustituyes.

Al final de ese rato tienes una foto clara: cuántos plugins te quedan en CocoaPods, cuáles se resuelven subiendo de versión y cuáles necesitan una decisión.

Cuándo no te tienes que preocupar, y cuándo sí

No te preocupes si estás en Flutter 3.44 o superior, todos tus plugins ya tienen versión SPM y no gestionas pods nativos propios. En ese caso la migración ya ocurrió sola al actualizar y solo queda confirmarlo con el build limpio.

Preocúpate, en cambio, si:

  • Sigues en una versión de Flutter anterior a la 3.44 y no la puedes subir pronto. La migración a SPM va atada a la actualización del framework, y subir de versión mayor tiene su propio coste de regresión que hay que planificar, no improvisar.
  • Dependes de un plugin crítico que no ha publicado soporte SPM y no da señales de hacerlo. Ahí la decisión es contribuir el soporte tú, cambiar de plugin, o asumir que te quedas congelado en su última versión de pod.
  • Arrastras dependencias nativas propias en CocoaPods que nadie va a migrar por ti.

El coste de lo que recomendamos tampoco es cero. Actualizar a Flutter 3.44 arrastra cambios de comportamiento y obliga a pasar tu suite de pruebas en serio antes de ir a producción. Lo que no tiene sentido es llegar a diciembre sin haber hecho el build limpio para saber en qué punto estás. Diez minutos de diagnóstico ahora te ahorran la sorpresa de descubrir en enero que un plugin que necesitabas tocar lleva meses congelado.

Qué haríamos con un cliente en esta situación

Lo primero, el diagnóstico de la lista de plugins, que es barato y define el tamaño real del problema. En la mayoría de apps bien mantenidas el resultado es tranquilizador: dos o tres plugins pendientes que se resuelven subiendo de versión, y eso se cierra en una tarde.

El trabajo de verdad aparece cuando hay un plugin crítico parado o cuando la app está anclada a un Flutter viejo por otras razones. Ahí la conversación deja de ser sobre CocoaPods y pasa a ser sobre el plan de actualización del proyecto, que es una decisión de roadmap, no una tarea de build. No la forzaríamos contra el calendario de CocoaPods: el 2 de diciembre no rompe nada, así que tienes margen para hacerlo bien en el siguiente ciclo en lugar de a las prisas.

Si tienes una app Flutter en producción y no sabes en qué punto estás, el primer paso es el build limpio. Si del diagnóstico sale un plan de actualización que tu equipo no puede abordar ahora, es el tipo de trabajo acotado que cubrimos con refuerzo de equipo sin parar tu roadmap. Hablamos cuando tengas la lista de plugins delante.