Para publicar una aplicación App Store Google Play, hay que crear las cuentas de desarrollador, preparar una build firmada, completar las fichas stores, declarar los datos recopilados, probar, enviar para validación y después gestionar las actualizaciones. El punto que lo cambia todo para su presupuesto y sus plazos: la publicación no es una simple formalidad de final de proyecto, sino una fase de conformidad que debe anticiparse desde la fase de definición.
¿Cómo crear las cuentas de desarrollador de Apple y Google?
La primera etapa consiste en abrir las cuentas oficiales a nombre de su empresa, no a nombre de un freelance o de una agencia. Es un detalle administrativo que se vuelve rápidamente estratégico: la cuenta posee la aplicación, las reseñas, las estadísticas, los certificados y el historial de actualizaciones.
En 2026, el Apple Developer Program cuesta 99 USD al año. Es obligatorio para distribuir una aplicación en la App Store. Para una inscripción como organización, Apple solicita una entidad legal, un nombre de vendedor, un sitio web público y funcional, un correo electrónico vinculado al dominio de la empresa, la autoridad legal del solicitante y, salvo excepciones, un número D-U-N-S, identificador internacional asignado a las sociedades.
Por parte de Google, el acceso a la Google Play Console cuesta 25 USD en un pago único. Google propone cuentas Personal y Organization, con verificaciones de identidad o de organización. Para una pyme, la cuenta Organization suele ser la elección correcta: aclara la propiedad, facilita la gestión de usuarios y evita depender de la cuenta personal de un colaborador.
En los proyectos que llevamos a cabo, vemos a menudo un bloqueo muy banal: la cuenta Apple Organisation no está lista, porque falta el D-U-N-S o el correo electrónico del dominio. Por sí solo, este asunto puede retrasar una publicación varios días, a veces más si la documentación debe regularizarse.
¿Qué archivos, certificados e identificadores hay que preparar?
Una aplicación no se sube como un PDF. Debe estar identificada, firmada y asociada a los servicios técnicos correctos. El signing, o firma, demuestra que el archivo procede realmente del desarrollador autorizado y que no ha sido modificado.
En iOS, el equipo técnico prepara en particular un Bundle ID, es decir, el identificador único de la aplicación, por ejemplo con un formato similar a com.entreprise.app. También configura las capacidades utilizadas: notificaciones push, inicio de sesión con Apple, compras integradas, geolocalización, segundo plano, según el perímetro real del proyecto. La build firmada se archiva después con Xcode y luego se envía a App Store Connect.
En Android, las nuevas aplicaciones publicadas en Google Play utilizan el Android App Bundle, un archivo .aab. Este formato permite a Google Play generar versiones adaptadas a los dispositivos de los usuarios. Después, Play App Signing gestiona la firma de distribución. Es práctico, pero exige una buena conservación de las claves y de los accesos.
La trampa menos visible: rehacer una aplicación con un identificador incorrecto o una mala gestión de la firma puede complicar, o incluso impedir, ciertas actualizaciones. En esta fase, vale más perder medio día verificando la arquitectura de publicación que descubrir el problema después de adquirir a sus primeros usuarios.
Si la elección técnica aún no está del todo definida, una fase de definición previa sigue siendo útil para comparar una aplicación nativa, React Native, Flutter o un enfoque web. El tema está vinculado a la decisión más amplia entre aplicación móvil o sitio web según los usos, porque no todas las ideas merecen forzosamente una presencia en las stores.
| Elemento | Aplicación Store de Apple | Google Play |
|---|---|---|
| Cuenta de desarrollador en 2026 | Apple Developer Program, 99 USD al año | Google Play Console, 25 USD en un pago único |
| Archivo de publicación | Build iOS firmada y archivada mediante Xcode / App Store Connect | Android App Bundle .aab con Play App Signing |
| Prueba oficial | TestFlight, interno o externo | Internal, Closed u Open testing |
| Plazo de revisión anunciado | Apple indica que el 90 % de los envíos se revisan en menos de 24 h de media | De unas horas a 7 días o más en algunos casos |
| Puntos a tener en cuenta | Cuenta de organización, D-U-N-S, confidencialidad, notas de revisión | Declaraciones sobre el contenido de la app, pruebas obligatorias para algunas cuentas Personal |
¿Cómo probar la aplicación antes de su publicación?
La fase de prueba store no es solo un control de calidad. También verifica que la aplicación se comporta correctamente en un entorno cercano al real: instalación, permisos, conexión, pago, notificaciones, actualización, eliminación de la cuenta si se tratan datos personales.
En iOS, TestFlight permite invitar a probadores internos y externos. Las pruebas externas requieren información de beta y la primera build debe ser aprobada por App Review. Esta etapa puede sorprender: incluso una versión de prueba destinada a unos pocos clientes piloto puede ser examinada por Apple.
En Google Play, las vías Internal testing, Closed testing y Open testing cubren distintos niveles de exposición. El internal testing acepta hasta 100 probadores. Para las cuentas Google Play Personal creadas después del 13 de noviembre de 2023, Google impone una closed test con al menos 12 probadores inscritos de forma continua durante 14 días antes de solicitar el acceso a producción.
Sinceramente, publicar sin una verdadera fase beta rara vez resulta rentable. Los ahorros aparentes se transforman rápidamente en reseñas negativas, tickets de support y correctivos urgentes. Para limitar estos riesgos, una Lista de comprobación de seguridad antes de la publicación en dispositivos móviles debe cubrir los accesos, el cifrado, los permisos, los SDK de terceros y los registros de errores.
¿Qué debe contener la ficha de presentación en las stores?
La ficha store influye en la tasa de instalación, pero también en la validación. Apple y Google quieren entender qué hace la aplicación, para quién, con qué datos y en qué condiciones. Una ficha vaga del tipo “gestione todo desde su móvil” no ayuda ni al usuario ni al revisor.
En App Store Connect, prepare el nombre, las palabras clave, la descripción, las capturas de pantalla, las posibles app previews, la categoría, la build, la URL de support, la URL de la política de privacidad y la información de review. Apple exige como mínimo 1 captura de pantalla y acepta hasta 10 capturas por ficha, en .jpeg, .jpg o .png. Las app previews, vídeos cortos, son opcionales hasta 3 por tamaño de dispositivo y por idioma.
En Google Play Console, el nombre de la aplicación está limitado a 30 caracteres. La short description llega hasta 80 caracteres y la full description hasta 4 000 caracteres. También hay que proporcionar los elementos visuales, la categoría, las coordenadas de contacto y la política de privacidad según los casos.
- Preparar las capturas en pantallas reales representativas, no solo maquetas de marketing.
- Escribir una descripción clara de las funcionalidades realmente disponibles en el lanzamiento.
- Proporcionar una cuenta de prueba al reviewer si la aplicación requiere inicio de sesión.
- Verificar que los permisos solicitados correspondan al uso visible para el usuario.
- Publicar una política de privacidad accesible, estable y coherente con la aplicación.
El trabajo editorial de la ficha suele llegar demasiado tarde. Sin embargo, el ASO, u optimización para las stores, exige elecciones de palabras, categorías y elementos visuales. Si su proyecto está empezando encore, la guía para crear una aplicación móvil de la A a la Z ayuda a volver a situar la publicación dentro de una trayectoria completa, de la idea al lanzamiento.
¿Cómo declarar los datos personales recopilados?
La publicación de una aplicación en App Store y Google Play exige declarar los datos recopilados, incluidos los que pasan por herramientas de terceros. Un SDK es un bloque de software añadido a la app, por ejemplo para estadísticas, publicidad, crash reporting o inicio de sesión social.
En Apple, los App Privacy details, a menudo llamados Privacy Nutrition Labels, son obligatorios para las nuevas aplicaciones y las actualizaciones. Cubren los datos recopilados por la aplicación, pero también por sus socios y SDK de terceros. En 2026, Apple también señala la aparición de Accessibility Nutrition Labels en las páginas de producto para los dispositivos con iOS 26 y sistemas asociados, con información relacionada con la accesibilidad.
En Google, la sección App content sirve para declarar las prácticas de privacidad y seguridad, las clasificaciones de contenido, las políticas de privacidad y otras informaciones de conformidad. El RGPD, aplicable en la Unión Europea desde 2018, sigue siendo obviamente central si trata datos personales: base legal, información, consentimiento si es necesario, plazo de conservación, derechos de los usuarios.
Un caso frecuente en el que la solución evidente es mala: añadir una herramienta de análisis publicitario “por si acaso” incluso antes de tener una estrategia de adquisición. Aumenta las declaraciones, los riesgos de consentimiento y la superficie de control, a veces sin beneficio medible. Con un presupuesto reducido, es mejor instrumentar poco, pero correctamente.
¿Cómo se desarrolla la validación por parte de Apple y Google?
Una vez que el build y la ficha están listos, el envío pasa a review. Apple examina la aplicación conforme a sus App Review Guidelines, la estabilidad, la privacidad, el contenido, los pagos y la experiencia de usuario. Apple indica que el 90 % de los envíos se examinan en menos de 24 horas de media.
Google Play anuncia una review que puede tardar desde unas horas hasta 7 días, o más en casos excepcionales. Modificar informaciones durante una review puede reiniciar el proceso. Por tanto, para una fecha de lanzamiento anunciada públicamente, deje margen. Una semana de seguridad no es excesiva.
Los rechazos más clásicos no siempre son técnicos: ausencia de cuenta de prueba, funcionalidad no explicada, política de privacidad incoherente, permiso demasiado amplio, crash al iniciar, contenido considerado incompleto. Del lado de la agencia, el reflejo es enviar una versión estable con notas de review muy concretas: recorrido de prueba, credenciales, zonas sensibles, explicación de los permisos.
No obstante, la calidad técnica sigue siendo determinante. Tiempo de arranque, memoria, ANR en Android, es decir, ausencia de respuesta de la aplicación, y crashs de iOS pesan directamente sobre la experiencia y la visibilidad. Para los proyectos complejos, laingeniería móvil orientada al rendormiento iOS y Android se convierte en un asunto de pilotaje, no solo de desarrollo.
¿Qué obligaciones hay que prever después de la publicación?
La publicación no es el final. Hay que supervisar los crashs, los ANR, las reseñas, las valoraciones, las performances, las descargas, los errores de pago y los tickets de supporte. También hay que mantener los certificados, las firmas, los SDK, las declaraciones de privacidad, los países de difusión, los precios y las fichas de las stores.
Las normas evolucionan. Google Play anunció, por ejemplo, en 2026 una Android developer verification que entra en vigor a partir del 30 de septiembre de 2026 para la instalación en dispositivos Android certificados. Google también ha comunicado cambios de políticas relacionados con ciertos tipos de apps, como los chats anónimos o aleatorios con estándares ampliados de seguridad infantil.
Prevea un presupuesto de mantenimiento. Según los proveedores y la complejidad, puede ser necesaria una partida mensual de varios cientos a varios miles de euros para corriger, actualizar las dependencias, supervisar las stores y adaptar la app a las nuevas versiones de iOS y Android. Con un presupuesto muy reducido, es mejor reducir el alcance funcional inicial que sacrificar este mantenimiento.
Para una empresa, la decisión adecuada consiste en conservar la propiedad de las cuentas, al tiempo que se delegan la preparación técnica, las pruebas y la publicación. DualMedia ha acompañado la publicación de más de 100 aplicaciones de empresas en las stores; la experiencia demuestra sobre todo una cosa: los proyectos más tranquilos son aquellos en los que las cuentas, los certificados y los datos permanecen bajo el control del cliente desde el principio.
Definir este tipo de publicación de antemano evita la mayoría de las malas sorpresas: plazos administrativos, rechazos de review, fichas incompletas, declaraciones de datos poco sólidas. Una mirada externa ayuda a menudo a transformer una etapa percibida como final en un proceso controlado, con menos idas y vueltas y menos dependencia técnica.
Preguntas frecuentes sobre la publicación en App Store y Google Play
¿Cuánto cuesta publicar una aplicación en App Store y Google Play?
En 2026, la cuenta de Apple Developer Program cuesta 99 USD al año y la cuenta de Google Play Console cuesta 25 USD en un pago único. A eso se añaden el tiempo de preparación, de pruebas, de correction y de mantenimiento.
¿Cuánto tiempo se tarda en publicar la aplicación App Store en Google Play?
Si las cuentas están listas, se puede preparar un envío en unos pocos días. La review suele tardar menos de 24 horas en Apple según sus cifras, y de unas pocas horas a 7 días o más en Google Play.
¿Se puede publicar una aplicación sin una cuenta de empresa?
Sí, existen cuentas individuales, especialmente en Google con el tipo Personal. Para una pyme, una cuenta de organisation suele ser preferible para garantizar la propiedad, los accesos y la continuidad en caso de que se marche un colaborador.
¿Por qué Apple o Google pueden rechazar una aplicación?
Las causas frecuentes son un fallo, una ficha engañosa, datos personales mal declarados, permisos excesivos, una cuenta de prueba ausente o una política de privacidad incoherente. La mayoría de estos rechazos se pueden prevenir antes de la presentación.