La promesa del Vibe Coding es sencilla; describes una aplicación, la inteligencia artificial escribe buena parte del código y, en pocas horas, tienes algo que antes podía requerir semanas. Para startups, departamentos internos y empresas de servicios tecnológicos, la idea es demasiado atractiva como para ignorarla.
Pero hay una segunda parte menos visible: que una IA pueda generar una app no significa que Apple o Google vayan a permitir publicarla.
El conflicto empieza justo ahí. El Vibe Coding ha reducido la barrera para crear software, pero las grandes tiendas de aplicaciones siguen funcionando con reglas pensadas para controlar qué código llega al dispositivo del usuario. Y en el caso de iOS, esa frontera es especialmente estricta.
El nuevo atajo para crear software
Vibe Coding es una forma de desarrollo asistido por IA en la que el usuario describe lo que quiere construir mediante prompts. La herramienta genera código, propone estructuras, corrige errores, añade pantallas, crea APIs o incluso ayuda a desplegar el proyecto.
No es magia. Tampoco es desarrollo sin programadores. Es una nueva capa de abstracción.
Antes, el proceso empezaba escribiendo código. Ahora puede empezar con una frase como esta; ejemplo:
Crea una app para registrar incidencias informáticas de clientes.
Debe permitir crear tickets, asignar prioridad, cambiar estado y filtrar por técnico.
Usa React, Node.js y PostgreSQL.
La IA puede devolver una estructura inicial del proyecto, componentes, rutas de API, modelos de base de datos y validaciones. Eso permite avanzar más rápido, sobre todo en prototipos, herramientas internas y primeras versiones.
La diferencia está en lo que ocurre después. Un prototipo generado por IA puede parecer producto. Pero no lo es necesariamente.
El problema no es que la IA escriba código
Apple y Google no prohíben, de forma general, que una app haya sido creada con ayuda de IA. Una empresa puede usar ChatGPT, Copilot, Cursor, Replit, Lovable u otras herramientas para escribir código y luego publicar una aplicación.
El problema aparece cuando la propia app permite generar, descargar o ejecutar código nuevo que cambia su funcionalidad después de haber pasado la revisión.
Apple lo expresa en sus normas de revisión: las apps no pueden descargar, instalar o ejecutar código que introduzca o cambie características o funcionalidades de la app tras la revisión. La regla admite excepciones limitadas para ciertos entornos educativos o de scripting, siempre bajo condiciones concretas.
En la práctica, eso significa que una app creada con IA puede ser aceptada. Pero una app que dentro de iOS permite crear otras apps, ejecutar código generado dinámicamente o modificar su comportamiento de forma no revisada puede ser rechazada.
La diferencia parece sutil. Para Apple no lo es.
Apple quiere revisar lo que el usuario va a ejecutar
El modelo de App Store se basa en una premisa: Apple revisa una app antes de que llegue al usuario. Si después de esa revisión la app puede transformarse en otra cosa mediante código descargado o generado, el sistema de control pierde fuerza.
Por eso el Vibe Coding choca con una zona sensible de iOS.
Ejemplo permitido:
Una empresa usa IA para crear una app de gestión de tickets.
El equipo técnico revisa el código.
La app se compila.
Se sube a App Store.
Apple revisa el binario final.
Ejemplo problemático:
Una app permite al usuario escribir:
«Crea una app de inventario con escáner y base de datos»
La plataforma genera código nuevo.
Ese código se ejecuta dentro de la app iOS.
La funcionalidad cambia sin pasar por revisión.
En el primer caso, la IA es una herramienta de desarrollo.
En el segundo, la IA convierte la app en una fábrica de software dentro del dispositivo.
Ese segundo escenario es el que puede activar las restricciones.
Google Play mira el problema desde otro ángulo
Google Play suele ser menos restrictivo que Apple con la ejecución y distribución de software, pero eso no significa que todo valga.
En Android, el foco está más repartido: seguridad, contenido generado por IA, privacidad, malware, engaño, protección de menores, permisos sensibles y mecanismos de reporte.
Google exige que las apps con contenido generado por IA incorporen medidas para que los usuarios puedan reportar contenido ofensivo o inadecuado dentro de la propia aplicación. También señala que las apps generativas deben evitar producir contenido prohibido, incluido contenido dañino, engañoso o que facilite abuso o malware.
Eso afecta directamente a las apps de Vibe Coding que permiten generar texto, imágenes, código o experiencias interactivas.
Un asistente que ayuda a crear una pantalla de login no plantea el mismo riesgo que una app que permite generar scripts, automatizaciones agresivas o código potencialmente malicioso.
Crear código no es lo mismo que ejecutarlo
Para empresas como @tuk.es esta es la distinción clave.
El Vibe Coding es útil si se usa como herramienta de producción interna.
Prompt → código → revisión técnica → pruebas → repositorio → despliegue
Es mucho más delicado cuando se convierte en producto final:
Prompt del usuario → código generado → ejecución inmediata dentro de la app
El primer flujo se parece al desarrollo asistido por IA.
El segundo se parece a una plataforma de ejecución dinámica.
Las tiendas de aplicaciones no tratan ambos casos igual.
Casos reales donde tiene sentido usar Vibe Coding
1. Prototipo de portal de soporte:
Una empresa necesita validar rápidamente una herramienta para gestionar incidencias.
Prompt:
Crea una primera versión de un portal de soporte técnico.
Debe tener:
– listado de tickets
– creación de tickets
– estados: abierto, en curso y cerrado
– prioridad: baja, media, alta y crítica
– filtro por estado y prioridad
Usa React con TypeScript y datos simulados.
Respuesta posible:
</>TypeScript
type TicketStatus = «abierto» | «en_curso» | «cerrado»;
type TicketPriority = «baja» | «media» | «alta» | «critica»;
type Ticket = {
id: number;
title: string;
client: string;
status: TicketStatus;
priority: TicketPriority;
};
const tickets: Ticket[] = [
{
id: 1,
title: «No funciona el correo»,
client: «Cliente A»,
status: «abierto»,
priority: «alta»,
},
{
id: 2,
title: «Instalación de impresora»,
client: «Cliente B»,
status: «en_curso»,
priority: «media»,
},
];
export function TicketList() {
return (
<section>
<h2>Tickets de soporte</h2>
<table>
<thead>
<tr>
<th>Cliente</th>
<th>Incidencia</th>
<th>Estado</th>
<th>Prioridad</th>
</tr>
</thead>
<tbody>
{tickets.map((ticket) => (
<tr key={ticket.id}>
<td>{ticket.client}</td>
<td>{ticket.title}</td>
<td>{ticket.status}</td>
<td>{ticket.priority}</td>
</tr>
))}
</tbody>
</table>
</section>
);
}
Esto sirve para enseñar una idea. No basta para producción.
Faltan autenticación, permisos, persistencia, logs, validaciones, pruebas, control de errores y seguridad.
2. API interna para incidencias
Prompt:
Crea una API en Express y TypeScript para gestionar tickets.
Debe permitir crear tickets, listar tickets y cerrar un ticket.
Usa memoria local.
Incluye validación básica.
Respuesta posible:
import express, { Request, Response } from «express»;
const app = express();
app.use(express.json());
type Status = «open» | «closed»;
type Priority = «low» | «medium» | «high» | «critical»;
type Ticket = {
id: number;
client: string;
subject: string;
priority: Priority;
status: Status;
};
let tickets: Ticket[] = [];
let nextId = 1;
app.get(«/tickets», (_req: Request, res: Response) => {
res.json(tickets);
});
app.post(«/tickets», (req: Request, res: Response) => {
const { client, subject, priority } = req.body;
const allowedPriorities: Priority[] = [
«low»,
«medium»,
«high»,
«critical»,
];
if (!client || !subject || !priority) {
return res.status(400).json({
error: «client, subject and priority are required»,
});
}
if (!allowedPriorities.includes(priority)) {
return res.status(400).json({
error: «Invalid priority»,
});
}
const ticket: Ticket = {
id: nextId++,
client,
subject,
priority,
status: «open»,
};
tickets.push(ticket);
return res.status(201).json(ticket);
});
app.patch(«/tickets/:id/close», (req: Request, res: Response) => {
const id = Number(req.params.id);
const ticket = tickets.find((item) => item.id === id);
if (!ticket) {
return res.status(404).json({
error: «Ticket not found»,
});
}
ticket.status = «closed»;
return res.json(ticket);
});
app.listen(3000, () => {
console.log(«Support API running on port 3000»);
});
Este código es útil para una demo. Pero también muestra el riesgo del Vibe Coding: parece una API real, aunque todavía no tiene base de datos, autenticación, autorización ni protección contra abuso.
El siguiente prompt debería ser:
Revisa esta API como si fuera a entrar en producción.
Identifica riesgos de seguridad, problemas de arquitectura y cambios necesarios.
No escribas código nuevo todavía.
Una buena respuesta debería señalar, como mínimo:
– No hay autenticación.
– No hay autorización por roles.
– Los datos se pierden al reiniciar el servidor.
– No hay limitación de peticiones.
– No hay logs.
– No hay validación fuerte del esquema de entrada.
– No hay tests.
– No hay separación entre rutas, servicios y persistencia.
Confundir velocidad con madurez, un riesgo empresarial
El Vibe Coding cambia la economía del prototipo. Una empresa puede enseñar una demo antes, validar una idea antes y reducir el coste inicial de exploración. Pero también puede crear una trampa: software que parece terminado porque tiene interfaz, botones y respuestas. Ese es el riesgo más serio.
Un producto empresarial necesita:
– arquitectura mantenible
– seguridad
– pruebas
– control de versiones
– gestión de errores
– privacidad
– permisos
– auditoría
– documentación
– despliegue controlado
– cumplimiento de normas de plataforma
La IA puede ayudar en todo eso. Pero no lo garantiza.
Cómo usar Vibe Coding sin meterse en problemas
La regla práctica es sencilla: usar IA para generar código no es el problema. Saltarse la revisión técnica sí lo es.
Flujo recomendado:
1. Definir el caso de uso.
2. Generar una primera versión con IA.
3. Revisar el código.
4. Pedir a la IA que explique riesgos y supuestos.
5. Añadir tests.
6. Revisar seguridad.
7. Sustituir datos simulados por backend real.
8. Validar privacidad y cumplimiento.
9. Compilar y publicar una versión cerrada y revisable.
Flujo peligroso:
1. El usuario pide una app.
2. La IA genera código.
3. La app ejecuta ese código directamente.
4. Las funciones cambian sin revisión.
5. Se intenta publicar en App Store o Google Play.
En iOS, ese segundo flujo puede chocar directamente con la prohibición de ejecutar código que cambie la funcionalidad revisada.
En Google Play, el problema puede desplazarse hacia seguridad, generación de contenido dañino, abuso de permisos o falta de mecanismos de reporte.
Checklist antes de publicar una app creada con IA
[ ] La IA se ha usado como herramienta de desarrollo, no como sustituto de revisión.
[ ] El código final está en repositorio.
[ ] No se ejecuta código dinámico no revisado en iOS.
[ ] No se descargan funciones nuevas que cambien la app tras la revisión.
[ ] Hay autenticación si existen cuentas de usuario.
[ ] Hay autorización si existen roles.
[ ] No hay claves API en frontend.
[ ] Hay política de privacidad.
[ ] Se validan datos de entrada.
[ ] Hay control de errores.
[ ] Hay tests.
[ ] Hay revisión de dependencias.
[ ] Si la app genera contenido con IA, hay moderación y reporte dentro de la app.
[ ] Se han revisado las normas de App Store y Google Play antes de enviar.
La oportunidad para empresas tecnológicas
Para muchas empresas el Vibe Coding no debería venderse como “crear apps sin programar”. Esa promesa es llamativa, pero débil.
La propuesta más sólida es otra:
Crear prototipos más rápido.
Reducir tiempo de validación.
Automatizar partes repetitivas del desarrollo.
Acelerar documentación y pruebas.
Convertir ideas en primeras versiones revisables.
El verdadero valor del Vibe Coding está en combinar la velocidad de la IA con criterio técnico. La inteligencia artificial puede escribir código y acelerar una demo, pero Apple y Google pueden frenar su distribución si la app no cumple sus normas. Por eso, el equipo técnico sigue siendo clave: es quien convierte una idea generada en minutos en un producto publicable, mantenible y defendible. El Vibe Coding no elimina las reglas del software; las hace más visibles. Antes, muchas ideas no llegaban a convertirse en app por el coste inicial de desarrollo. Ahora pueden transformarse en una demo en horas, lo que cambia el mercado, pero también aumenta el número de proyectos que llegan a App Store y Google Play sin entender sus restricciones. La pregunta ya no es solo si una app puede construirse con IA, sino si puede publicarse, mantenerse y sostenerse técnicamente. Ahí empieza el trabajo real.
