Directriz 4.2 de Apple: ¿Apple rechazará una aplicación de sitio web? Cómo pasar la revisión

Apple puede rechazar una aplicación basada en un sitio web y la "funcionalidad mínima" es la razón más común. La directriz 4.2 es la norma que la sustenta. Una aplicación de sitio web no se rechaza automáticamente, pero una aplicación que no agrega nada más que un sitio web en un marco corre un riesgo real.

Esta guía explica lo que dice la directriz, qué tienden a buscar los revisores y cómo preparar un envío. Nadie fuera de Apple puede prometer su aprobación, y este artículo no lo hace. Lo que puedes hacer es eliminar los motivos evitables de rechazo.

Lo que realmente dice la Directriz 4.2

Las Pautas de revisión de aplicaciones establecen en 4.2, Funcionalidad mínima:

Su aplicación debe incluir funciones, contenido y una interfaz de usuario que la lleven más allá de un sitio web reempaquetado. Si su aplicación no es particularmente útil, única o "parecida a una aplicación", no pertenece a la App Store.

Las palabras que importan son "sitio web reempaquetado". La regla no prohíbe las aplicaciones creadas en torno a contenido web. Prohíbe aplicaciones que no ofrecen nada que un sitio web no ofrezca ya.

En las reseñas de aplicaciones y sitios web también aparecen pautas relacionadas:

• 4.2.2: Aparte de los catálogos, las aplicaciones no deberían ser principalmente materiales de marketing, anuncios, recortes web, agregadores de contenido o una colección de enlaces.
• 4.2.3: La aplicación debería funcionar por sí sola sin requerir la instalación de otra aplicación, y debería revelar y solicitar cualquier descarga grande necesaria en el primer inicio.
• 2.1 (Integridad de la aplicación): Los envíos deben ser versiones finales con URL que funcionen, sin contenido de marcador de posición y detalles de la cuenta de demostración si la aplicación tiene un inicio de sesión.
• 4.2.6: Las aplicaciones creadas a partir de una plantilla comercializada o un servicio de generación de aplicaciones se rechazan a menos que sean enviadas directamente por el proveedor del contenido de la aplicación.

Lea siempre usted mismo el texto actual, ya que Apple actualiza las pautas. La fuente oficial es la Directrices de revisión de la App Store.

¿Apple rechazará una aplicación de sitio web?

Depende de lo que haga la aplicación enviada. En la práctica, los revisores reaccionan ante algunos patrones:

• La aplicación abre una única URL y tiene un aspecto idéntico al sitio web móvil, incluida la navegación estilo web.
• Muestra solo un muro de inicio de sesión sin contenido navegable, por lo que el revisor no puede ver lo que hace la aplicación.
• Se rompe o muestra errores sin conexión.
• Sus enlaces saltan constantemente al navegador.
• Parece un folleto de marketing para una empresa sin función propia.

Una aplicación que envuelve un servicio real, como una tienda, un sistema de reservas, un área de miembros o una biblioteca de contenidos, y lo presenta con una navegación similar a la de una aplicación, se encuentra en una posición diferente. Aún así puedes ser rechazado, ya que la revisión es un juicio, pero tienes algo que señalar.

Por qué una aplicación generada por un servicio necesita su propia cuenta

La directriz 4.2.6 dice que las aplicaciones creadas con un servicio de generación de aplicaciones se rechazan a menos que sean enviadas directamente por el proveedor del contenido de la aplicación. Para el propietario de un sitio web, la lectura práctica es la siguiente: publique con su propia cuenta de desarrollador de Apple, en su propio nombre o en el de su empresa, y asegúrese de que la aplicación represente su propio contenido.

Así es también como funciona SiteTo.App. Las compilaciones se firman con la cuenta de desarrollador de Apple que conecta y la compilación se entrega a TestFlight en su cuenta de App Store Connect. Eres dueño del listado y lo envías. Ver el Guía de cuentas de desarrollador de Apple para la configuración. No entregue su contenido a un proveedor que envía el mismo shell para muchos clientes bajo su propia cuenta.

¿Qué hace que una aplicación de sitio web parezca una aplicación?

El objetivo no es agregar funciones porque sí. Es mejorar el uso del móvil. Las adiciones sólidas y honestas incluyen:

• Navegación nativa. Una barra de pestañas o un menú que coincida con la forma en que las personas se mueven a través de su sitio en un teléfono, en lugar de un encabezado de escritorio comprimido en una pantalla pequeña.
• Notificaciones push. Mensajes a los que los usuarios optan, como actualizaciones de pedidos, recordatorios de reservas o contenido nuevo. En SiteTo.App, estos se configuran a través de Firebase; ver el Guía de base de fuego.
• Enlaces profundos. Enlaces de notificaciones o correo electrónico que abren la pantalla derecha de la aplicación.
• Una experiencia de lanzamiento diseñada. Un ícono, una pantalla de presentación y un estado claro de carga y error.
• Traspasos nativos. Compartir, cargar archivos, acceder a la cámara o descargar que funcionen correctamente en el dispositivo.

No agregue un truco como un interruptor de linterna. No aborda la directriz 4.2 y los revisores la ven claramente.

Una lista de verificación previa al envío

Resuelva esto antes de cargar:

1. Pruebe todo el viaje en un iPhone real. Instale a través de TestFlight, no solo un simulador. Abra la aplicación en frío, inicie sesión, navegue varios niveles y use el gesto hacia atrás.
2. Prueba sin conexión. Activa el modo avión y abre la aplicación. Debería ver un mensaje claro, no una página en blanco.
3. Verifique cada enlace externo. Decide a propósito qué enlaces permanecen dentro de la aplicación y cuáles abren el navegador.
4. Solucionar problemas de diseño del sitio web. Los problemas de respuesta, los pequeños objetivos de toque y las ventanas emergentes solo en el escritorio son obvios en una aplicación.
5. Eliminar el contenido del marcador de posición. La directriz 2.1 espera un producto terminado con soporte funcional y URL de privacidad.
6. Proporcione credenciales de demostración. Si es necesario iniciar sesión, incluya una cuenta que siga funcionando durante la revisión.
7. Haga que las respuestas de privacidad sean precisas. Deben describir toda la experiencia, incluidos los análisis web y las herramientas de pago cargadas en la aplicación.
8. Escribe capturas de pantalla honestas y una descripción. Muestre la aplicación real y no reclame las funciones de las que carece.
9. Utilice notas de revisión. Explique qué hace la aplicación, dónde están las funciones nativas y los requisitos de cuenta o región.

Puede comparar su sitio con muchos de estos con el lista de verificación de preparacióny nuestro guía editorial Cubre los escalones de la tienda circundante.

Cómo escribir notas de revisión que ayuden

Los revisores ven muchas presentaciones. Una nota breve y específica les ayuda a encontrar el valor rápidamente. Cubrir:

• Para qué sirve la aplicación, en una o dos frases.
• Cómo iniciar sesión con credenciales de demostración funcionales.
• Dónde encontrar las funciones nativas, por ejemplo "Las notificaciones se pueden habilitar desde la pestaña de la cuenta".
• Cualquier cosa inusual, como una función que necesite una región o hardware en particular.

Mantenlo objetivo. Evite discusiones sobre las pautas en la primera presentación. Guárdelo para una respuesta si lo rechazan.

Si Apple rechaza la aplicación

Un rechazo es una conversación, no un veredicto final. Apple explica la directriz que aplicó en el Centro de resoluciones.

1. Lea atentamente el mensaje. Anote el número de la guía y cualquier pantalla o comportamiento específico mencionado.
2. Solucione el problema real. Si el motivo es una funcionalidad mínima, mejore lo que hace la aplicación en lugar de reformular la descripción.
3. Responde con precisión. Describe qué cambió y dónde puede verlo el revisor.
4. Vuelva a enviar una nueva compilación si es necesario. Un cambio en el binario requiere una nueva carga.
5. Apelar sólo con un caso. Si cree que el rechazo es un error, utilice el proceso de apelación de revisión de aplicaciones y cite los hechos.

Debido a que una aplicación basada en un sitio web carga su sitio, muchas correcciones se realizan en el sitio web y aparecen en la aplicación sin una nueva versión de la tienda. Los cambios de configuración nativa aún necesitan una nueva compilación.

Preguntas comunes

¿La aplicación de un sitio web tiene que funcionar sin conexión?

No como regla general, pero debería fracasar con gracia. Una pantalla en blanco sin conexión parece inacabada y eso afecta la forma en que los revisores ven la aplicación.

¿Se trata una PWA de manera diferente a cualquier otro sitio web?

Una PWA en una aplicación de iOS sigue siendo contenido web dentro de un shell nativo, por lo que se aplica la misma directriz. Ver cómo publicar una PWA en App Store y Google Play.

¿Puedo enviar la misma aplicación para varias marcas?

La pauta 4.2.6 restringe las aplicaciones creadas a partir de una plantilla o servicio de generación y enviadas en nombre de los clientes. Cada empresa debe publicar bajo su propia cuenta.

¿Tengo que pagar por un convertidor para obtener la aprobación?

Ninguna herramienta decide el resultado. Apple evalúa la aplicación enviada. Pagar por una construcción no cambia eso, por lo que el precio es independiente de la aprobación. Ver precios.

Próximos pasos

Comience probando su sitio como una aplicación. Obtenga una vista previa de su sitio web en SiteTo.App, pruébalo en tu teléfono y observa lo que parece un sitio web en lugar de una aplicación. Arregle esos puntos, luego siga las crear y publicar guía.