Desarrollo de apps de consumo en la nube: 10 puntos antes de firmar

Una app de consumo en la nube es un producto donde el móvil es la interfaz y la nube guarda la verdad: cuentas, sincronización entre dispositivos, medios, notificaciones push, cobros en las tiendas. Las pantallas son la mitad que se juzga en una demo. La otra mitad decide si el producto sigue funcionando con cincuenta mil usuarios, y ahí es donde las conversaciones previas a la firma se quedan en genérico.

Quedarse en genérico ahora sale caro. El informe 2026 de RevenueCat, hecho con más de 115.000 apps, muestra al primer cuartil creciendo un 80% en un año y al último perdiendo un tercio (RevenueCat, State of Subscription Apps 2026). En Estados Unidos las reglas de cobro en las tiendas cambiaron dos veces en dieciocho meses y ahora están en el Tribunal Supremo. Desde el 1 de enero de 2026 las tiendas pasan a los desarrolladores la franja de edad de las cuentas nuevas de Texas. Un estudio que publica apps de consumo sigue las tres cosas. Un estudio que publica paneles las aprenderá con tu presupuesto.

Diez comprobaciones. Seis que hay que exigir, cuatro que hay que rechazar.

El alcance real de una app de consumo en la nube

El alcance se acuerda antes de las comprobaciones. Una app de consumo en la nube son seis sistemas: el cliente en dos plataformas, el servicio de identidad y cuentas, la ruta de sincronización con un almacén local, la gestión de medios detrás de una CDN, el cobro en las tiendas con el estado de las suscripciones, y la parte operativa (push, analítica, informes de errores, herramientas de soporte). Quien presupuesta sobre pantallas ha presupuestado uno de los seis. Pide una línea por sistema, con el nombre de quien lo mantiene después del lanzamiento.

Exige el modelo de sincronización por escrito, antes de la primera pantalla

La sincronización es la arquitectura. Pregunta qué modelo piensan usar: escrituras autoritativas en el servidor con una copia SQLite local, replicación de lectura desde Postgres, o CRDT para los registros que dos personas editan a la vez sin conexión. Cada opción trae sus reglas de conflicto y su peor día.

Después viene la pregunta del proveedor. El 11 de agosto de 2026 Electric, uno de los motores de sync más conocidos, anunció su paso a Databricks (Electric). Las adquisiciones son normales y esta puede acabar bien: lo que importa es que tu modelo de datos sobreviva a una noticia así. Quien responde «cambiamos el transporte y mantenemos el contrato de mutaciones» se lo ha planteado. Quien nombra un SDK y se queda ahí, no.

Tres respuestas que conviene tener por escrito: qué campos ganan con la última escritura, cuáles necesitan una fusión de verdad, y qué ve el usuario cuando esa fusión no es posible.

Pide el recorrido del cobro, tienda por tienda y mercado por mercado

En Estados Unidos los enlaces de pago externos hoy no pagan comisión a Apple. El porcentaje está congelado en cero desde la sentencia por desacato de abril de 2025, el 30 de junio de 2026 el Tribunal Supremo admitió el recurso y el 14 de septiembre de 2026 Apple presentó su escrito de apertura (SCOTUSblog, Apple contra Epic Games). En la Unión Europea ese mismo enlace necesita el entitlement External Purchase Link de Apple y las tarifas que lleva detrás. La vista difícilmente llega antes de 2027, así que quien te dé un número definitivo está adivinando.

La pregunta útil es quién hace el trabajo cuando el número se mueve, y si ese trabajo está dentro del contrato o hace falta otro. Luego pregunta dónde vive el estado de la suscripción: en el recibo de la tienda, en tu servidor o en un servicio de billing. La comparación entre RevenueCat y Stripe Billing está aquí. Si la respuesta es que lo decide el cliente, párate ahí.

Señales de edad y borrado de cuenta son el mínimo

Desde el 1 de enero de 2026 Apple pasa a los desarrolladores la franja de edad de las cuentas nuevas creadas en Texas (menos de 13 años, 13-15, 16-17, 18 o más), el método de verificación usado y la señal de consentimiento parental, y ese dato hay que borrarlo en cuanto la comprobación termina (Apple Developer). Se aplica a todas las apps de la tienda, no solo a las dirigidas a menores, y otros estados han aprobado su versión de la misma ley (Wiley).

El borrado de cuenta dentro de la app es obligatorio desde 2022 por la directriz 5.1.1(v), incluida la revocación de los tokens de Sign in with Apple mediante la API REST (Apple Developer), y cada SDK que toca datos personales lleva su privacy manifest. Nada de esto es exótico. Quien publica apps de consumo este año lo enumera antes de que se lo preguntes.

Pide el coste por usuario activo, no solo el precio del proyecto

El precio del proyecto dice cuánto cuesta construir. El coste por usuario activo mensual dice si el producto sobrevive a su propio éxito. Pide la hoja: almacenamiento y tráfico de salida por usuario, lecturas y escrituras en la base de datos a la frecuencia de sync que han elegido, volumen de notificaciones, transcodificación si hay vídeo, tokens del modelo si hay IA. Luego pide la misma hoja con diez veces los usuarios.

Las apps de consumo mueren en la línea del tráfico de salida más que en la de los sueldos. Las cifras de construcción están en nuestro desglose de lo que cuesta desarrollar un SaaS. El número recurrente es el que se queda dentro de la vida de una app de consumo.

Construye el calendario de lanzamientos sobre los tiempos reales de revisión

Apple declara que el 90% de los envíos se revisa en menos de 24 horas (Apple, App Review). El primer envío, las apps que tratan datos sensibles y todo lo que toca a menores tardan más. Planifica con el caso lento y pide cuatro cosas: feature flags para publicar código apagado, despliegue por fases en Play, una vía de actualización forzada para el día en que cambia un contrato del servidor, y una regla para quien nunca actualiza.

Sin un interruptor remoto, cada error tiene un ciclo de revisión de antigüedad antes de que alguien lo arregle.

Exige medición de paywall y retención en la versión uno

Los benchmarks 2026 de RevenueCat dan la referencia. Los paywalls duros convierten al 10,7% en el día 35 frente al 2,1% del freemium. Las pruebas de 17 días o más convierten al 42,5% frente al 25,5% de las cortas. La mediana de descarga a pago en el día 35 es del 2,6% en Norteamérica frente al 1,4% en India y el Sudeste Asiático (RevenueCat). Esas cifras solo sirven al lado de las tuyas.

Así que el esquema de eventos es un entregable del lanzamiento: vistas del paywall, pruebas iniciadas, restauraciones fallidas, retención a 1, 7 y 30 días, motivo de baja donde la tienda lo dé. La analítica añadida en el tercer mes deja el primer mes sin medir.

No aceptes un portfolio web como prueba

Las webs de marketing y los paneles de administración demuestran que el estudio sabe publicar un frontend. Una app de consumo en la nube añade dos equipos de revisión, los estados sin conexión, la actualización en segundo plano, el momento de pedir el permiso de notificaciones, el paso a un móvil nuevo, la restauración de compras, la cadena de capturas de pantalla y el triaje de errores en varias versiones del sistema. Pide dos apps vivas en las tiendas, su valoración actual y la historia de su peor caída. Las señales de alarma se ven en cómo cuentan esa historia.

No dejes «soporte sin conexión» como una línea de lista

Estar sin conexión es una serie de decisiones y el usuario las ve todas. Qué viaja dentro del paquete de la app. Qué muestra en pantalla una escritura optimista. Qué pasa con una escritura en cola cuando el token caducó hace una hora. Cómo se resuelven dos ediciones en conflicto. Qué dice la interfaz cuando no se resuelven. Esas cinco respuestas van en la propuesta, o sin conexión significa que la app guarda en caché la última pantalla y tus usuarios se enteran en el metro.

No dejes tiendas, claves y cuentas de nube a nombre del estudio

App Store Connect, Play Console, los certificados de firma, el proyecto en la nube, el dominio, la propiedad de analítica: todo a nombre de tu sociedad desde el primer día, con el estudio añadido como miembro. Es el bloqueo más común que vemos en trabajo de consumo y evitarlo no cuesta nada. Pon la titularidad en el SOW y compruébala antes de que suban la primera build, no durante la discusión.

No dejes el cumplimiento para la semana del lanzamiento

Etiquetas de privacidad, flujo de borrado, gestión de las señales de edad, consentimiento de notificaciones, plazos de conservación: cada una toca el modelo de datos. Pegadas en el último sprint producen rechazos y retrabajo, los dos en la ruta crítica. Pregunta en qué sprint está cada una. «Antes del envío» significa que el plan ya tiene un error.

Las diez comprobaciones, en orden

1. Modelo de sincronización por escrito, con las reglas de conflicto explícitas.
2. Una respuesta de salida del proveedor para el motor de sync elegido.
3. Recorrido del cobro por tienda y por mercado, y quién absorbe un cambio de reglas.
4. Señales de edad y borrado dentro de la app ya en su proceso.
5. Coste por usuario activo mensual, hoy y con diez veces los usuarios.
6. Calendario de lanzamientos construido sobre revisiones lentas, feature flags y despliegue por fases.
7. Esquema de eventos de paywall y retención publicado en la versión uno.
8. Dos apps de consumo vivas, con valoraciones y una historia honesta de caída.
9. Cuentas de tienda, claves de firma y proyecto en la nube a nombre de tu sociedad.
10. Trabajo de cumplimiento colocado en sprints concretos, no en el último.

Debajo de las diez hay el mismo hecho: una app de consumo en la nube se juzga en el móvil y se decide en la nube. Cada comprobación sirve para saber, antes de que se mueva el dinero, si el estudio ha vivido en la segunda mitad.