Por qué las aplicaciones de pago creadas con vibe-coding son rechazadas en la App Store

Las aplicaciones de pago creadas con vibe-coding son rechazadas en la App Store a un ritmo mayor que casi cualquier otra cosa en la cola de revisión, y los motivos no suelen tener nada que ver con la calidad del código. Una aplicación creada con vibe-coding (una que construyó describiendo lo que quería a un asistente de IA y lanzando lo que este escribió) puede parecer indistinguible de un trabajo profesional. La revisión de Apple no califica el código. Comprueba quién envió la aplicación, qué mecanismo de pago gestiona cada tipo de producto, si las autorizaciones de hardware se aprobaron por separado y si el revisor puede completar una transacción real. Esas son exactamente las cosas que un asistente de IA no puede generar.

Este es el muro con el que todos se topan después de crear un punto de venta personalizado con un modelo de IA: el código existe en una tarde, pero llevarlo a un iPhone como una aplicación de pago real es un proceso de cumplimiento, no una tarea de programación.

¿Su IA dirigió los pagos a través del sistema equivocado?

El rechazo más común es utilizar el mecanismo de pago incorrecto para los productos que se venden, y los asistentes de IA son inusualmente buenos para equivocarse en esto. Las Pautas de revisión de la App Store de Apple trazan una línea estricta. El contenido y los servicios digitales consumidos dentro de la aplicación deben utilizar la compra dentro de la aplicación de Apple según la Pauta 3.1.1. Los productos físicos y los servicios del mundo real (un café, un corte de pelo, un pedido enviado) deben hacer lo contrario según la Pauta 3.1.5(a): no pueden utilizar la compra dentro de la aplicación en absoluto y requieren un método de pago externo.

Un modelo de programación reproduce cualquier patrón de pago que haya dominado sus datos de entrenamiento (plantillas de compra dentro de la aplicación de tutoriales de suscripción o un SDK de pago web de ejemplos de comercio electrónico) sin preguntar nunca qué está vendiendo. Pídale "una aplicación que acepte pagos" y obtendrá una de las dos opciones, elegida por estadísticas en lugar de por las reglas de Apple. Las reglas también cambian según la tienda: tras el fallo de Epic de 2025, las aplicaciones en la tienda de EE. UU. pueden incluir enlaces a opciones de compra externas para productos digitales, pero esa excepción se aplica solo en los Estados Unidos. Una aplicación distribuida en todo el mundo todavía tiene que cumplir con la regla más estricta en todos los demás lugares.

¿Tiene siquiera permitido enviar una aplicación de pago?

Apple espera que las aplicaciones que gestionan la administración de dinero o servicios financieros sean enviadas por la institución que realmente realiza esos servicios, con las licencias requeridas en cada región donde la aplicación esté disponible; esa es la Pauta 3.2.1. Un creador independiente que lanza una aplicación de pagos generada por IA no es una institución financiera con licencia, y tampoco lo es una agencia que envía una para un cliente. Ofrecer la aplicación en un país donde no existe la licencia de transferencia de dinero es el mismo rechazo con un matasellos diferente.

Los revisores de Apple no evalúan si su programa de cumplimiento es bueno; comprueban si la entidad correcta envió la aplicación y la rechazan cuando no es así. Ninguna instrucción soluciona eso.

¿Por qué el pago sin contacto es su propio proceso de aprobación?

Aceptar tarjetas sin contacto en un iPhone requiere la autorización de Tap to Pay on iPhone, una solicitud independiente para Apple, ajena a la revisión de la aplicación, otorgada a una entidad legal en lugar de a una base de código. La autorización de desarrollo suele aprobarse en uno o dos días. La autorización de publicación pasa por el equipo de operaciones de Apple, suele tardar de una a dos semanas y requiere trabajar con un proveedor de servicios de pago compatible. Un asistente de IA escribirá con gusto el código de tap-to-pay sin mencionar nada de esto; si realiza el envío antes de que se otorgue la autorización, la aplicación será rechazada.

La aceptación con tarjeta presente también arrastra requisitos que Apple no posee: hardware de lectura certificado, reglas EMV y alcance PCI para cualquier cosa que toque datos de tarjetas. Nada de eso surge de un modelo que escribe Swift.

¿Puede el revisor realmente finalizar una transacción?

La Pauta 2.1, Integridad de la aplicación, descarta silenciosamente más aplicaciones de pago que las propias reglas de pagos. Los revisores deben poder probar la aplicación completa, incluido el flujo de pago. Una aplicación de pago suele requerir una cuenta de comerciante, verificación de identidad y, a veces, una cuenta bancaria, cosas a las que un revisor no puede registrarse durante la revisión. Los envíos creados con vibe-coding fallan aquí constantemente, porque el creador a menudo nunca aprovisionó una cuenta de comerciante real por sí mismo; la aplicación solo se probó con datos simulados que la IA generó junto con ella. Sin una cuenta de demostración que funcione y una forma de ejecutar una transacción de prueba, la aplicación se rechaza por estar incompleta, y cada reenvío cuesta otro ciclo de revisión.

Entonces, ¿qué es lo que realmente se lanza?

La parte difícil nunca fue el código. Un asistente de IA puede producir una interfaz de pago que funcione en una tarde, pero la distribución en la App Store es una carrera de obstáculos de autorizaciones, licencias y políticas de revisión que queda completamente fuera del alcance de cualquier instrucción. La demostración funciona; la infraestructura aún no existe.

Para un comerciante que vende productos físicos, la conclusión práctica es más sencilla: no entre en la cola. Su negocio necesita un proceso de pago que funcione, no su propia publicación en la App Store; los gastos generales de licencias, certificación de hardware y revisión solo tienen sentido para las empresas cuyo producto es el propio software de pagos. Gestione el mostrador en una plataforma de POS que ya haya absorbido esos costos (Final está construida exactamente de esta manera: pagos a través de Final Pay con hardware de terminal certificado, no alguna aplicación propia que publicar) y destine el dinero del ciclo de revisión a cosas que impulsen los ingresos, como un flujo de pago más rápido y tarifas de tarjeta efectivas más bajas.

El proceso de revisión de Apple existe por buenas razones: las aplicaciones de dinero que fallan perjudican a personas reales. Simplemente no es un proceso que la mayoría de los comerciantes necesiten superar, sin importar quién o qué haya escrito la aplicación.