Cuánto cuesta publicar una app en App Store y Google Play
Una guía práctica sobre el coste de publicar una app y todo lo que hay detrás del envío a tiendas.
El coste de publicar una app no depende solo de subir un archivo. Cambia según el estado de las cuentas de desarrollador, la calidad de la build, las capturas, la ficha de tienda, la política de privacidad, los accesos de prueba, los pagos, la analítica y la posibilidad de tener que corregir una revisión rechazada. Las cuotas oficiales de Apple y Google se pagan aparte y no sustituyen el trabajo de preparación del lanzamiento.
Estima tu app con un breve cuestionario
EmpezarQué se paga a las tiendas
Las cuotas oficiales de las tiendas solo abren la puerta. Apple cobra una membresía anual para su programa de desarrolladores y Google Play cobra un registro único para la consola. Esos pagos permiten distribuir la app, pero no preparan la ficha, no revisan la privacidad, no crean las capturas, no prueban los pagos y no corrigen una build rechazada.
Por eso una propuesta de publicación debe explicar qué incluye. No es lo mismo recibir un paquete de archivos ya listo y subirlo, que revisar la app, preparar los materiales, coordinar pruebas, contestar a la revisión y hacer una segunda entrega si aparece un problema.
Qué incluye un servicio serio
En una app sencilla, el trabajo suele cubrir la revisión de la cuenta, el identificador de la app, icono, capturas, nombre, descripción, categoría, clasificación por edad, enlace de soporte, política de privacidad, notas de versión y credenciales de prueba. Es el mínimo para que el revisor pueda entender qué hace la app y cómo probarla.
En un producto comercial hay más capas. Hay que validar TestFlight o pistas de prueba de Google Play, comprobar eventos de analítica, revisar fallos, probar notificaciones, verificar pagos, preparar datos de ejemplo y confirmar que el servidor de producción funciona. Si la app depende de reservas, cursos, pedidos, mensajería privada o roles de administración, el revisor necesita un camino claro.
Por qué cambia el coste
El precio sube cuando la app aún no está lista. Una build estable, con un flujo principal claro, se publica más rápido. Una app con backend en pruebas, login incompleto, capturas antiguas o textos que prometen funciones no disponibles genera trabajo adicional y riesgo de rechazo.
| Factor | Qué se revisa | Impacto en el coste |
|---|---|---|
| Cuentas | propietario, empresa, permisos y roles | sin propiedad clara el lanzamiento se retrasa |
| Ficha de tienda | título, descripción, capturas, categoría | afecta revisión y conversión |
| Privacidad | datos, SDK, analítica, soporte | los formularios deben coincidir con la app real |
| Acceso de prueba | usuario demo, datos, roles, entorno | el revisor debe completar el flujo principal |
| Pagos | suscripciones, servicios, compras, reembolsos | las reglas dependen del modelo de negocio |
| Revisión | notas, correcciones, nueva build | un rechazo puede añadir varios ciclos |
Cuándo puedes hacerlo internamente
Puedes publicar sin ayuda externa si el producto es pequeño, las cuentas ya son de tu empresa, la build está probada, no hay escenarios sensibles, la política de privacidad es correcta y alguien del equipo puede responder rápido a la tienda. En ese caso, quizá baste con una revisión final de la checklist.
El problema aparece cuando la persona que sube la app no conoce el producto. Puede que el revisor necesite un pedido de ejemplo, una reserva, una ruta de repartidor, una cuenta premium, una lección cargada o un panel de administración. Si ese contexto no está preparado, la app parece vacía o rota.
¿Tienes una idea de app y quieres el siguiente paso?
Revisar mi ideaCuándo pagar apoyo de lanzamiento
Merece la pena pagar apoyo cuando el lanzamiento está ligado a ventas, inversión, campañas, socios, franquicias o un calendario público. También cuando hay suscripciones, pagos, marketplace, geolocalización, contenido privado, salud, moderación o integraciones con CRM y ERP.
En Appfyl tratamos la publicación como una parte del lanzamiento, no como una tarea aislada. Si desarrollamos la app, queremos que la primera versión pública coincida con el alcance, el plan de pruebas y la ficha de tienda. Si revisamos una app hecha por otro equipo, primero auditamos build, cuentas, privacidad, analítica y materiales antes de prometer una fecha.
Qué preparar antes de pedir precio
Prepara el estado actual de la build, plataformas, propietario de las cuentas, política de privacidad, enlace de soporte, capturas, texto de la ficha, credenciales demo y una descripción del flujo principal. Si hay pagos, aclara si vendes contenido digital, servicios, productos físicos, reservas o transacciones entre usuarios.
También conviene decidir países e idiomas del primer lanzamiento. Localizar una ficha puede ser una adaptación ligera o un trabajo más grande con capturas locales, moneda, métodos de pago, confianza, soporte y textos legales. Si el producto se lanzará en varios mercados, no dejes esta decisión para el final.
Trabajo oculto que suele aparecer
Muchos retrasos vienen de incoherencias. La ficha habla de una función que no existe en la build. Las capturas enseñan pantallas antiguas. El formulario de privacidad omite un SDK. El login no permite entrar al revisor. La suscripción funciona en pruebas, pero falla en producción. El enlace de soporte lleva a una página vacía.
También hay que mirar el día posterior a la aprobación. Un lanzamiento necesita seguimiento de errores, eventos, pagos, reseñas y mensajes de soporte. La publicación termina cuando los primeros usuarios completan la acción principal sin ayuda manual del equipo.
Convierte la investigación en un plan
Appfyl convierte tu idea en un plan claro, una lista de funciones y el primer tramo de trabajo.
Hablar del plan de la appPuntos clave
- Las cuotas de las tiendas no cubren la preparación del lanzamiento.
- El coste depende más del estado de la app que del tiempo de subida.
- Privacidad, pagos y acceso demo suelen causar retrasos evitables.
- Una buena propuesta debe incluir revisión, materiales, respuesta a rechazos y coordinación.
- Para una app de negocio, publicación, QA, analítica y soporte deben planificarse juntos.
Enlaces útiles
Preguntas frecuentes
No. La publicación gestiona el envío a tiendas. Si aparecen fallos de login, pagos, privacidad o estabilidad, ya hablamos de trabajo de producto o desarrollo.
Para una empresa, lo normal es que la app pertenezca a la cuenta de la propia empresa. Eso protege actualizaciones, pagos, analítica, soporte y control futuro.
La subida puede ser rápida, pero el primer lanzamiento depende de verificación de cuenta, pruebas, revisión, posibles rechazos y velocidad de respuesta del equipo. Es mejor planear días o semanas.
Instala la app desde cero, recorre el flujo principal, verifica accesos demo, capturas, privacidad, pagos y servidor. Con eso la estimación será mucho más realista.