Nadie te dice que puedes publicar apps en la App Store sin tocar Xcode ni una vez

Hay una verdad que nadie en el ecosistema Apple quiere admitir: Xcode es una pesadilla. Ocupa 120GB, tiene un editor de texto que se siente de 2010, y cada actualización trae 3 bugs nuevos por cada feature que arregla.

Pero hay un secreto que los podcasters tech de silicon valley no te cuentan: no tienes que abrirlo jamás. Literalmente. Puedes tener Xcode instalado, generar tu proyecto, compilar, firmar, notarizar, y publicar en la App Store sin ver la interfaz gráfica ni una sola vez.

Y sí, funciona con vibe coding — puedes escribir toda la app con Claude Code, Cursor, o ChatGPT, y el pipeline de build lo maneja un solo script. Cero clicks. Cero frustration.

¿Por qué esto importa en LATAM?

Porque no todo el mundo tiene una MacBook Pro M4 Ultra con 5 monitores. En Latinoamérica, muchos desarrolladores tienen Macs viejas, Mac minis prestadas, o incluso usan máquinas virtuales para compilar. Abrir Xcode en esas condiciones es una sentencia de muerte para la productividad.

Pero si puedes correr una terminal, puedes publicar apps de Apple. Y con los LLMs actuales, puedes escribir una app completa sin escribir una línea de Swift manualmente si no quieres.

El stack que necesitas (spoiler: no es Xcode)

El setup es sorprendentemente simple, y está documentado por Scott Willsey en un blog post que explotó en Hacker News con 236 puntos y 111 comentarios. La gente necesita saber esto.

1. Xcode instalado, pero cerrado para siempre
Sí, necesitas tener Xcode instalado porque dentro viven xcodebuild, notarytool, stapler y devicectl. Pero nunca lo abres. Lo confirmas con xcode-select -p y te olvidas.

2. XcodeGen
Esta herramienta es la clave. En vez de dejar que Xcode maneje el .xcodeproj (que cambia solo cada vez que respiras), defines todo en un archivo project.yml. Un archivo de texto plano, legible, que se versiona en git sin conflicto. Y xcodegen regenera el proyecto entero desde ese YAML en cada build.

3. Un script release.sh
Este es el corazón. Un solo archivo que hace: archive → Developer ID sign → notarize → staple → install. Todo automático. Lo escribes una vez y nunca más piensas en el pipeline de publicación.

4. Tu LLM favorito
El autor lo dice claro: "si tienes dudas sobre cómo hacer algo, apunta Claude Code o tu herramienta de IA a este blog post y deja que lo resuelva". Para eso están.

El setup único (lo único que requiere GUI)

OK, no es completamente cero-GUI. Hay tres cosas que tienes que hacer una vez con la interfaz gráfica de Xcode:

• Aceptar la licencia (o con sudo xcodebuild -license accept)
• Agregar tu Apple ID en Settings → Accounts
• Crear un certificado Developer ID Application — necesario para notarizar la app y que pase Gatekeeper

⚠️ Necesitas una cuenta Apple Developer paga. Son $99/año. No hay forma de evitarlo si quieres distribuir fuera del App Store o notarizar. Pero una vez que la tienes, el certificado se guarda en tu llavero y xcodebuild lo encuentra solo.

Después de eso, nunca más abres Xcode. Ni para builds, ni para debugging, ni para nada.

Vibe coding real: cómo funciona el día a día

Tu flujo diario se ve así:

1. Escribes código en cualquier editor (VS Code, Neovim, Cursor, lo que sea)
2. Corres xcodegen para regenerar el proyecto desde tu project.yml
3. Corres xcodebuild desde la terminal para compilar
4. Si todo pasa, corres el script de release y tu app está notarizada y lista para distribuir

El secreto es que xcodebuild es una herramienta de línea de comandos extremadamente potente. Todo lo que hace la GUI de Xcode, xcodebuild lo hace desde la shell. Y como es headless, se integra perfectamente con CI/CD, GitHub Actions, o tu propio pipeline.

¿Y para iOS?

El mismo principio aplica. Necesitas devicectl para instalar en dispositivos físicos, y el mismo pipeline de notarización. Las diferencias son mínimas:

• Para App Store Connect, usas xcrun altool o transporter para subir el build
• Para dispositivos físicos, devicectl funciona desde la terminal — ni siquiera necesitas abrir Xcode para instalar en tu iPhone
• Los provisioning profiles se manejan con fastlane o con la web de Apple Developer

La pregunta incómoda: ¿Apple quiere que esto sea fácil?

La respuesta corta es no. Apple tiene un incentivo perverso: mientras más miserable sea la experiencia de desarrollo, más desarrolladores pagan por MacBooks Pro, más contenido se queda en su ecosistema. Xcode es el peaje de entrada al jardín amurallado.

Pero herramientas como XcodeGen, Fastlane, y la propia CLI de Apple demuestran que el jardín se puede abrir con una llave inglesa. No necesitas amar Xcode. Necesitas usarlo como infraestructura, no como herramienta.

¿Por qué esto es VIBE CODING real?

Porque el flujo descrito arriba — LLM escribe el código → xcodegen arma el proyecto → xcodebuild compila → script release publica — es 100% automatizable. Puedes tener un pipeline donde:

1. Le dices a Claude: "crea una app de notas con sincronización iCloud"
2. Claude escribe el código Swift + el project.yml
3. Un script corre xcodegen && xcodebuild
4. Si hay errores, se los pasas al LLM para que los corrija
5. Cuando el build pasa, el release script lo notariza y lo deja listo para distribuir

Eso es vibe coding real. No lo que venden los influencers de Twitter (abrir Cursor, escribir un prompt, y esperar que salga una app mágicamente). Es ingeniería de verdad, con herramientas de línea de comandos, CI/CD, y un LLM como copiloto.

Conclusión: Xcode es un martillo, no la casa

Xcode no es tu entorno de desarrollo. Xcode es la biblioteca de herramientas que Apple te obliga a instalar. Trátalo como tal: instálalo, olvídate de su existencia, y usa las herramientas reales que viven dentro de él.

El futuro del desarrollo Apple no está en una interfaz gráfica del 2007. Está en scripts, YAML, terminal, y LLMs. Y si estás en LATAM con una Mac del 2019 y sueños de publicar tu app, este es el camino.

Comparte esto con alguien que todavía abre Xcode y sufre en silencio.

¿Tú ya usas XcodeGen o sigues peleando con la GUI de Apple? Cuéntame en los comentarios 👇