GitHub Actions retirará macOS 14: cómo migrar antes de los fallos

Actualización del 15 de octubre de 2026: los brownouts del 5 y 12 de octubre ya pasaron. El próximo está previsto para el 16, de 09:00 a 19:00 en Lima. El retiro definitivo sigue anunciado para el 2 de noviembre.

El retiro de macOS 14 en GitHub Actions está fijado para el 2 de noviembre de 2026 y el siguiente periodo de fallo temporal está previsto para el 16 de octubre de 2026, de 09:00 a 19:00 en Lima. Los periodos del 5 y 12 de octubre ya quedaron atrás. Los flujos que usen macos-14, macos-14-large o macos-14-xlarge deben probarse con una imagen compatible antes de esa fecha. GitHub recomienda etiquetas arm64 basadas en macOS 15 o macOS 26, pero cambiar una línea de YAML no basta: también hay que validar arquitectura, versiones de Xcode, herramientas preinstaladas, dependencias nativas, cachés y artefactos.

La medida afecta a equipos de cualquier país que utilicen esas imágenes alojadas por GitHub. No es una norma legal ni el fin de macOS 14 en equipos propios: es un retiro anunciado de imágenes de runner del servicio GitHub Actions.

Qué anunció GitHub y cuándo ocurrirá

Hecho confirmado. El anuncio oficial de GitHub del 1 de octubre de 2026 establece que la imagen de macOS 14 se retirará el 2 de noviembre de 2026. Incluye tres etiquetas:

• macos-14
• macos-14-large
• macos-14-xlarge

Antes del retiro, GitHub ejecutará periodos de brownout: los trabajos que aún usen esas etiquetas fallarán temporalmente para hacer visible la dependencia. También advierte que puede reducir la capacidad disponible de macOS 14 durante la transición, lo que podría alargar las colas incluso fuera de esos periodos.

Calendario de fallos temporales en UTC y America/Lima

Cada periodo oficial va de 14:00 UTC a 00:00 UTC del día siguiente. En America/Lima (UTC−5) equivale a 09:00–19:00 del mismo día de inicio:

Fecha de inicio	Horario oficial UTC	Horario en Lima
5 de octubre	14:00–00:00 del 6	09:00–19:00 del 5
12 de octubre	14:00–00:00 del 13	09:00–19:00 del 12
16 de octubre	14:00–00:00 del 17	09:00–19:00 del 16
19 de octubre	14:00–00:00 del 20	09:00–19:00 del 19
23 de octubre	14:00–00:00 del 24	09:00–19:00 del 23
26 de octubre	14:00–00:00 del 27	09:00–19:00 del 26
29 de octubre	14:00–00:00 del 30	09:00–19:00 del 29
30 de octubre	14:00–00:00 del 31	09:00–19:00 del 30

Este calendario no describe una interrupción general de GitHub Actions. El fallo programado se limita a trabajos que continúen solicitando las etiquetas retiradas.

Qué etiqueta puede reemplazar a macOS 14

GitHub propone las siguientes alternativas arm64:

• macos-latest, actualmente asociado por el anuncio a macos-26;
• macos-15;
• macos-latest-xlarge, actualmente asociado a macos-26-xlarge;
• macos-15-xlarge.

Análisis. La elección depende de la prioridad del proyecto. Una etiqueta explícita como macos-15 reduce cambios inesperados durante una migración; una etiqueta móvil como macos-latest recibe la imagen estable que GitHub decida asociar en el futuro. “Latest” no significa que el entorno permanecerá idéntico.

La mención de arm64 exige una comprobación adicional: binarios, extensiones nativas, imágenes auxiliares y herramientas descargadas pueden haber sido compilados para otra arquitectura. No se debe asumir compatibilidad solo porque el sistema operativo sea más reciente.

Cómo localizar los flujos afectados

Busca las tres etiquetas en los archivos YAML de cada repositorio y en workflows reutilizables compartidos:

git grep -nE 'macos-14(-large|-xlarge)?' -- '.github/workflows/*.yml' '.github/workflows/*.yaml'

Amplía el inventario a plantillas centralizadas y repositorios que suministran workflows mediante uses:. Registra por flujo:

• etiqueta actual y alternativa propuesta;
• arquitectura esperada por cada binario;
• versión de Xcode, SDK y lenguaje;
• dependencias instaladas manualmente y herramientas preinstaladas;
• claves de caché que incluyan sistema operativo o arquitectura;
• artefactos producidos y plataformas donde se ejecutarán.

La documentación de runners alojados explica que las imágenes y sus herramientas se actualizan de forma periódica. En el registro de una ejecución, la sección Set up job → Runner Image → Included Software enlaza la lista exacta del runner utilizado.

Plan de migración antes del siguiente brownout

1. Crea una prueba paralela y reversible

No sustituyas todos los jobs críticos a la vez. Añade temporalmente la nueva etiqueta a una rama o matriz de validación y conserva el flujo actual hasta comparar resultados. Si el presupuesto de minutos es limitado, empieza por el proyecto más representativo y por los pasos que compilan código nativo.

2. Compara herramientas y versiones

Consulta el repositorio oficial actions/runner-images y la lista de software de la imagen concreta. GitHub señala que el repositorio documenta las imágenes disponibles y que el enlace dentro del log es la referencia del runner realmente ejecutado. Revisa, como mínimo, Xcode, simuladores, Swift, Homebrew, Python, Node.js, Ruby, Java y utilidades de firma que use el proyecto.

3. Valida dependencias y cachés por arquitectura

Regenera dependencias nativas y evita reutilizar una caché creada para un entorno incompatible. Una clave puede incorporar el sistema, la arquitectura y el archivo de bloqueo. También conviene inspeccionar scripts que descargan binarios según uname -m o que contienen rutas rígidas.

4. Prueba el resultado, no solo el estado verde

Una compilación exitosa no demuestra que el artefacto funcione. Instala o ejecuta el paquete resultante en un entorno de prueba, verifica firmas, pruebas de interfaz, destinos de despliegue y cualquier integración con simuladores o dispositivos. Conserva una ejecución de referencia para comparar duración y advertencias.

5. Cambia de forma explícita y vigila las primeras ejecuciones

Cuando la prueba sea estable, actualiza el YAML y documenta la decisión. Revisa las primeras ejecuciones programadas y manuales, no solo las activadas por una solicitud de cambios. Si usas una etiqueta móvil, programa una comprobación periódica de la imagen y sus herramientas.

Ejemplo de cambio controlado

# Antes
jobs:
  build:
    runs-on: macos-14

# Prueba inicial con versión explícita
jobs:
  build:
    runs-on: macos-15

El ejemplo solo cambia la selección del runner. No garantiza que el proyecto compile ni que macos-15 sea la mejor alternativa para todos los casos. Añade pruebas específicas para el lenguaje, Xcode, dependencias y artefactos de tu repositorio.

Oportunidades y precauciones para equipos de desarrollo

Oportunidad. La transición sirve para eliminar dependencias implícitas, fijar versiones críticas mediante acciones configurables y separar cachés por arquitectura. También puede revelar herramientas que ya no necesitan estar preinstaladas.

Precaución. Evita convertir macos-latest en una promesa de reproducibilidad. Para entregas reguladas o artefactos difíciles de reproducir, documenta la imagen, las versiones y el enlace de software incluido en cada ejecución.

Este retiro coincide con otros cambios del servicio. Si tu organización también usa runners Linux, revisa la guía sobre la migración de ubuntu-latest a Ubuntu 26.04. Para flujos expuestos a contribuciones externas, consulta las protecciones de ejecución para pull_request_target. Y si una automatización autentica mediante GitHub Apps, comprueba el nuevo formato de tokens de instalación.

Preguntas frecuentes

¿Todos los trabajos de GitHub Actions fallarán en los brownouts?

No. El brownout anunciado afecta a los trabajos que sigan usando macos-14, macos-14-large o macos-14-xlarge.

¿Puedo seguir usando macOS 14 después del 2 de noviembre?

No con las imágenes alojadas incluidas en el retiro anunciado. Un runner autohospedado es una infraestructura diferente y queda bajo la administración del equipo; el anuncio no ordena retirar sistemas propios.

¿Debo elegir macOS 15 o macOS 26?

Depende de la compatibilidad probada. Para una migración controlada, una versión explícita puede facilitar el diagnóstico. Usa macos-latest cuando aceptes cambios futuros de la imagen y tengas pruebas capaces de detectarlos.

¿Cambiar runs-on es suficiente?

No necesariamente. Comprueba arquitectura, Xcode, SDK, herramientas, binarios nativos, cachés, firmas y el artefacto final.

¿Los horarios publicados están en la zona de mi país?

GitHub los publicó en UTC. En America/Lima, cada periodo listado equivale a 09:00–19:00 del día de inicio.

Fuentes y verificación

• GitHub Changelog: retiro de la imagen macOS 14, publicado y actualizado el 1 de octubre de 2026.
• Repositorio oficial de imágenes de runners, consultado el 4 de octubre de 2026.
• GitHub Docs: runners alojados, consultado el 4 de octubre de 2026.

Verificado el 4 de octubre de 2026 a las 11:03, America/Lima. Las fechas y etiquetas son las publicadas por GitHub; las recomendaciones de inventario, pruebas y despliegue son análisis editorial. La disponibilidad de imágenes y herramientas puede cambiar, por lo que debe comprobarse en la documentación y en los registros de cada ejecución.