Mac mini M6 vs el runner de macOS alojado de GitHub: benchmark de builds con Xcode

Queríamos una cifra real para una pregunta. ¿Cuánto más rápido es un Mac mini M6 dedicado que el runner de macOS alojado estándar de GitHub, con una app de iOS real? Así que compilamos la app de código abierto de Wikipedia para iOS en los dos, con el mismo Xcode y el mismo script, tres veces en cada uno.

Este artículo sustituye a nuestro benchmark anterior del M4. Todas las cifras salen de ejecuciones hechas el 24 de septiembre de 2026.

Resultados

Median of 3 runs, in seconds. Lower is better.

                      GitHub-hosted   MacRun M6   change
                      macos-26
package download            43            39       -8%
clean build                183            86      -53%
incremental build           21            10      -51%
no-op build                 20            10      -50%
220 unit tests              44            17      -61%

El M6 compiló unas dos veces más rápido. La descarga de paquetes quedó pareja, porque las dos máquinas bajan los mismos paquetes de GitHub con conexiones rápidas. Todos los pasos terminaron bien en las dos máquinas en todas las ejecuciones.

Lo que tarda un job de CI normal

La tabla compara las máquinas paso a paso. Pero un job de CI real es distinto en cada una. Un runner alojado empieza cada job vacío. Tiene que descargar paquetes, compilar desde cero y luego pasar los tests. Un Mac dedicado conserva su carpeta de build, así que tras un cambio pequeño solo recompila lo que ha cambiado.

Esa es la diferencia que nota tu equipo. Un job que tardaba cuatro minutos y medio termina en menos de treinta segundos. En un día con muchos push, los minutos ahorrados suman horas.

En un runner alojado, ese mismo job cuesta dinero. GitHub redondea cada job al minuto hacia arriba, así que 269 segundos se facturan como 5 minutos. A $0.062 el minuto, son unos 31 céntimos por job. En un Mac dedicado no cuesta nada extra. Nuestra calculadora de costes convierte tu número de jobs en una cifra mensual.

Las dos máquinas

Los datos del hardware salen de las propias máquinas. Cada ejecución mostró su chip, su número de núcleos y su memoria antes de compilar. GitHub también vende runners de macOS más grandes, a precios por minuto más altos. Probamos el estándar porque es el que usa la mayoría de los equipos.

Método

• Proyecto: wikimedia/wikipedia-ios en el commit 8691a89, compilado para el simulador de iOS con su scheme Wikipedia y sus paquetes de Swift.
• Simulador: un iPhone 17 nuevo con iOS 26.5, creado de la misma forma en las dos máquinas.
• Cada ejecución empieza borrando la caché de paquetes y DerivedData. La firma está desactivada, como suele estarlo en las builds de CI para el simulador.
• Descarga de paquetes: xcodebuild -resolvePackageDependencies en una carpeta vacía.
• Build limpia: xcodebuild build-for-testing con DerivedData vacío y los paquetes ya descargados.
• Build incremental: el mismo comando tras añadir una línea de comentario a un archivo Swift de la app.
• Build sin cambios: el mismo comando otra vez sin cambiar nada.
• Tests: los 220 tests unitarios del paquete WMFData de la app, ejecutados con test-without-building en un simulador arrancado.
• Tres ejecuciones completas en cada máquina. Damos la mediana.

Matices

Pasamos los tests de los paquetes de la app, no su target de tests principal. El target principal necesita entitlements de app group firmados, y una build de CI sin firmar no los tiene. Su test host se relanzaba una y otra vez en las dos máquinas, así que no era una medida justa.

La build incremental tocó un archivo pequeño. Casi todos sus 10 segundos son Xcode planificando la build, y por eso coincide con la build sin cambios. Un cambio en un archivo muy usado tardaría más en las dos máquinas.

Las dos máquinas tenían versiones distintas de macOS, porque cada una usaba lo que su dueño ofrece hoy. Un job alojado también puede cachear los paquetes de Swift con actions/cache. Eso recortaría el paso de descarga. No eliminaría la build limpia, que es la mayor parte del tiempo.

Vendemos el runner M6, así que valora nuestras cifras teniéndolo en cuenta. El método de arriba es lo bastante completo para repetirlo con tu propio proyecto. Ese es el único benchmark que de verdad te importa.