Desarrollo de apps en Mallorca: cómo publicar tu app en App Store y Google Play sin sorpresas

Cuando una empresa encarga el desarrollo de una app en Mallorca, casi toda la conversación gira en torno al diseño, las funciones y el presupuesto. Y casi nadie pregunta por el último tramo: la publicación en la App Store de Apple y en Google Play. Es un trámite que parece menor hasta que la app está terminada, el equipo la espera para el lunes y la tienda la devuelve por un motivo que nadie había previsto.

Este artículo repasa qué hay que tener preparado antes de publicar, quién debería ser el titular de las cuentas, cómo reducir el riesgo de rechazo y qué hacer en las semanas posteriores. Sirve igual para un negocio de Palma que para uno de Menorca, Ibiza o Formentera.

Un ejemplo para situarnos

Imaginemos, como caso hipotético, un club de pádel de Calvià que encarga una app para reservar pistas, apuntarse a partidos y recibir avisos. El desarrollo avanza bien y en la demo todo funciona. Pero llegado el momento de publicar descubren varias cosas a la vez: las cuentas de desarrollador las había abierto un colaborador externo con su correo personal, no hay política de privacidad pública, las capturas de pantalla son las del prototipo y nadie ha pensado en cómo pasar de la prueba interna a los socios reales.

Nada de esto es grave por separado. Juntos, a una semana del lanzamiento, se convierten en un retraso evitable.

1. Las cuentas de desarrollador deben ser de la empresa

Para publicar en las dos tiendas hace falta una cuenta de desarrollador en cada una (Apple y Google), y ambas tienen una cuota que conviene consultar en sus webs oficiales. Lo importante no es el coste, sino a nombre de quién se abren.

• A nombre de la empresa, con un correo corporativo que no dependa de una sola persona.
• Con al menos dos personas de tu equipo con acceso de administración.
• Con los datos fiscales y de contacto reales: las tiendas los usan para verificar al titular, y ese proceso puede tardar más de lo que se espera.
• Con el equipo de desarrollo añadido como colaborador, no como propietario.

Si la cuenta es del proveedor y un día cambias de proveedor, la app y sus reseñas se quedan atadas a otra empresa. Es el punto que más conviene dejar escrito antes de empezar, igual que el código y los datos.

2. Lo que las tiendas piden aparte de la app

Además del archivo de la app, cada tienda pide una ficha con contenidos que alguien tiene que preparar. Cuanto antes se redacten, mejor, porque suelen depender de decisiones de negocio y no solo técnicas.

• Nombre y descripción de la app, con la palabra clave principal de forma natural y sin prometer lo que la app no hace.
• Capturas de pantalla de la versión final, en los tamaños que pida cada tienda, y con textos en los idiomas en los que vayas a ofrecerla. En Baleares lo habitual es español, catalán, inglés y, según el público, alemán.
• Icono y, si procede, imágenes promocionales.
• Política de privacidad en una dirección web pública y accesible, que describa qué datos recoge la app y para qué.
• Declaración de datos: las dos tiendas piden indicar qué información personal se recoge. Debe coincidir con lo que la app hace de verdad.
• Contacto de soporte y una página o correo donde el usuario pueda reclamar.
• Cuenta de prueba: si la app exige iniciar sesión, el revisor de la tienda necesita un usuario y contraseña de demostración para entrar.

Un detalle práctico: si la app usa la cámara, la ubicación o las notificaciones, la propia app debe explicar al usuario para qué las necesita en el momento de pedir permiso. Es una de las causas más habituales de que una revisión se complique.

3. Por qué una tienda puede rechazar una app

No hace falta memorizar las normas, pero sí saber qué suele atascar una revisión. Las normas cambian, así que conviene revisar las guías oficiales de Apple y de Google cuando vayas a publicar. Los motivos que más se repiten son de sentido común:

• La app falla o se cierra al abrirla con una configuración distinta a la de quien la probó.
• La descripción o las capturas no se corresponden con lo que hace la app.
• Falta la política de privacidad o los permisos no están justificados.
• El revisor no puede entrar porque no tiene una cuenta de prueba.
• La app es poco más que una web metida en un contenedor, sin nada que aporte como app. Si tu caso es sobre todo informativo, quizá una web adaptada te convenga más; lo explicamos en nuestra comparativa de nativa, híbrida o web app.

Si te rechazan, no es el fin del mundo: la tienda indica el motivo, se corrige y se vuelve a enviar. El riesgo real es el calendario. Por eso conviene enviar la primera versión con margen, no el día antes de una campaña, una inauguración o el inicio de temporada.

4. De la prueba interna a los usuarios reales

Antes de publicar para todo el mundo, las dos plataformas permiten repartir versiones de prueba a un grupo reducido de personas (en el caso de Apple, mediante TestFlight; en el de Google, con las pruebas internas y cerradas de Google Play). Úsalas.

Un reparto razonable para una primera salida:

1. Equipo propio: tu gente prueba el flujo completo con datos reales, sin clientes delante.
2. Grupo pequeño de clientes de confianza: diez o veinte personas que te darán opinión sincera y avisarán de lo que falla.
3. Publicación abierta: solo cuando los fallos importantes estén corregidos y el equipo sepa responder a las dudas más comunes.

En el ejemplo del club de pádel, el segundo grupo podrían ser los socios más activos, que además ayudan a difundir la app en el club cuando funciona bien.

5. Después de publicar: lo que ocurre en las primeras semanas

Publicar no es el final del proyecto, es el comienzo del mantenimiento. Conviene acordar de antemano:

• Quién vigila los fallos: un sistema que avise cuando la app se cierra de forma inesperada, para enterarte antes que tus clientes.
• Quién contesta las reseñas y en qué plazo. Una respuesta educada a una queja pesa mucho.
• Cómo se publican las actualizaciones: cada versión nueva pasa de nuevo por revisión, así que no se pueden prometer cambios «para esta tarde».
• Qué pasa cuando salga una versión nueva de iOS o de Android: la app puede necesitar ajustes, y ese trabajo debería estar previsto.
• Cómo se medirá el éxito: descargas, usuarios activos, reservas hechas desde la app. Con tres o cuatro números claros basta.

Cuándo no tiene sentido publicar en las tiendas

Una app en las tiendas no siempre es la mejor decisión. Quizá te convenga esperar si:

• Todavía no tienes claro qué hará el usuario dentro de la app que no pueda hacer en tu web.
• No hay nadie que atienda soporte y reseñas después del lanzamiento.
• Tu público es muy reducido y puede acceder a un enlace privado o a una web instalable.

En esos casos, una primera versión como web app puede darte datos reales antes de dar el salto. Si quieres ver cómo planteamos este tipo de proyectos, tienes más información en nuestro servicio de desarrollo de apps móviles en Mallorca. Y si lo que necesitas es una herramienta interna o conectar la app con tus sistemas, mira también el software a medida para empresas.

Resumen en una lista

• Cuentas de desarrollador a nombre de tu empresa y con dos administradores.
• Ficha de la tienda preparada con capturas finales, textos en los idiomas necesarios y política de privacidad pública.
• Cuenta de prueba para el revisor y permisos bien explicados.
• Primera versión enviada con margen de calendario.
• Pruebas internas y con un grupo pequeño antes de abrir al público.
• Responsables claros para fallos, reseñas y actualizaciones.

Hablemos de tu app

Si estás pensando en lanzar una app en Mallorca, Menorca, Ibiza o Formentera y quieres llegar a las tiendas sin sorpresas, cuéntanos qué quieres que haga y quién la va a usar. Escríbenos a derek@dereksolutions.com o llama al +34 680 283 973 y vemos por dónde empezar.