Guideline 4.2 Minimum Functionality: app rechazada

La guideline 4.2, "Minimum Functionality", rechaza una app que no ofrece nada más que un sitio web, o que ofrece demasiado poco para que alguien la conserve. La solución no es amontonar funciones nativas: es poner una en el centro del uso y luego decirle al reviewer dónde encontrarla. La corrección pasa casi siempre por un nuevo build.

Publico mis propias apps iOS: Solys, TradaZen y Nolera están en el App Store. Esta guía se basa en el texto oficial de Apple, leído el 15 de octubre de 2026, y en rechazos 4.2 publicados por desarrolladores en los foros de Apple. Las apps rechazadas que cito más abajo son ejemplos. Para ver el panorama de todos los motivos, mejor lee por qué Apple rechaza una app.

¿Qué dice la guideline 4.2?

La 4.2 está en la sección 4, "Design", de las App Review Guidelines. Su primera frase plantea el criterio: "Your app should include features, content, and UI that elevate it beyond a repackaged website." Dicho de otro modo, tu app debe ofrecer funciones, contenido y una interfaz que la pongan por encima de un sitio web metido en una caja.

El texto agrega dos ideas. Una app que no es realmente útil, única o "app-like" no tiene lugar en el App Store. Y una app que no ofrece ni entretenimiento duradero ni utilidad suficiente puede ser rechazada. Así que la 4.2 juzga dos cosas: la diferencia con la web y la cantidad de valor.

Las subreglas que el mensaje puede citar

Subregla	Lo que pide Apple	El rechazo típico
4.2	Ir más allá de un sitio web	Sitio mostrado en una WebView
4.2.1	Una verdadera experiencia de realidad aumentada	Un modelo 3D colocado en la vista AR
4.2.2	No solo marketing o enlaces	App escaparate, agregador, enlaces
4.2.3	Una app autónoma, descargas claras	App que exige otra app
4.2.6	Nada de apps hechas con una plantilla comercial	Plantilla enviada por un proveedor

Tres aclaraciones. La 4.2.2 hace una excepción para los catálogos: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Así que un catálogo de productos puede pasar. Un folleto publicitario, no.

La 4.2.3 tiene dos incisos. El (i) pide que la app funcione sola, sin instalar otra app. El (ii) pide, si la app debe descargar recursos en el primer inicio, indicar el tamaño de la descarga y pedir permiso antes.

La 4.2.6, sobre plantillas comerciales y servicios de generación de apps, se detalla en la guía de la guideline 4.3, porque va de la mano con la regla antispam.

Los dos mensajes 4.2 más frecuentes

El mensaje de Apple empieza con el título "Guideline 4.2 - Design - Minimum Functionality". Lo que sigue dice cuál de los dos problemas vio el reviewer. Aquí tienes dos redacciones publicadas por desarrolladores en los foros de Apple. Tienen algunos años: el texto exacto pudo cambiar, las dos familias no.

La app parece un sitio web. "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." Este mensaje, publicado en los foros de Apple, contiene una frase decisiva: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

La app es demasiado pobre. "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." Este segundo mensaje pide replantear el concepto y reconoce que ninguna regla numérica define qué es útil o entretenido.

Agregar notificaciones, ubicación y un botón para compartir a un sitio encapsulado no basta: Apple lo escribió en sus propios rechazos.

Cuatro casos típicos de rechazo 4.2

Los cuatro casos siguientes son ejemplos construidos para ilustrar la regla, no apps reales.

El sitio web encapsulado

Ejemplo: un gimnasio muestra su sitio móvil en una WebView, con una barra de pestañas nativa encima. El horario, las reservas y la cuenta son páginas web. El reviewer encuentra lo mismo que le mostraría Safari. Apple lo dice en su página de App Review: un sitio servido dentro de una app iOS, un contenido web no adaptado a iOS o interacciones web limitadas no hacen una app de calidad.

Lo que yo haría: reconstruir en nativo las pantallas de la acción principal, aquí el horario y las reservas. Luego agregar lo que el sitio no puede hacer: un recordatorio antes de la clase, el horario disponible sin conexión, la próxima clase en un widget.

La app demasiado simple

Ejemplo: una app que muestra una cita al día, y nada más. La recorres entera en diez segundos. La 4.2 habla de "lasting entertainment value or adequate utility": un valor que dura, o una utilidad suficiente. Para corregirlo, agrega profundidad a la acción principal, no pantallas alrededor. Aquí: un historial, favoritos, un recordatorio a la hora elegida, un widget en la pantalla de inicio.

La app generada con IA, sin nada nativo

Ejemplo: un campo de texto, un botón, una respuesta de IA mostrada en texto plano. Apple no juzga la herramienta, sino lo que llega a la pantalla del reviewer. Si la experiencia cabe en una página web, es muy probable que caiga la 4.2.

Detallo lo que la IA hace bien y lo que falla en crear una app con IA. El formato que produce cada generador, aplicación web o proyecto móvil, se compara en Lovable, Rork o FlutterFlow.

El cascarón a la espera de contenido

Ejemplo: un marketplace sin anuncios, un directorio vacío, un feed que muestra "Próximamente". El reviewer abre una app que no tiene nada que mostrar. Este caso también toca la 2.1, que rechaza el contenido provisional: mira la guía de la guideline 2.1. Envía la app cuando tenga contenido real, o proporciona una cuenta demo ya llena.

La prueba que hago: "¿Y en Safari?"

Antes de enviar, me pregunto si un sitio web podría ofrecer la misma función principal. Si la respuesta es sí, la app está expuesta a la 4.2. Esta es mi tabla para juzgar una función nativa. Una función cuenta cuando sirve a la acción principal, no cuando decora.

Función	Cuenta cuando...	No basta cuando...
Notificaciones	Traen una información esperada	Solo difunden tus artículos
Sin conexión	El contenido principal sigue siendo usable	Solo aparece una pantalla de error
Widget	Muestra un dato propio de la persona	Muestra tu logo
Compartir	Se envía contenido hacia tu app	Solo comparte un enlace
Cámara, sensores	Forman parte de la acción principal	Abren tu sitio
Datos locales	La app calcula, ordena y recuerda	Todo vive en una página web

Las recomendaciones de Apple van en el mismo sentido. Un widget muestra un contenido actual, legible de un vistazo. Una notificación aporta una información útil, en pocas palabras, y no sirve para empujar hacia una tarea dentro de la app.

Lo que mis apps hacen y un sitio no

Diseño cada app en torno a una función principal que no existe en un navegador, o a un valor que hace volver.

• Solys es un despertador. La alarma pasa por AlarmKit, el servicio de alarmas de iOS 26: suena aunque esté activado el modo silencio, como el despertador de Apple. Para apagarla, hay que ganar un minijuego, y las apps elegidas quedan en pausa después de despertar. Ninguna página web hace sonar un iPhone en silencio.
• TradaZen es un simulador de trading: un gráfico real en una fecha real, una decisión, velas que se revelan, duelos clasificatorios y un rango que sube. Aquí no es una función nativa la que sostiene la app. Es el valor de entretenimiento duradero del que habla la 4.2.
• Nolera es un clóset virtual: fotografías tu ropa, la app la recorta y la ordena, y luego te propone un outfit cada mañana. La cámara forma parte de la acción principal. No es un extra.

La 4.2 no exige una lista de funciones nativas: exige una razón para instalar la app en lugar de abrir un sitio.

Corregir un rechazo 4.2, paso a paso

1. Identifica la familia. Navegación web: es el sitio encapsulado. Contenido o funciones mínimas: es la app demasiado pobre. La 4.2.3: una dependencia de otra app o una descarga no anunciada.
2. Cambia el producto, no la redacción. Una respuesta que argumenta sin cambiar nada no tiene por qué convencer. Reconstruye en nativo las pantallas de la acción principal, o agrega la profundidad que falta.
3. Prevé un nuevo build. La causa está en la app: una actualización remota no basta. Cada envío vuelve a pasar por la fila, mira el tiempo de revisión del App Store.
4. Escribe notas de revisión que guíen. Apple pide, en su página sobre la información para una revisión completa, describir el concepto, las funciones y el público. Para una actualización: qué cambió y dónde encontrarlo.
5. Apela solo si el reviewer pasó algo por alto. Si tu función nativa ya existía pero no la vieron, responde en App Store Connect con un video corto. La apelación ante el App Review Board se justifica cuando tu app fue mal entendida, no cuando es pobre.

La plantilla de notas que yo usaría, en inglés, para adaptar:

Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]

Escribe solo lo que existe en el build enviado. Una función anunciada que no se encuentra te costaría un nuevo rechazo, esta vez por la 2.1.

El checklist 4.2 antes de enviar

• Sabes decir en una frase qué hace tu app que un sitio no hace.
• Las pantallas de la acción principal son nativas, no páginas web.
• Cada función nativa sirve a la acción principal, y el reviewer se la topa en menos de dos minutos.
• La app tiene contenido real desde el primer inicio, o una cuenta demo llena.
• La app funciona sola, sin otra app que instalar.
• Una descarga grande en el primer inicio indica su tamaño y pide permiso.
• Las notas de revisión describen el concepto, el público y la ubicación de cada función.
• Si tu idea roza el límite, la probaste antes de programar, con un MVP de app iOS bien delimitado.

Pasar la 4.2 desde tu próximo envío

Si tu app acaba de ser rechazada por la 4.2, el Apple Review Kit te ayuda a encontrar la regla citada y lo que pide, con las plantillas de notas para el revisor. Si todavía estás construyendo, el recorrido del iOS Kit parte de la función principal antes de la primera línea de código. Para una mirada humana, reserva una hora conmigo. El proceso completo está en la página app rechazada por Apple.

Si preparas tu primer lanzamiento, haz tu diagnóstico gratuito: pone los pasos en orden y te envía mi checklist antirrechazo de Apple. La página de inicio muestra cómo crear una app móvil pensada para la revisión desde el principio.

Nadie puede garantizar que Apple aceptará tu app. Yo puedo ayudarte a darle una razón para existir en el App Store.

Preguntas frecuentes

¿Qué significa "Guideline 4.2 - Design - Minimum Functionality"?

Es el título del rechazo por funcionalidad mínima. Apple considera que tu app se parece demasiado a un sitio web, o que ofrece muy poco contenido o funciones. El mismo título puede apuntar a una subregla: "Guideline 4.2.2" para una app escaparate o una lista de enlaces, 4.2.3 para una app que depende de otra app.

¿Una app en WebView siempre es rechazada?

No. La regla apunta al sitio web metido en una app, no a la tecnología. El reviewer juzga la experiencia principal: si sus pantallas son páginas web que hacen lo mismo que Safari, el riesgo es alto. Una página de ayuda abierta en el navegador no es el problema.

¿Agregar notificaciones push basta para pasar la 4.2?

No. En un mensaje de rechazo publicado en sus foros, Apple escribe que las notificaciones, la ubicación y la función de compartir no bastan para que la experiencia sea lo bastante rica. Una notificación cuenta cuando sirve a la función principal, como una alarma o un recordatorio elegido por la persona.

¿Qué diferencia hay entre la guideline 4.2 y la 4.3?

La 4.2 juzga tu app sola: ¿aporta lo suficiente frente a un sitio web? La 4.3 la compara con las demás: ¿es una copia, una variante o una app más en una categoría saturada? Una misma app puede recibir las dos, pero no se corrigen de la misma manera.

¿Hace falta un nuevo build después de un rechazo 4.2?

Casi siempre, porque la causa está en la propia app. Única excepción: el reviewer no encontró una función que ya existía. En ese caso, responde en App Store Connect con notas precisas y un video corto, sin cambiar el build.