Mac mini M6 vs runner macOS de GitHub Actions: el benchmark
En pocas palabras: Según el benchmark de MacRun publicado el 4 de noviembre de 2026, un Mac mini M6 compiló la app Wikipedia iOS casi el doble de rápido que el runner hosted macOS de GitHub Actions: 86 segundos de clean build contra 183, y un job completo de CI en 27 segundos con caché tibia frente a 269 segundos en GitHub.
MacRun, la empresa que alquila Mac minis dedicados para CI, publicó un benchmark el 4 de noviembre de 2026 comparando su Mac mini con chip M6 contra el runner macOS hosted estándar de GitHub Actions. El resultado: compilar la app Wikipedia iOS fue casi el doble de rápido en el M6, con un clean build de 86 segundos contra 183 en el runner de GitHub, y un job completo de CI que pasó de 269 segundos a 27 con caché tibia.
Un runner macOS de GitHub Actions es una máquina virtual efímera que GitHub levanta para cada job de integración continua en macOS, usada sobre todo por equipos que compilan apps iOS o macOS. Cada corrida arranca desde cero: sin caché, sin DerivedData previo, sin paquetes descargados. Ese diseño tiene una ventaja (aislamiento total entre jobs) y un costo directo: tiempo de build más largo y una factura por minuto que se acumula con cada push.
En este artículo:
- En 30 segundos
- ¿Cómo funciona el runner hosted de macOS en GitHub Actions?
- ¿Cómo se armó el benchmark entre el Mac mini M6 y el runner de GitHub?
- ¿Cuánto más rápido es el Mac mini M6 compilando en Xcode?
- ¿Cuánto cuesta un job de CI en macOS en GitHub Actions comparado con un Mac mini dedicado?
- ¿A partir de cuántos jobs por día conviene pagar por un Mac dedicado?
- ¿Qué está confirmado y qué no en este benchmark?
- ¿Qué limitaciones tiene este benchmark antes de tomar una decisión?
- Errores comunes al evaluar runners de CI para iOS
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- El Mac mini M6 de MacRun completó un clean build de Xcode en 86 segundos contra 183 del runner hosted de GitHub, una mejora del 53%.
- Los 220 tests unitarios del paquete WMFData corrieron en 17 segundos en el M6 versus 44 en el runner de GitHub (-61%).
- Un job completo de CI bajó de 269 segundos en GitHub a 27 segundos en el M6 con caché tibia, según las pruebas del 24 de septiembre de 2026.
- GitHub factura por minuto redondeado hacia arriba: ese mismo job de 269 segundos cuesta unos 31 centavos de dólar a $0.062 el minuto.
- MacRun cobra $139 al mes por el Mac mini dedicado, sin cargo adicional por job. Con esos dos números por sí solos ya se puede calcular a partir de cuántos jobs por mes empieza a convenir uno u otro esquema (lo hacemos más abajo).
¿Cómo funciona el runner hosted de macOS en GitHub Actions?
El runner hosted de macOS en GitHub Actions es una máquina virtual que GitHub provisiona desde cero por cada ejecución de workflow, sin estado persistente entre jobs. Según la metodología publicada por MacRun, la VM estándar corre sobre un Apple M2 Pro virtualizado con 5 cores y 14 GB de memoria, con macOS 26.6.2 y Xcode 26.6 (build 17F113).
Ese modelo tiene sentido para equipos chicos o proyectos esporádicos: no hay hardware que mantener, no hay que parchear nada. El problema aparece cuando tenés pushes constantes. Cada job arranca con el DerivedData vacío y los paquetes de Swift sin descargar, así que todo lo que en una máquina persistente sería incremental, ahí es siempre un clean build completo.
¿Y qué pasa con el precio? GitHub cobra $0.062 por minuto en el runner estándar, redondeando cada job hacia el minuto superior. Eso significa que un job de 269 segundos (4 minutos y 29 segundos) se factura como 5 minutos completos, unos 31 centavos de dólar por corrida. Complementá con nuestra comparativa de plataformas CI/CD en 2026.
¿Cómo se armó el benchmark entre el Mac mini M6 y el runner de GitHub?
MacRun compiló el proyecto open source wikimedia/wikipedia-ios en el commit 8691a89, usando el simulador de iPhone 17 en iOS 26.5, creado de la misma forma en ambas máquinas. Corrieron tres pruebas completas por máquina y reportaron la mediana, con la caché de paquetes y DerivedData borrados antes de cada corrida.
Los pasos medidos fueron cinco: descarga de paquetes con xcodebuild -resolvePackageDependencies, clean build con build-for-testing, build incremental (agregando un comentario en un archivo Swift), build no-op (repitiendo sin cambios) y los 220 tests unitarios del paquete WMFData con test-without-building. La firma de código estuvo desactivada, como suele pasar en builds de CI para simulador.
Las pruebas se hicieron el 24 de septiembre de 2026. Este post reemplaza un benchmark anterior de MacRun con el chip M4, lo cual tiene lógica: si vas a comparar hardware, mejor hacerlo con el chip que tenés hoy, no con el de hace dos generaciones.
¿Cuánto más rápido es el Mac mini M6 compilando en Xcode?
El Mac mini M6 fue aproximadamente el doble de rápido compilando que el runner hosted de GitHub, con mejoras de entre 50% y 61% según el paso medido. La descarga de paquetes fue la excepción, con solo 8% de diferencia, porque ambas máquinas bajan los mismos paquetes de GitHub por conexiones rápidas. Lo explicamos a fondo en la migración a runners macOS en GitHub Actions.
Ponele que estás esperando el clean build de tu proyecto. En el runner de GitHub tardás 183 segundos. En el M6 de MacRun, 86. La diferencia se mantiene en los tests: 44 segundos contra 17 para correr los 220 tests unitarios del paquete WMFData.
| Paso | GitHub-hosted (macos-26) | MacRun M6 | Cambio |
|---|---|---|---|
| Descarga de paquetes | 43 s | 39 s | -8% |
| Clean build | 183 s | 86 s | -53% |
| Build incremental | 21 s | 10 s | -51% |
| Build no-op | 20 s | 10 s | -50% |
| 220 tests unitarios | 44 s | 17 s | -61% |
El build incremental tocó un solo archivo, con un cambio mínimo: un comentario. La mayoría de esos 10 segundos en el M6 es Xcode planificando el build, no compilando código real. Por eso el incremental y el no-op quedan casi idénticos. Un cambio en un archivo usado por toda la app tardaría más en ambas máquinas, eso no lo midieron.
¿Cuánto cuesta un job de CI en macOS en GitHub Actions comparado con un Mac mini dedicado?
Un job completo de CI en el runner hosted de GitHub tardó 269 segundos de mediana (descarga, clean build y tests), mientras que el mismo job en el M6 de MacRun con caché vacía tardó 142 segundos, y con caché tibia (solo build incremental y tests) bajó a 27 segundos. Esa es la diferencia que un equipo siente en el día a día: un job que tardaba cuatro minutos y medio termina en menos de treinta segundos.
El tema es que la tabla de pasos sueltos no refleja cómo trabaja cada máquina en producción. Un runner hosted arranca cada job vacío: tiene que bajar paquetes, compilar desde cero y recién después testear. Un Mac dedicado conserva su carpeta de build entre jobs, así que después de un cambio chico solo recompila lo que cambió. Ya lo cubrimos antes en si conviene usar runners autohospedados.
En plata: ese job de 269 segundos en GitHub se factura como 5 minutos redondeados a $0.062 cada uno, unos 31 centavos de dólar por corrida. El Mac mini M6 de MacRun cuesta $139 al mes en plan flat, sin cargo extra por job. Si tu equipo hace decenas de pushes por día, hacé la cuenta: los minutos ahorrados se acumulan en horas de espera que nadie recupera.
¿A partir de cuántos jobs por día conviene pagar por un Mac dedicado?
Los números de MacRun sirven para algo más que mostrar que su máquina es más rápida: con el precio por minuto de GitHub y el costo flat del M6 se puede armar un criterio de punto de equilibrio, sin necesidad de testear nada propio. Tomando el peor caso para GitHub (job con VM fresca, 269 segundos, que redondea a 5 minutos a $0.062 cada uno), cada job hosted cuesta unos $0.31. Dividiendo el plan flat de MacRun ($139/mes) por ese costo por job, se llega a que hacen falta aproximadamente 448 jobs al mes para que el gasto en GitHub iguale al del Mac dedicado. Repartido en 20 días laborales, son unos 22 jobs por día; repartido en 30 días corridos, unos 15 por día.
Ese número no está en el benchmark original, pero se deriva directamente de los dos precios que MacRun publicó, así que es un piso razonable para decidir sin inventar nada: si tu equipo corre menos de esa cantidad de jobs por día, el runner hosted sigue siendo la opción más barata en dólares, aunque sea más lento. Si corre más, el Mac dedicado empieza a pagarse solo, y encima ahorra el tiempo de espera que el benchmark mide en segundos pero que en la práctica se siente en minutos muertos por desarrollador.
Ejemplo hipotético (no son datos reales de ningún equipo, solo una ilustración con los precios de la fuente): pensemos en dos equipos ficticios, “Equipo A” y “Equipo B”. Equipo A hace 5 pushes por día entre sus tres desarrolladores: a $0.31 el job, eso es menos de $2 diarios en GitHub, muy por debajo del punto de equilibrio. Para Equipo A, pagar $139 al mes por un Mac dedicado sería gastar de más, aunque gane velocidad. Equipo B, en cambio, tiene un pipeline con tests en cada commit y corre 30 jobs por día entre varios repos: a $0.31 cada uno, son cerca de $9.30 diarios, bastante por encima de los ~$4.60 diarios que representa el plan flat de MacRun ($139/30). Para Equipo B, el Mac dedicado no solo sale más barato en dólares: además le devuelve minutos de espera en cada push. La cuenta cambia según cuántos jobs corra cada equipo real, pero el mecanismo para decidir es ese: comparar tu volumen diario de jobs contra ese umbral de ~15 a 22 por día.
¿Qué está confirmado y qué no en este benchmark?
Confirmado:
- Las cifras de tiempo por paso y por job completo, publicadas por MacRun con metodología reproducible sobre el proyecto wikimedia/wikipedia-ios.
- Las especificaciones de hardware de ambas máquinas, impresas por cada corrida antes de compilar: M2 Pro virtual de 5 cores en GitHub, M6 de 12 cores bare metal en MacRun.
- El precio del runner hosted de GitHub, $0.062 por minuto, y el plan flat de MacRun a $139 mensuales.
No confirmado o con reservas:
- Si el ahorro se replica en otros proyectos. MacRun mismo lo aclara: el método es reproducible, pero cada codebase tiene su propio perfil de build.
- El impacto real de actions/cache. Cachear los paquetes de Swift en GitHub Actions reduciría la descarga, pero no el clean build, que es la mayor parte del tiempo medido.
- Comparabilidad perfecta entre versiones de macOS. El runner de GitHub corrió macOS 26.6.2 y el M6 corrió macOS 27.0, cada uno con lo que su dueño tenía instalado el día de la prueba.
- El punto de equilibrio de jobs por día calculado arriba asume que cada job hosted siempre arranca desde una VM fresca (el peor caso de 269 segundos). Si un equipo usa actions/cache y reduce ese costo por job, el umbral para que convenga el Mac dedicado sube.
¿Qué limitaciones tiene este benchmark antes de tomar una decisión?
MacRun vende el servicio de Mac mini M6 en alquiler, así que conviene leer sus propios números con ese dato en la cabeza. No invalida la metodología (publicaron el proyecto exacto, el commit y los comandos), pero el incentivo existe.
Tampoco testearon el target principal de la app de Wikipedia, porque necesita entitlements de app-group firmados y un build sin firma de CI no los tiene. Su test host se reiniciaba solo en ambas máquinas durante la prueba, así que no era una medida justa. Solo corrieron el paquete WMFData, con sus 220 tests.
MacRun deja el método documentado para que cualquiera lo reproduzca sobre su propio proyecto, que es, al final, el único benchmark que te sirve de verdad. En la comparativa real entre Jenkins y GitHub Actions profundizamos sobre esto.
Errores comunes al evaluar runners de CI para iOS
- Comparar solo el precio por minuto, sin contar el tiempo acumulado. 31 centavos por job parece poco hasta que multiplicás por cientos de pushes diarios en un equipo grande.
- Asumir que la caché de GitHub Actions resuelve todo. actions/cache ataca la descarga de paquetes, pero el clean build (183 de los 269 segundos del job completo en GitHub) sigue intacto.
- Ignorar que el hardware dedicado conserva estado entre jobs. La ventaja real del M6 no es el chip en sí, es que mantiene DerivedData y no arranca vacío cada vez.
- No medir en el proyecto propio. Un benchmark con la app de Wikipedia no predice cómo se comporta tu codebase, con sus propias dependencias y tamaño.
- Calcular el punto de equilibrio sin contar jobs reales. El umbral de ~15 a 22 jobs diarios que armamos arriba es un punto de partida con los precios publicados, no una garantía: contá tus propios pushes por día antes de decidir.
Preguntas Frecuentes
¿Cuánto tarda un build de Xcode en un runner de GitHub Actions?
Un clean build de la app Wikipedia iOS tardó 183 segundos de mediana en el runner hosted estándar de GitHub (macos-26), según el benchmark de MacRun del 24 de septiembre de 2026. El tiempo varía según el tamaño del proyecto y sus dependencias.
¿Vale la pena usar un Mac mini dedicado en vez del runner hosted de GitHub?
Depende del volumen de pushes diarios. Con los precios publicados ($0.062/minuto en GitHub, $139/mes flat en MacRun), el punto de equilibrio está en torno a 15-22 jobs por día: por debajo de eso, el runner hosted sigue siendo más barato en dólares aunque sea más lento; por encima, el Mac dedicado se paga solo y además ahorra tiempos de espera.
¿Cuánto cuesta un job de CI en macOS en GitHub Actions?
GitHub cobra $0.062 por minuto en el runner macOS estándar y redondea cada job hacia el minuto superior. Un job de 269 segundos (4 minutos 29 segundos) se factura como 5 minutos completos, unos 31 centavos de dólar por corrida.
¿Por qué un Mac mini es más rápido que una VM de GitHub para compilar iOS?
Porque el Mac mini conserva su carpeta de DerivedData y caché de paquetes entre jobs, mientras que el runner hosted de GitHub arranca una VM vacía cada vez. Con caché tibia, el M6 de MacRun completó un job de CI en 27 segundos contra 269 en GitHub.
¿Cómo se mide el tiempo de build en una app iOS real?
MacRun usó el proyecto open source wikimedia/wikipedia-ios en el commit 8691a89, compilando con xcodebuild para simulador de iPhone 17 en iOS 26.5, con tres corridas por máquina y reportando la mediana de cada paso.
Conclusión
El dato duro de este benchmark es que el Mac mini M6 compiló al doble de velocidad que el runner macOS hosted de GitHub Actions, y que con caché tibia un job completo de CI bajó de 269 a 27 segundos. Eso no significa que todo equipo deba migrar mañana: el ahorro depende de cuántos jobs corrés por día y de cuánto pesa la espera en tu flujo de trabajo real. Con los mismos precios que publicó MacRun, el cruce de números da un umbral orientativo de 15 a 22 jobs diarios para que el Mac dedicado empiece a convenir en dólares; por debajo de eso, seguís ganando con el runner hosted aunque sea más lento.
Lo que sí podés hacer, sin depender de los números de MacRun ni de nuestra cuenta de punto de equilibrio, es correr el mismo experimento sobre tu propio proyecto: clonar el repo, borrar DerivedData, medir tres corridas y comparar la mediana contra tu runner actual, y después contar cuántos jobs corre tu equipo por día de verdad. Es la única forma de saber si la diferencia te justifica el cambio de infraestructura, o si con actions/cache y algunos ajustes al pipeline te alcanza.
