El 9 de septiembre Apple publicó la RC de Xcode 27 y abrió el envío de apps para los nuevos sistemas. En el mismo anuncio, casi en letra pequeña: a partir de abril de 2027, el App Store dejará de aceptar builds hechas con SDK antiguos. Si tu CI es un par de Mac mini debajo de un escritorio, ya conoces el ritual que empieza ahora: actualizar macOS en los agentes, actualizar Xcode, recompilar todo lo que se rompió por el camino. En Xcode Cloud, el entorno nuevo simplemente aparece en un desplegable: el otoño pasado, Xcode 26 estuvo disponible allí el mismo día de su lanzamiento, el 15 de septiembre.
Buen momento, entonces, para desarmar esta nube de una vez: qué es, cuánto cuesta y dónde terminan sus capacidades. Spoiler sobre lo último: terminan exactamente en la frontera del ecosistema Apple, y convivir con esa frontera en una empresa que además tiene backend y equipo de Android es tema de otro artículo.
Qué es exactamente#
Xcode Cloud es un CI/CD gestionado, integrado en Xcode y App Store Connect. No administras runners: las builds corren sobre Apple silicon en los centros de datos de Apple, y las versiones de macOS y Xcode se eligen de un desplegable.
La unidad de configuración es el workflow. Tiene cuatro partes:
- condición de inicio — cambio en una rama o etiqueta, pull request, calendario o arranque manual;
- entorno — versión de Xcode y de macOS (betas incluidas);
- acciones — build, test, analyze, archive; los tests pueden correr en paralelo en varios simuladores;
- posacciones — distribución por TestFlight, envío al App Store, notificaciones en Slack.
Proveedores de git compatibles: GitHub, GitHub Enterprise, GitLab (incluido self-managed), Bitbucket. El primer workflow se crea desde Xcode en un solo diálogo: Integrate → Create Workflow, y unos quince minutos después tienes tu primera build en la nube — sin un solo archivo YAML y sin negociar en qué escritorio vivirá la máquina de builds.
Desde el año pasado la barrera de entrada bajó aún más: se puede compilar y testear sin membresía de pago del Developer Program. Para TestFlight y publicar, la cuenta sigue siendo necesaria.
Firmar deja de ser un trabajo#
El dolor histórico del CI de iOS nunca fue compilar. Es la firma: certificados, provisioning profiles, sus vencimientos silenciosos, un repositorio cifrado para fastlane match y todo lo demás. Existe una clase entera de herramientas solo porque firmar en CI es una profesión aparte.
En Xcode Cloud esa profesión no existe. Cloud signing crea y rota los certificados por su cuenta, los perfiles se renuevan sin ti, y el clásico «¿en qué Mac está el certificado de distribución?» desaparece del proceso. Ese es, probablemente, el argumento más fuerte a favor de todo el servicio — más fuerte que el precio.
En la misma caja vienen extras agradables: estados de build directamente en el pull request de GitHub (y puedes hacerlos obligatorios para el merge), reportes de tests y cobertura dentro del propio Xcode, distribución por TestFlight como una casilla en la configuración del workflow.
La economía#
Desde enero de 2024, la membresía del Developer Program ($99/año) incluye 25 horas de cómputo al mes. A partir de ahí, planes de pago:
| Plan | Precio | Por hora |
|---|---|---|
| 25 horas | incluidas en la membresía | — |
| 100 horas | $50/mes | $0.50 |
| 250 horas | $100/mes | $0.40 |
| 1000 horas | $400/mes | $0.40 |
Para comparar: un runner de macOS en GitHub Actions cuesta $0.08 por minuto — $4.80 la hora, casi un orden de magnitud más. La comparación no es del todo justa: el hardware difiere, y en Xcode Cloud los destinos de test paralelos consumen horas simultáneamente. Aun con esas correcciones, la nube de Apple es una de las builds de macOS más baratas del mercado.
Las horas no usadas expiran al final del mes. Cuenta rápida sobre un proyecto real: una build con tests toma 12–15 minutos, así que las 25 horas gratis cubren alrededor de cien ejecuciones. Para un desarrollador en solitario, de sobra. Para un equipo de cinco con CI en cada push, una semana.
Dónde duele#
Ahora la columna honesta del «en contra», sin la cual el cuadro no significa nada.
Solo ecosistema Apple. iOS, iPadOS, macOS, watchOS, tvOS, visionOS — y ya. Ni backend, ni Android, ni Docker, ni Linux. Xcode Cloud no será el CI de tu empresa — solo el CI de tu equipo de iOS.
La personalización son tres scripts. Todo lo que sale de las acciones estándar vive en ci_scripts/: ci_post_clone.sh, ci_pre_xcodebuild.sh, ci_post_xcodebuild.sh. No hay grafo de pasos arbitrario como en GitHub Actions. Las dependencias SPM se resuelven de fábrica; CocoaPods y herramientas propias corren por tu cuenta, vía post-clone y Homebrew.
La configuración no vive en git. El workflow se configura en App Store Connect, no en un archivo junto al código. La API permite leerlos y crearlos, pero el «config as code» tendrás que construirlo tú — de fábrica no existe.
Apple dicta las versiones del entorno. En diciembre Xcode Cloud tuvo un bug conocido: el export archive para distribución de desarrollo fallaba en Xcode 26.2, y el workaround oficial era «compila en 26.1». Lo arregla Apple — pero los plazos también los elige Apple, no tú. Súmale las colas: antes de los grandes lanzamientos de Apple, las builds esperan notablemente más.
Secretos y política. Los secretos son variables de entorno en la interfaz de App Store Connect. No hay integración con Vault, no hay runners self-hosted ni los habrá: si seguridad exige que «las builds no salgan del perímetro», la conversación termina en este punto.
A quién sí, a quién no#
Para desarrolladores en solitario y equipos de hasta ~5 ingenieros iOS con un producto puramente Apple — sí, casi sin pensarlo. Las horas gratis alcanzan, la firma desaparece como categoría de trabajo, TestFlight queda a dos clics, y el costo de mantener un par de Mac mini envejeciendo suele subestimarse justo hasta los plazos de abril del App Store.
Para equipos con requisitos duros de reproducibilidad, grafos de pasos propios, secretos en Vault y política de «todo dentro del perímetro» — no. O, lo más interesante, un híbrido: el pipeline común de la empresa se queda donde está, y Xcode Cloud se convierte en un ejecutor de un rol concreto — compilar y distribuir la app de iOS.
Cómo se cablea ese híbrido en la práctica — lanzar builds vía App Store Connect API, webhooks de vuelta al pipeline, artefactos y monorepos — lo cubre el siguiente artículo.
