Lo que cuesta

Cuánto cuesta una app móvil

Una aplicación cuesta más que una web, y no es una cuestión de complejidad: es que se paga dos veces, y luego cada año. Dos veces, porque iPhone y Android son dos sistemas distintos. Cada año, porque las dos tiendas imponen actualizaciones para seguir publicable — una aplicación que ya no se toca acaba retirada. El presupuesto de fabricación no dice nada de esa parte, y es la que decide si el proyecto sobrevive. Esta página detalla el método de cálculo, las partidas que vuelven, y lo que cambia una suscripción en la que un equipo se queda después de la publicación.

1. Por qué se paga dos veces

Es el hecho que gobierna todo el presupuesto, y el que se descubre más a menudo tras haber pedido un primer presupuesto.

Dos sistemas, dos mundos. iOS y Android no tienen el mismo lenguaje, ni las mismas convenciones de presentación, ni las mismas reglas de permisos. Históricamente, eso significaba dos desarrollos completos, es decir aproximadamente el doble de carga.
Las tecnologías comunes reducen la distancia sin borrarla. Escribir una base compartida es hoy la norma, pero el ajuste fino, las pruebas y las particularidades de cada plataforma quedan por hacer dos veces. Cuente un suplemento real, no un doble.
Dos tiendas que satisfacer. Cada una tiene sus reglas de publicación, sus imágenes que producir en las dimensiones correctas, sus textos que traducir y su examen que pasar. Es un trabajo administrativo en sí mismo, distinto del desarrollo.
Un parque de dispositivos, no un dispositivo. Tamaños de pantalla muy distintos, versiones de sistema antiguas aún en servicio. Lo que la web resuelve con una hoja de estilos aquí exige pruebas en varias configuraciones.

A igual carga, una aplicación cuesta, por tanto, estructuralmente más que una web. La verdadera pregunta no es cómo pagar menos, sino si la aplicación es necesaria — es la sección 5, y merece leerse antes de pedir un presupuesto.

2. Calcular un desarrollo, partida por partida

Como para una web, no existe ninguna tarifa de referencia. Estas son las partidas que hay que hacer calcular por separado: un presupuesto que las funde en una línea no puede compararse con ningún otro.

Las pantallas. Cuéntelas, y distinga las que muestran de las que capturan: un formulario, con sus errores y sus casos límite, cuesta varias veces una pantalla de consulta.
La cuenta de usuario. Registro, acceso, contraseña olvidada, eliminación de la cuenta — esta última exigida por las tiendas en cuanto hay registro. Este bloque casi siempre se subestima.
El servidor y los datos. Una aplicación que solo muestra contenido fijo es barata. En cuanto guarda algo, hacen falta una base, una interfaz para administrarla y una copia de seguridad. Suele ser la primera partida del presupuesto.
Las notificaciones. Técnicamente sencillas, costosas en ajustes: permisos que pedir, comportamientos distintos en los dos sistemas, y una lógica de negocio que escribir para decidir qué enviar y cuándo.
El pago dentro de la aplicación. Si hay una compra, las tiendas imponen su propio mecanismo y cobran una comisión. Es a la vez un desarrollo y una parte de su facturación.
La prueba de aceptación en dispositivos reales. No negociable, y la primera partida recortada en un presupuesto apretado — lo que se paga en correcciones después de la publicación, a tarifa de urgencia.

3. Lo que corre cada año

Una web descuidada sigue en línea. Una aplicación descuidada se vuelve inutilizable, y luego desaparece. Es la diferencia esencial, y es financiera.

Los gastos de cuenta de desarrollador. Publicar exige una cuenta en cada tienda: una suscripción anual del lado de Apple, un pago único del lado de Google. Modesto, pero la suscripción de Apple no renovada retira la aplicación de la venta.
Las actualizaciones impuestas. Cada año, las nuevas versiones de iOS y Android desplazan reglas, y las tiendas exigen una compilación con herramientas recientes para aceptar una actualización. Hay que intervenir, por tanto, incluso sin cambiar nada en la aplicación.
El servidor. Alojamiento, base de datos, copias de seguridad: un gasto mensual que crece con el uso.
Las correcciones. Un fallo no se ve como una página rota: se ve en las valoraciones de la tienda, donde queda meses.
El seguimiento de las valoraciones. Nadie se ocupa de ellas, y son lo primero que lee un futuro usuario.

Provisione estas partidas a tres años antes de firmar. Una aplicación entregada sin presupuesto de continuidad es una aplicación que será retirada de las tiendas — a veces antes de haber servido.

4. El coste de las tiendas: el rechazo

Es una partida ausente de todos los presupuestos, y es real: la publicación no es un depósito, es un examen. Las dos tiendas revisan la aplicación y rechazan por motivos a menudo ajenos al desarrollo — una política de privacidad incompleta, una eliminación de cuenta imposible de encontrar, credenciales de prueba que no funcionan, una explicación de permiso considerada insuficiente, un parecido con una web sin valor propio.

Cada rechazo cuesta dos cosas. Tiempo: una corrección, un nuevo envío, una nueva espera. Y una fecha: si el lanzamiento estaba anunciado, se desplaza. Un proyecto llevado sin margen en este punto acaba pagando una urgencia por un motivo administrativo.

Pregunte, pues, a cualquier proveedor quién gestiona la publicación y quién retoma los rechazos. La respuesta vale una línea de presupuesto.

5. La pregunta que hay que hacerse antes de pagar

Muchas aplicaciones no deberían haberse desarrollado, y el presupuesto habría estado mejor en otra parte. Tres preguntas lo resuelven con honestidad.

¿El uso es repetido? Se instala una aplicación por lo que se abre a menudo — pedir, seguir, fichar, fidelizar. Para una consulta ocasional, una web en el teléfono lo hace mejor, sin instalación que obtener.
¿Necesita el dispositivo? Notificaciones, cámara, ubicación, funcionamiento sin red, códigos de barras: si nada de eso sirve, la aplicación no aporta lo que la web no sabe hacer.
¿Quién va a instalarla? Es el punto que hunde más proyectos. Obtener una instalación es más difícil que obtener una visita. Sin una audiencia ya cautiva — clientes habituales, socios, equipos de campo — la aplicación quedará vacía, sea cual sea su calidad.

Si las tres respuestas no son claras, empiece por la web: la página sobre cuánto cuesta una web detalla ese camino. La aplicación llegará cuando exista el uso.

6. Pagar por el después, no por la publicación

Si el gasto se concentra después del lanzamiento, entonces lo que hay que comprar no es un desarrollo: es una presencia que dure.

En nullbot, la aplicación se describe en conversación, igual que la web. Se la ve funcionar en un simulador de iOS y Android antes de cualquier publicación — se puede manipular y tomar capturas. Puede tener su base de datos, pasa una prueba de aceptación, se produce el binario para cada destino, y la publicación en la App Store y Google Play se pilota desde el mismo sitio, con el estado de cada tienda a la vista.

Sigue sin ser lo que vendemos. Lo que vendemos es el año siguiente: el equipo de agentes que se queda. Prepara las actualizaciones que reclaman las tiendas, retoma un rechazo de examen, corrige lo que falla, mantiene las fichas y sus traducciones, vigila las valoraciones. La aplicación no espera un presupuesto de mantenimiento que no llegará — es el trabajo corriente del equipo.

El gasto deja de ser un proyecto que financiar y luego refinanciar. Se convierte en una suscripción mensual, y la publicación ya no es un final de recorrido.

7. Semana 1, mes 3, año 2

Los tres momentos que separan las ofertas — y no son los mismos que para una web, porque las tiendas imponen su calendario.

Semana 1. La aplicación está publicada en las dos tiendas, sus fichas están completas, una cuenta de prueba funciona para el examen. Un proveedor competente sabe hacerlo.
Mes 3. Tres quejas se refieren a la misma pantalla, una valoración de dos estrellas está a la cabeza, ha salido una versión de sistema. La pregunta pasa a ser: ¿quién ha publicado la corrección? Un proyecto entregado sin continuidad está aquí ya perdiendo a sus usuarios.
Año 2. Las dos tiendas exigen una compilación con herramientas más recientes, so pena de rechazar cualquier actualización. Sin intervención, la aplicación sigue instalada en quienes la tienen, ya no se instala en ninguna parte, y acaba por no arrancar. Es el momento en que aparece un presupuesto de rediseño — por la misma razón por la que volverá a aparecer.

8. Los límites, dichos con franqueza

Una aplicación muy especializada sigue siendo desarrollo a medida. Tratamiento avanzado de imagen, hardware conectado por Bluetooth, cartografía fina, un juego: son oficios, y un presupuesto de desarrollo clásico.
El examen de las tiendas no se garantiza. Ningún proveedor puede prometer una aceptación, ni un plazo. Lo que se promete es retomar el expediente hasta que pase.
Una aplicación no crea su audiencia. Si nadie la instala, ningún equipo lo cambiará. Vuelva a leer la sección 5: es la decisión más económica del proyecto.
Lo que compromete a la empresa pasa por una validación. Una puesta en venta, un cambio de tarifa, un mensaje enviado a todos los usuarios se le someten antes de salir.

9. Preguntas frecuentes

¿Por qué no dar un precio medio para una aplicación móvil?

Porque la diferencia entre una aplicación de consulta y una aplicación con cuentas, pago y notificaciones es tal que una media no informaría de nada. Las partidas de la sección 2, calculadas para su caso, dan un orden de magnitud defendible. Un importe único daría sobre todo una falsa seguridad al comparar dos presupuestos.

¿Una sola aplicación para iPhone y Android cuesta menos?

Menos que dos desarrollos separados, sí, y es la práctica corriente. Pero el ahorro no es de la mitad: el ajuste fino, las pruebas y las particularidades de cada plataforma quedan por hacer de los dos lados, y las fichas de tienda hay que producirlas dos veces. Cuente un suplemento respecto a una plataforma única, no una gratuidad de la segunda.

¿Hace falta una cuenta de Apple y de Google a mi nombre?

Es muy preferible, y es un punto que hay que resolver antes de firmar. Una aplicación publicada en la cuenta de un proveedor es difícil de recuperar, y su historial de valoraciones no se transfiere. Abra las cuentas a nombre de la empresa, aunque después delegue el acceso: son quince minutos al principio, y un bloqueo total más adelante.

¿Qué ocurre si nunca actualizo la aplicación?

Tres cosas, en este orden. Las tiendas rechazan primero sus nuevas versiones porque las herramientas de compilación son demasiado antiguas. Luego la aplicación deja de funcionar correctamente en los teléfonos recientes. Por último, una aplicación sin actualización desde hace mucho puede ser retirada de la venta. Es lo que distingue una aplicación de una web: la inacción no la deja en su sitio, la suprime.

¿Mi web basta en lugar de una aplicación?

En la mayoría de los casos de empresa, sí — y sigue siendo cierto incluso cuando una aplicación resultaría agradable. Una web funciona en todos los teléfonos, no exige instalación, no tiene revisión que pasar ni actualización impuesta cada año. La aplicación se justifica cuando el uso es repetido y hace falta algo del dispositivo. Las tres preguntas de la sección 5 lo resuelven en unos minutos.

Para profundizar

Leer a continuación: cómo se crea la aplicación, paso a paso, cuánto cuesta una web, o cuánto cuesta un empleado.