Sí, la URL de soporte es obligatoria en App Store Connect. Es un campo requerido en los metadatos de tu versión, así que no puedes enviar la app sin ella. Debe llevar a una página activa y pública donde los usuarios puedan obtener ayuda o ponerse en contacto contigo. Una URL vacía, rota o con un marcador de posición provoca un rechazo de metadatos según la guía 1.5. La URL de política de privacidad también es obligatoria; la de marketing, en cambio, es opcional.
Respuesta rápida
La URL de soporte es un campo obligatorio: sin ella, App Store Connect no te deja enviar la versión. Según las Directrices de revisión de Apple, la guía 1.5 exige una forma de contactar contigo para obtener soporte, y la URL de soporte es ese requisito en los metadatos. Debe apuntar a una página real con información de ayuda o contacto actualizada. La URL de política de privacidad también es obligatoria, como recoge la ayuda de App Store Connect; la de marketing es opcional. Si tu URL de soporte está rota o vacía, corrígela y reenvía; suele bastar con actualizar los metadatos, sin subir un binario nuevo.
¿Es obligatoria la URL de soporte?
Sí, sin excepciones prácticas. En la pestaña App Store de tu versión, la URL de soporte es un campo que debes rellenar para poder enviar la app a revisión. No es un extra recomendado: es un requisito de envío, y App Store Connect no acepta la versión mientras el campo esté vacío.
Además de exigirla, Apple la comprueba. La guía 1.5, sobre información del desarrollador, pide que los usuarios tengan una forma de contactarte para pedir ayuda, y esa URL es la vía. Por eso no basta con poner cualquier dirección: tiene que funcionar y ofrecer soporte real, o el envío se rechaza por metadatos.
Qué debe contener la URL de soporte
La URL de soporte debe llevar a una página pública y activa donde un usuario pueda resolver dudas o contactarte. Lo mínimo es una forma de contacto, como un correo, un formulario o un chat, y lo ideal es añadir preguntas frecuentes o una guía básica. El objetivo es que alguien con un problema encuentre ayuda sin salir de esa página.
Lo que no vale es una página vacía, una de próximamente, tu página de inicio sin información de soporte, o un enlace roto. Apple abre la URL durante la revisión, así que si no ofrece soporte visible, cuenta como si no la hubieras puesto. Piénsala como el sitio al que enviarías a un usuario molesto para que se sienta atendido.
URL de soporte vs marketing vs privacidad
Es fácil confundir los tres campos de URL de tu ficha, así que conviene separarlos. La URL de soporte es obligatoria y sirve para ayuda; la de política de privacidad es obligatoria y enlaza tu política; la de marketing es opcional y promociona la app. La tabla lo resume.
| Campo | ¿Obligatorio? | Qué es |
|---|---|---|
| URL de soporte | Sí | Página donde obtener ayuda o contacto |
| URL de política de privacidad | Sí | Política de privacidad pública |
| URL de marketing | No | Página promocional opcional |
| URL de acuerdo de licencia (EULA) | No | Solo si usas uno personalizado |
La distinción práctica es cuáles bloquean el envío. La URL de soporte y la de política de privacidad son obligatorias, así que un fallo en cualquiera de las dos frena la publicación. La de marketing puedes dejarla en blanco sin problema. No pongas tu política de privacidad en el campo de soporte ni al revés; cada una cumple una función distinta.
Qué pasa si falta o está rota
Si el campo está vacío, App Store Connect no te deja enviar, así que el problema aparece antes de la revisión. Si la URL está puesta pero rota, apunta a una página sin soporte o muestra un marcador de posición, el resultado es un rechazo de metadatos: la revisión se detiene y recibes un mensaje en el Centro de resoluciones citando la guía 1.5.
La buena noticia es que un rechazo de metadatos suele ser rápido de arreglar. Como afecta a la información de la ficha y no al binario, normalmente puedes corregir la URL y reenviar sin compilar ni subir una app nueva. Es un tropiezo molesto pero menor si reaccionas rápido.
Cómo corregir un rechazo por la URL de soporte
Trátalo como un arreglo de metadatos, en orden. La tabla siguiente da una ruta clara.
| Paso | Acción | Por qué |
|---|---|---|
| 1 | Verifica que la URL esté activa y sea pública | Apple la comprueba |
| 2 | Asegúrate de que ofrece contacto o ayuda | Es el propósito del campo |
| 3 | Evita marcadores de posición o próximamente | Provocan rechazo |
| 4 | Corrige la URL en la pestaña App Store | Donde vive el metadato |
| 5 | Responde en el Centro de resoluciones | Si fue rechazo de metadatos |
| 6 | Reenvía los metadatos | Sin necesidad de nuevo binario |
El punto clave es que casi nunca necesitas un binario nuevo. Corriges la URL en los metadatos, confirmas que la página funciona y ofrece soporte, respondes en el Centro de resoluciones explicando el cambio, y reenvías. La revisión retoma desde los metadatos corregidos.
Errores comunes con la URL de soporte
Los rechazos por la URL de soporte se repiten por unos pocos motivos. El más común es una página que no ofrece soporte de verdad: la página de inicio de la app, una landing de marketing o una red social sin forma de contacto. Otro es un enlace roto o que exige iniciar sesión, de modo que el revisor no puede verlo. Y otro es una página en construcción.
Evitar estos errores es sencillo si te pones en el lugar del revisor. Abre tu URL de soporte en una ventana privada, sin sesión iniciada, y comprueba que ves ayuda o contacto de inmediato. Si tú, sin contexto, no sabrías cómo pedir soporte desde esa página, Apple tampoco, y ese es el fallo que marcan.
¿Puedo cambiarla después de publicar?
Sí. La URL de soporte se puede actualizar cuando lo necesites. Algunos cambios de metadatos de una app ya publicada se pueden guardar sin enviar una versión nueva, y otros se aplican con la siguiente actualización, según el campo. En cualquier caso, mantener la URL viva y útil es tu responsabilidad continua, no solo del primer envío.
Conviene revisarla de vez en cuando. Si cambias de dominio, de sistema de tickets o de correo de soporte, actualiza la URL para que no acabe apuntando a una página muerta. Una URL de soporte que funcionaba al publicar pero que hoy da error es un problema esperando a la siguiente revisión o a un usuario frustrado.
Buenas prácticas para una página de soporte
Una buena página de soporte no necesita ser compleja. Incluye una forma clara de contacto, unas preguntas frecuentes con los problemas más habituales, y quizás enlaces a tu política de privacidad y a novedades. Mantenla en una URL estable que controles, no en una plataforma que puedas perder, para que el enlace no se rompa.
Piénsala también como parte de la experiencia, no solo como un requisito. Los usuarios que llegan a soporte suelen estar frustrados, así que una página que responda rápido a sus dudas reduce reseñas negativas y tickets. Cumplir la guía 1.5 y cuidar de verdad a tus usuarios acaban siendo lo mismo.
Antes de enviar, revisa también la seguridad
Los metadatos son solo una parte de lo que Apple revisa. Además de la URL de soporte y la política de privacidad, la revisión evalúa lo que hace tu app, y puede rechazarla por motivos de seguridad y privacidad que no tienen que ver con la ficha. Una app con una clave incrustada o tráfico en claro puede pasar los metadatos y fallar por otro lado.
Un escáner como PTKD.com analiza tu .ipa y devuelve resultados ordenados por gravedad y alineados con OWASP MASVS, para que corrijas secretos embebidos y configuraciones inseguras antes de enviar. Con un límite claro: PTKD no tiene nada que ver con tu URL de soporte ni con los metadatos, y no evita un rechazo de la guía 1.5. Cubre la parte de seguridad que una revisión de metadatos no mira.
Qué recordar
- La URL de soporte es obligatoria; sin ella, App Store Connect no te deja enviar.
- Debe llevar a una página pública y activa con contacto o ayuda real; una página vacía o rota provoca un rechazo por la guía 1.5.
- La política de privacidad también es obligatoria; la URL de marketing es opcional.
- Un rechazo por la URL de soporte suele arreglarse actualizando los metadatos, sin un binario nuevo.
- Antes de enviar, revisa también la seguridad de tu build con PTKD.com, porque los metadatos no son lo único que Apple mira.
