Rechazos 4.3 del App Store: ¿llegar primero da ventaja?
· Matt Senter
Mi amigo y colega desarrollador independiente Alan Seales vio hace poco cómo rechazaban su app, Dumpling, bajo la Guideline 4.3: Spam de App Review de Apple. La he usado. El diseño está bien pensado, la implementación es sólida y entiende a las personas para las que fue creada. Me cuesta ver en ella un clon desechable.
Dumpling es una app de notas de voz para iPhone y Apple Watch, creada para reducir la fricción entre capturar una idea y organizarla, también para personas con TDAH. Transcribe las grabaciones, pone título y archiva las notas, extrae tareas y fechas de vencimiento, y arma un resumen diario. Puedes capturar una idea sin decidir antes dónde va.
No sé con qué apps consideró Apple que Dumpling era demasiado parecida, ni qué similitudes motivaron el rechazo. Eso hace que la decisión sea difícil de evaluar y todavía más difícil de abordar. A un nivel lo bastante amplio, casi cualquier app es algo que ya existe: una grabadora de voz, un gestor de tareas, una app del clima. Las diferencias suelen aparecer al usarla.
Esa incertidumbre plantea una pregunta mayor: a medida que el software se vuelve más fácil de construir, ¿llegar primero al App Store se convierte en una ventaja competitiva más valiosa? Una regla pensada para dejar fuera el spam podría crear, sin querer, un foso defensivo alrededor de los productos que ya fueron admitidos.
¿Qué significa la Guideline 4.3 del App Store de Apple?
La guideline de spam de Apple cubre dos problemas relacionados. La sección 4.3(a) trata de enviar la misma app con varios Bundle ID, como hacer una app de mapas distinta para cada ciudad. La sección 4.3(b) trata de apps que en la práctica no se distinguen de las ya existentes. En categorías consolidadas, Apple exige «una experiencia significativamente diferente o mejorada». Entre sus ejemplos están las apps de citas, las de fondos de pantalla y los temporizadores simples.
Entiendo el propósito. Tomar el producto de otra persona, cambiarle los colores y enviarlo con otro nombre genera trabajo para los revisores y desorden para los clientes. Producir cien variaciones no lo hace más útil. La propia Apple advierte que los envíos prácticamente idénticos consumen capacidad de App Review.
La escala es considerable. En su actualización del App Store de mayo de 2026, Apple dijo que revisó más de 9,1 millones de envíos durante 2025 y rechazó más de 371.000 por copiar otras apps, por spam o por engañar a los usuarios. Esa categoría combinada cuenta envíos, no apps únicas rechazadas específicamente bajo la 4.3. Tampoco nos dice con qué frecuencia se rechazaron por error apps legítimas.
La IA complica todo esto, porque ya no hace falta comprar una plantilla para reproducir un producto conocido. Se puede escribir una implementación independiente de prácticamente la misma experiencia. Ser dueño del código no hace que el resultado sea automáticamente significativamente diferente.
Yo uso IA para construir software. Puede ayudar a los desarrolladores a resolver problemas técnicos difíciles y a atender a clientes que nadie atendía. También puede abaratar el inundar un mercado con apps apenas diferenciadas. Las herramientas hacen posibles ambas cosas; la calidad del resultado sigue importando.
¿Por qué los desarrolladores cuestionan los rechazos por spam de la 4.3?
Un hallazgo de similitud puede ser difícil de responder cuando el desarrollador no puede ver con qué lo está comparando Apple. Algunos relatos públicos recientes muestran lo difícil que puede ser demostrar qué hace diferente a una app, sobre todo cuando su valor depende de un flujo de trabajo especializado.
Sebastian Röhl, desarrollador de FocusKit, informó de dos rechazos 4.3(a) antes de lanzar su temporizador de enfoque en noviembre de 2025. Varios días de correspondencia explicando sus diferencias terminaron en la aprobación. Es un resultado alentador, pero demostrar que una app merece ser admitida exigió un trabajo adicional antes de que los clientes pudieran probarla.
En septiembre de 2026, el desarrollador de YanPian informó de un rechazo 4.3(a) de una app de video para escalada. Entre sus funciones estaban combinar los datos de frecuencia cardíaca del Apple Watch con las imágenes de la escalada, seguir a un escalador dentro de un plano general y el control opcional de un estabilizador. El desarrollador reconoció que, sin imágenes de escalada para importar, la pantalla inicial podía parecerse a la de una app de cámara genérica. El hilo público registra una apelación sin una resolución publicada.
Estos relatos no establecen que Apple haya rechazado cada app porque su categoría estuviera llena. Tampoco tenemos los registros completos de revisión de Apple. Sí muestran lo difícil que puede ser entender qué se le pide demostrar a un desarrollador.
La situación de YanPian me hace pensar en Dumpling. Una app especializada puede compartir sus ingredientes básicos con una app de uso general y aun así tomar decisiones distintas sobre cómo se combinan. Reconocer esas decisiones puede requerir seguir un flujo de trabajo concreto o entender el problema que resuelve. Es un juicio más difícil que comprobar si una app se cierra sola.
¿Las reglas de spam del App Store dan ventaja a quienes llegan primero?
Creo que pueden darla. Una app que entra en una categoría relativamente abierta tiene menos productos establecidos con los que se pueda juzgar su carácter distintivo. Quien llega después quizá tenga que explicar por qué su enfoque se diferencia lo suficiente de una colección creciente de apps disponibles.
El desarrollador que llegó antes puede usar ese tiempo para atraer clientes, mejorar el producto y aprender de su uso. El que llega después quizá lo dedique a explicar por qué su producto debería poder llegar a esos clientes. Aunque la aprobación llegue al final, la incertidumbre y la demora tienen un costo.
La aprobación no es una protección permanente. Las guidelines de Apple permiten la diferenciación o mejora significativa y contemplan retirar las apps que no se mantienen, no se mejoran o no atraen clientes. Los desarrolladores ya establecidos también pueden toparse con fricción en la revisión.
En septiembre de 2026, Josh Dance informó de un rechazo 4.3(a) de una actualización de Pushup Hero. Dijo que la app estaba en la tienda desde 2018. Estaba enviando correcciones de errores y el modo oscuro cuando Apple señaló una similitud con una app asociada a una cuenta cancelada. Su relato describe una apelación, pero no cuenta cómo terminó.
Lo que me preocupa es la carga adicional de llegar cuando una categoría ya se llenó. Esa carga podría influir tanto en lo que construyen los desarrolladores como en la rapidez con que lo envían.
Crea un incentivo incómodo: apresurarse. El tiempo dedicado a pulir un producto se convierte en tiempo en el que otra persona podría establecer el punto de comparación. Un proceso diseñado para mejorar la calidad podría aumentar, sin querer, la presión por enviar antes de que el trabajo esté listo.
¿La IA está haciendo App Review más lento o más estricto?
Apple ha reconocido el crecimiento de los envíos. Su declaración de mayo de 2026 dice que las herramientas de desarrollo con IA están impulsando un aumento de envíos, y sostiene que App Review ha «escalado sin problemas» para manejarlo. Apple también dice que usa IA para analizar la similitud entre apps y señalar a los revisores humanos cambios potencialmente problemáticos. Eso no establece que la automatización haya tomado la decisión final en ningún rechazo concreto.
En un reportaje de Business Insider de marzo de 2026, Apple reconoció que algunas revisiones tardaron más. Dijo que había procesado más de 200.000 envíos por semana durante las 12 semanas anteriores, con un tiempo de revisión promedio de 1,5 días. Su guía para desarrolladores dice que el 90 % de los envíos suele revisarse en menos de 48 horas.
Una decisión de revisión y un lanzamiento exitoso son hitos distintos. Un desarrollador puede recibir un rechazo rápido y aun así pasar semanas entre correspondencia, reenvíos y apelaciones. Las estadísticas de revisión rápida pueden convivir con un proceso frustrante para los desarrolladores cuyas apps activan una clasificación discutida.
Apple también ha respondido públicamente a quejas individuales. En un hilo de mayo de 2026 sobre ByGate, el cliente dedicado de un servicio de VPN, una cuenta identificada como personal de App Review de Apple dijo que la similitud en binarios, metadatos y conceptos generales puede contribuir a que se determine que es spam. Recomendó pedir una cita con App Review, sin identificar un comparador concreto ni explicar qué características no eran lo bastante distintas.
¿Cómo pueden responder los desarrolladores a un rechazo 4.3?
Apple ofrece correspondencia con App Review, citas y apelaciones ante el App Review Board. Estos mecanismos funcionan mejor cuando el desarrollador entiende el motivo de la preocupación.
Código parecido, capturas parecidas, funcionalidad parecida y una sospecha de conexión con otro desarrollador son problemas distintos. Un desarrollador no puede responder con criterio sin saber cuál de ellos aplica. Un rechazo útil identificaría la pantalla o el flujo de trabajo en cuestión, explicaría qué diferencias alegadas se consideraron, o aclararía si la preocupación tiene que ver con la autoría, con envíos repetidos o con la experiencia del cliente.
Nada de eso exige revelar información privada de la cuenta de otro desarrollador.
Los desarrolladores también tenemos responsabilidades. Meses de trabajo no prueban que una app ofrezca algo que los clientes no puedan obtener ya. Tenemos que hacer visible su valor para quien la encuentra por primera vez. Si para eso hacen falta imágenes de escalada, datos representativos o una secuencia concreta de acciones, hay que ofrecer una demostración que funcione e instrucciones de revisión claras.
Siento empatía por los revisores que intentan distinguir un clon de una idea conocida bien ejecutada. Un mejor intercambio de evidencias ayudaría a ambas partes a resolver los malentendidos antes de que un desarrollador empiece a rediseñar una app basándose en suposiciones.
¿Se pueden distribuir apps fuera del App Store?
Para los desarrolladores de Mac, la distribución directa es una opción consolidada. Algunas apps necesitan permisos o interacción con otras aplicaciones que no caben dentro del sandbox del Mac App Store. La documentación de Apple sobre el sandbox señala que ciertos usos de las API de Accesibilidad y la interacción con otras apps son incompatibles con esas restricciones.
Yo ya distribuyo dos apps de Mac de esta manera: Burly, mi enrutador de enlaces por perfil de navegador, y Comoji, mi app de atajos de emojis. Burly dirige los enlaces a perfiles específicos del navegador y usa el acceso de Accesibilidad para controlar los menús de perfiles de Safari. Comoji lleva atajos de emojis a los campos de texto de todo el Mac, usando Monitorización de entrada para reconocer los atajos y el acceso de Accesibilidad para insertar el resultado. Esas capacidades son centrales para los productos.
La firma con Developer ID y la notarización permiten distribuir software de Mac directamente y conservar las comprobaciones de Apple contra software malicioso y problemas de firma. Para las apps que necesitan operar fuera de las restricciones de la tienda, es una forma consolidada de atender a los clientes.
Espero que la incertidumbre en torno a los rechazos por spam dé a más desarrolladores una razón para invertir en esa independencia. Un sitio web, un sistema de pago, una lista de correo y una relación directa con los clientes ofrecen más control. También dan margen para explicar un producto especializado más allá de la ficha de una tienda.
Pero un sitio web no recrea el alcance del App Store. Los clientes siguen teniendo que descubrirlo, confiar en el desarrollador y completar un proceso de compra e instalación distinto. Incluso quienes distribuyen de forma independiente pueden querer una ficha en la tienda. Perder esa oportunidad tiene un costo.
La respuesta es más restrictiva para iPhone y iPad. Apple admite actualmente tiendas alternativas y distribución autorizada desde sitios web en la Unión Europea, y también hay tiendas para iPhone en Japón y Brasil. Estas opciones tienen requisitos regionales y siguen sujetas a notarización. Un desarrollador que atiende a clientes comunes de iPhone en Estados Unidos no puede simplemente sustituir una ficha rechazada por un botón de descarga en un sitio web.
Una versión web puede funcionar para algunos productos, pero puede exigir cambios sustanciales en el producto. La distribución independiente es una respuesta mucho más completa para un desarrollador de Mac que para uno de iPhone.
¿Las revisiones más estrictas del App Store frenarán los clones desechables?
Espero que algunas de las personas que producen clones en serie concluyan que vender de forma independiente da más problemas de los que vale. Si la estrategia es enviar cien variaciones y ver cuál da dinero, un rechazo podría ser el punto en el que terminen algunos proyectos.
Generar una app es solo una parte de dirigir un negocio de software. Aunque puedas generar el sitio web igual de rápido, todavía tienes que atraer clientes, ganarte su confianza, manejar pagos y actualizaciones, y darle a la gente una razón para elegirte. Quien espera subirse a la fama de una app existente quizá tenga poco interés en ese trabajo.
¿Quién necesita otro temporizador Pomodoro con un icono distinto? Una categoría conocida puede beneficiarse de una mejor experiencia o de un enfoque pensado para un público desatendido. Reproducir el mismo producto con otra marca aporta muy poco.
Espero que la distribución independiente desaliente parte de ese comportamiento. También espero que Apple mejore al distinguirlo de un desarrollador que ha construido algo que vale la pena usar. Detener un clon desechable puede beneficiar al mercado; un rechazo opaco de un producto bien pensado puede privar a los clientes de una opción útil.
Quiero que Dumpling se juzgue por la experiencia que ofrece a las personas para las que Alan la creó. Si Apple cree que esa experiencia no es lo bastante diferente, debería explicar por qué. Quien llega primero a una categoría merece una ventaja inicial con los clientes. Quien llega después debería tener igualmente una oportunidad justa de ofrecerles algo mejor.