La semana de lanzamiento va bien en staging. El API es rápido, las notificaciones push llegan, QA da el visto bueno y el equipo por fin respira. Entonces llega el tráfico de producción de una nueva campaña, los clientes móviles empiezan a reintentar solicitudes en redes inestables, las descargas de imágenes se disparan en algunas regiones y un error de configuración que parecía inofensivo convierte una interrupción parcial en una cola de soporte en llamas.
Ese patrón de fallo es común porque los equipos suelen tratar la infraestructura como hosting de backend más un job de CI. Para una app móvil crítica, esa definición se queda corta. La planificación de infraestructura incluye dónde se ejecuta code, cómo se almacenan los datos, cómo llegan las actualizaciones a los dispositivos, cómo se comportan los clientes en redes malas, qué tan rápido puedes revertir un release y qué tan claro tienes qué se rompió en una versión concreta de la app en una región concreta.
Los sistemas móviles fallan en los extremos. Los retrasos de aprobación de la App Store pueden frenar un hotfix. Los dispositivos de los clientes tienen batería, memoria y almacenamiento limitados. La ejecución en segundo plano está restringida. La entrega de última milla importa porque los usuarios experimentan tu app a través de radios, cachés, CDNs, binarios de la app y assets en vivo, no a través de diagramas de arquitectura. Un backend puede parecer saludable mientras el producto móvil está caído en la práctica.
Por eso la planificación de infraestructura debe ser proactiva. La misma lógica amplia de inversión que se aplica a la infraestructura física también se da en los sistemas digitales. Los países deben invertir alrededor de 3,7 billones de dólares anuales en infraestructura económica hasta 2035, y la inversión privada en infraestructura aumentó de 95 mil millones de dólares en 2023 a casi 200.000 millones de dólares en 2025, según el informe de infraestructura de McKinsey. La versión de software de esa realidad es simple: los sistemas resilientes requieren planificación deliberada, no optimismo.
Tabla de contenidos
- Introducción: Más allá de "Funciona en mi máquina"
- Los componentes principales de la infraestructura de aplicaciones
- Un framework práctico para la planificación de infraestructura
- Gestión de costos y mitigación de riesgos
- Definición de KPIs de éxito y criterios de decisión
- Herramientas y tecnologías para la infraestructura de apps móviles
- Conclusión: tu roadmap de infraestructura y próximos pasos
Introducción: Más allá de "Funciona en mi máquina"
Una app móvil puede pasar todas las comprobaciones previas a la publicación y aun así ser frágil. La razón es que los entornos de prueba rara vez reproducen el comportamiento de producción en el edge. En producción, los usuarios abren versiones antiguas de la app tras semanas sin conexión, los dispositivos se activan con tokens de autenticación obsoletos, el Wi-Fi del hotel interrumpe peticiones a mitad de camino y una actualización del sistema operativo cambia el timing de las tareas en segundo plano. Si tu planificación de infraestructura ignora esa realidad, tu primera prueba de carga real será tu base de clientes.
Para equipos móviles empresariales, la planificación de infraestructura no es solo aprovisionamiento en la nube. Es la disciplina de decidir cómo la app sobrevivirá al crecimiento, la degradación, los errores de publicación, los incidentes de seguridad y la inevitable discrepancia entre las suposiciones del backend y el comportamiento del lado del cliente. Eso significa planificar para APIs, bases de datos, colas, almacenamiento, entrega vía CDN, secretos, observabilidad, controles de despliegue gradual y canales de actualización que puedan corregir errores sin hacer esperar a los usuarios a la revisión de la tienda.
Regla práctica: Si la recuperación depende de que los ingenieros improvisen en Slack, no tienes planificación de infraestructura. Tienes esperanza de infraestructura.
Las apps móviles y multiplataforma añaden restricciones que los equipos solo web a veces pueden ignorar. El almacenamiento del dispositivo se agota. Los bundles de JavaScript se desincronizan de las versiones del shell nativo. Un release puede ser seguro en iOS y problemático en Android. Un problema de login puede afectar solo a usuarios que reanudaron la app desde segundo plano tras cambiar de red. Una buena planificación acepta que la app es un sistema distribuido con miles de runtimes de cliente que no controlas.
El beneficio no es abstracto. Una planificación de infraestructura sólida protege la velocidad de desarrollo porque los equipos pueden lanzar con guardrails. Protege los ingresos porque las caídas y las actualizaciones rotas se contienen más rápido. Protege la credibilidad porque el soporte puede explicar qué pasó, quién se vio afectado y qué cambió.
Lo que funciona es aburrido de la mejor manera. Entornos estables. Propiedad clara. Rutas de rollback explícitas. Telemetría consciente de versiones. Canales de release separados por audiencia y riesgo. Lo que no funciona es combinar despliegues de backend, cambios en el binario móvil y actualizaciones de assets del cliente en un único evento de release opaco y esperar que los dashboards lo resuelvan después.
Los componentes principales de la infraestructura de aplicaciones
Una forma sencilla de explicar la infraestructura de una aplicación es compararla con una casa. Si una parte es débil, los ocupantes lo notan rápidamente. Una app móvil tiene el mismo problema. Puedes construir una interfaz pulida, pero si los sistemas subyacentes son insuficientes, invisibles o difíciles de actualizar, el producto se siente poco fiable.
Un buen hábito de planificación es escribir las especificaciones de resultados antes de discutir sobre proveedores. Según la guía de infraestructura del Global Infrastructure Hub, una planificación eficaz depende de cinco áreas clave: requisitos funcionales, gestión de contratos, requisitos de diseño y construcción, requisitos de mantenimiento y ciclo de vida, y requisitos operativos, todo alineado con estándares más amplios y las reglas del propietario en la referencia del GI Hub sobre especificaciones de resultados. En términos de software, esto significa que debes definir cómo debe comportarse el sistema, quién es el propietario, cómo se construye, cómo se mantiene y cómo se opera antes de comprometerte con un stack.
Piensa en capas, no en servicios
Cómputo El cómputo es donde se ejecuta la lógica de tu app. Puede tratarse de contenedores en Kubernetes, funciones serverless, plataformas de apps gestionadas o una mezcla. Para backends móviles, la planificación de cómputo debe centrarse en la latencia de inicio, el comportamiento de concurrencia, la ubicación regional y el aislamiento de fallos. Una carga de trabajo intermitente activada por push puede encajar con serverless. Un servicio de chat con conexiones de larga duración puede necesitar servicios en contenedores con un autoscaling cuidadoso.
Almacenamiento abarca bases de datos relacionales, cachés, almacenamiento de objetos e índices de búsqueda. Los sistemas móviles suelen crear patrones de almacenamiento poco prácticos porque los clientes sincronizan de forma intermitente y reintentan agresivamente. Planifica idempotencia, gestión de conflictos, retención y simulacros de restauración de backups. También planifica patrones de almacenamiento cifrado en el dispositivo y en el servidor. Los equipos que trabajan con los trade-offs de protección de datos móviles suelen beneficiarse de guías como cifrar SQLite en apps de Capacitor.
Redes es la capa que los equipos móviles suelen subestimar más. Incluye balanceadores de carga, gateways de API, CDNs, terminación TLS, reglas WAF y caché en el edge. La entrega de última milla ocurre aquí. Si tus asset bundles, imágenes, feature flags y payloads de configuración no se sirven de forma eficiente en las distintas regiones, los usuarios notan lentitud aunque tu API principal esté sano.
Monitoreo es tu sistema de seguridad y caja negra. Logs, trazas, métricas, reportes de crash, checks sintéticos y telemetría móvil por versión van aquí. La observabilidad debe responder preguntas prácticas rápido: ¿Qué release introdujo el error? ¿El fallo está ligado a una versión de OS específica? ¿Los reintentos vienen de una región o de un patrón de operador concreto?
Seguridad es la base de todo lo anterior. La autenticación, autorización, gestión de secrets, manejo de certificados, escaneo de dependencias, suposiciones de confianza en el dispositivo y acceso de mínimo privilegio son preocupaciones centrales de infraestructura, no simples añadidos de cumplimiento.
Checklist práctico para equipos móviles
| Componente | Pregunta clave a responder | Ejemplo de métrica u objetivo |
|---|---|---|
| Cómputo | ¿Puede el backend absorber tormentas de reintentos móviles y picos de tráfico? | Tiempos de respuesta estables en picos de login o sincronización |
| Almacenamiento | ¿Los datos resisten conflictos de sync, restauraciones y escrituras parciales? | Restauración de backups exitosa y resolución limpia de conflictos |
| Redes | ¿Llegan los assets y APIs rápido a los dispositivos con red débil? | Baja latencia en endpoints críticos y payloads de actualización |
| Monitoreo | ¿Puede el equipo aislar fallos por versión de la app, plataforma y región? | Alertas vinculadas a la versión de release, tendencias de crashes y errores de API |
| Seguridad | ¿Están protegidos los secretos, tokens y datos de usuario en el cliente y el servidor? | Controles de acceso verificados, auditabilidad y capacidad de respuesta ante incidentes |
El error de infraestructura más caro no suele ser el subaprovisionamiento. Es construir un sistema que nadie puede entender durante un incidente.
Un framework práctico para la planificación de infraestructura
Los buenos planes no empiezan con módulos de Terraform. Empiezan con la realidad operativa. Los equipos necesitan una secuencia que convierta la intención de negocio en sistemas desplegables sin descuidar la seguridad del release, el comportamiento del cliente o el mantenimiento.
Empieza con la realidad operativa
La Fase 1 es el descubrimiento. Identifica primero los flujos críticos de negocio. El login, el checkout, el envío de reclamaciones, la sincronización offline, la subida de documentos y la entrega de mensajes son mejores puntos de partida que objetivos genéricos de throughput. Para móvil, el descubrimiento también requiere un mapa de release: binarios de la App Store, assets web, remote config, feature flags y SDKs de terceros.
La Fase 2 es la arquitectura. En esta fase, los equipos definen límites, flujo de datos, dominios de fallo y la estrategia de actualización. Una de las primeras decisiones es la forma del servicio. Muchos equipos funcionan mejor con un monolito modular que con una dispersión prematura de servicios, especialmente al inicio del ciclo de vida de un producto. Si tu equipo aún está decidiendo dónde trazar esa línea, este desglose de arquitectura monolítica vs microservicios para apps en crecimiento es una herramienta útil de encuadre.
En esta etapa, las decisiones sobre el modelo de nube también importan. Equipos regulados, restricciones de compras empresariales, residencia de datos y requisitos de latencia pueden orientarte hacia diferentes modelos operativos. Una forma sólida de analizar esos trade-offs es Elegir tu infraestructura de IA, especialmente si tu hoja de ruta de la app incluye inferencia de modelos, cargas de trabajo privadas o entornos de despliegue mixtos.
Diseña para la repetibilidad y la recuperación
La fase 3 es la implementación mediante infraestructura como code. Usa Terraform, Pulumi o CloudFormation para aprovisionar entornos de forma consistente. Almacena la configuración de la aplicación con control de versiones y separa los secretos en un gestor adecuado como AWS Secrets Manager, Google Secret Manager, Azure Key Vault o HashiCorp Vault. El objetivo no es la elegancia. Es la repetibilidad bajo presión.
La fase 4 es la prueba. Para infraestructura móvil, las pruebas deben ir más allá de las comprobaciones de API. Ejecuta pruebas de carga contra autenticación, subida de archivos y ráfagas activadas por notificaciones. Pon a prueba la invalidación de caché. Simula despliegues fallidos. Verifica versiones antiguas de la app contra el nuevo comportamiento del backend. Prueba qué ocurre cuando los clientes reanudan tras largos períodos sin conexión.
Construye tu ruta de rollback antes de necesitar tu primer rollback.
El principio de resiliencia aquí es más amplio que el software. La OCDE argumenta que un enfoque de ciclo de vida es crítico porque la planificación, el diseño, la operación y el mantenimiento contribuyen a la resiliencia, y el mantenimiento preventivo junto con decisiones de diseño modernas mejoran la vida útil y la adaptabilidad de los activos en el compendio de la OCDE sobre infraestructura de calidad. Esto se aplica directamente a los sistemas de software. Los equipos que reservan tiempo para parches, actualizaciones de dependencias, rotación de certificados y corrección del drift del entorno evitan ese deterioro lento que acaba provocando incidentes visibles.
Mantén el plan vivo
La Fase 5 es operación e iteración. En esta fase, muchos equipos dejan de planificar y empiezan a reaccionar. No lo hagas. Usa el comportamiento en producción como input para el siguiente ciclo de planificación. Revisa incidentes, alertas ruidosas, clusters de crashes móviles, regiones lentas, acumulación de colas y releases fallidos. Luego actualiza runbooks, umbrales de scaling, defaults de rollout y estándares del entorno.
Lo que funciona es un plan vivo con responsables asignados. Lo que falla es un documento de arquitectura estático que nadie actualiza cuando empieza la presión por el delivery.
Gestión de costos y mitigación de riesgos
Los problemas de costos en la nube rara vez vienen de una sola decisión desastrosa. Vienen de la acumulación. Entornos extra que nadie limpia. Bases de datos sobredimensionadas elegidas en un lanzamiento tenso. Loguear cada request body para siempre. Tráfico cross-region que parecía inofensivo en los diagramas. Nodos de Kubernetes inactivos porque la política de scaling se escribió una vez y se olvidó.
Control de costes: empieza por el perfil de carga
El primer paso práctico es mapear la forma de la carga de trabajo, no solo el uso total. Los backends móviles suelen tener picos alrededor del inicio de sesión, la apertura de la app, las notificaciones y las ventanas de sincronización programada. Si la demanda es irregular, el autoscaling de cómputo o los componentes orientados a eventos pueden superar a la capacidad siempre activa. Si el tráfico es estable y predecible, la capacidad reservada o el uso comprometido pueden ser la mejor opción financiera.
Algunos hábitos ayudan consistentemente:
- Dimensiona según el comportamiento: Revisa el uso de CPU, memoria y base de datos frente a los patrones de tráfico reales. Muchos servicios se dimensionan por miedo, no por evidencia.
- Separa lo crítico de lo conveniente: Mantén la resiliencia de grado de producción donde más importa. No todas las herramientas internas o entornos de previsualización necesitan la misma postura de disponibilidad.
- Reduce la gravedad de los datos: Logs, media, analytics exports, and backups tend to grow. Set retention rules intentionally.
- Vigila el egress y las rutas de edge: Las apps móviles mueven muchos assets. El redimensionado de imágenes, la entrega de bundles y la distribución de medios pueden trasladar el costo del cómputo a la red rápidamente.
El costo total de propiedad también incluye la carga operativa. Un clúster más barato no es más barato si solo un ingeniero lo entiende. Un componente autoalojado puede ser racional, pero solo si el equipo acepta el parcheo, la monitorización, las actualizaciones y la respuesta a incidentes como trabajo continuo.
El riesgo suele esconderse en las rutas de release
La parte de mayor riesgo de un sistema móvil suele ser el pipeline de releases, no la base de datos. Los cambios en el backend, los binarios del cliente, los switches de configuración y las actualizaciones de assets interactúan entre sí. Si esos cambios se publican sin aislamiento, creas cadenas de fallo difíciles de revertir.
Centra tu atención primero en los riesgos que importan:
- Puntos únicos de fallo: Una instancia de base de datos, un build runner, un proceso de firma de claves, una persona que sabe cómo funciona el rollback.
- Deploys inseguros: Releases directos a producción sin etapa canary, sin health gate y sin rollback automatizado.
- Incompatibilidad de versiones: Nuevos supuestos de API que rompen versiones antiguas de la app que siguen activas en producción.
- Fragilidad de terceros: Los proveedores de autenticación, los SDKs de pago, los vendors de push y las herramientas de analítica pueden degradar tu app sin tocar tu code.
Para equipos enterprise, un Checklist de seguridad OTA para apps con Capacitor ayuda a forzar estas conversaciones antes de la revisión de incidentes. El objetivo no es la burocracia, sino hacer visibles las suposiciones ocultas.
Si no puedes desactivar un release defectuoso en minutos, tu proceso de despliegue tiene más riesgo que tu propio codebase.
La mitigación de riesgos debe incluir rollouts escalonados, checks sintéticos para rutas críticas, simulacros de recuperación, backups probados, inventarios explícitos de dependencias y una cadena de mando de incidentes documentada. El coste y el riesgo van de la mano. La arquitectura más barata sobre el papel se vuelve cara enseguida si la recuperación es lenta, ruidosa y manual.
Definición de KPIs de éxito y criterios de decisión
Los equipos suelen decir que quieren infraestructura escalable cuando en realidad se refieren a una de tres cosas: menos incidentes, releases más rápidos o menor gasto. Son resultados distintos y requieren mediciones diferentes. Si no defines el KPI antes de elegir la herramienta, terminarás debatiendo sobre plataformas sin un marco de decisión.
La importancia de las métricas objetivas va más allá del software. El mercado global de infraestructura se valoró en 2,56 billones de USD en 2023 y se prevé que alcance los 4,69 billones de USD para 2033, y una priorización efectiva requiere fuentes de datos estandarizadas y métricas agnósticas al sector, según el resumen ejecutivo de ASCE 2025. La planificación de la infraestructura de aplicaciones tiene el mismo requisito. Las métricas estándar permiten comparar trade-offs sin que cada decisión sea una opinión.
Elige métricas que cambien tus decisiones
Para apps móviles críticas, el set de KPIs más útil suele ser pequeño y operativo:
- Rendimiento: Latencia de API en rutas críticas, experiencia de arranque de la app, tiempo de entrega de assets y retraso en colas.
- Fiabilidad: Uptime de servicios de cara al usuario, tasa de errores por endpoint, tendencias de crashes por versión y tiempo medio de recuperación.
- Escalabilidad: Límites de concurrencia, saturación de recursos y acumulación de tareas ante picos de tráfico.
- Eficiencia de costos: Gasto por entorno, por carga de trabajo principal y por superficie de release. Si las actualizaciones móviles o el tráfico multimedia impulsan el costo, debe ser visible.
- Seguridad y cumplimiento: Tiempo de respuesta ante vulnerabilidades, disciplina de rotación de secretos, finalización de revisiones de acceso y trazabilidad de incidentes.
Si estás ajustando qué medir en la app y el backend a la vez, esta guía sobre métricas de rendimiento de apps móviles que realmente ayudan a los equipos a decidir es un gran complemento.
Usa criterios de decisión antes de elegir herramientas
Las métricas te dicen si el sistema rinde. Los criterios de decisión te dicen si un cambio propuesto vale la pena. Usa una scorecard ligera antes de seleccionar herramientas o patrones de infraestructura.
Una scorecard práctica pregunta:
| Área de decisión | Qué evaluar |
|---|---|
| Team fit | ¿Puede el equipo actual operarlo sin heroicidades? |
| Claridad ante fallos | Si falla, ¿será evidente el alcance del impacto? |
| Seguridad en los releases | ¿Puedes hacer canary, pausar y revertir limpiamente? |
| Compatibilidad móvil | ¿Funciona bien con clientes offline, versiones antiguas y distribución de assets? |
| Tolerancia al lock-in | Si necesitas migrar más adelante, ¿qué tan doloroso será? |
El error a evitar es optimizar para la escala teórica máxima ignorando las operaciones del día a día. Una plataforma que parece potente en la evaluación puede ser la elección equivocada si depurarla requiere conocimiento experto que tu equipo no tiene. Las mejores decisiones de planificación de infraestructura suelen ser las que tu ingeniero on-call puede entender a las 2 a.m.
Herramientas y tecnologías para la infraestructura de apps móviles
El rango de herramientas disponibles es amplio, pero la mayoría de los equipos móviles no necesitan infraestructura exótica. Necesitan un stack que soporte APIs confiables, releases seguros, buena observabilidad y rutas de corrección rápidas cuando un cliente desplegado se comporta de forma diferente en producción.
The stack most teams actually need
Para la base en la nube, las opciones habituales: AWS, Google Cloud, o Azure. La elección correcta suele depender menos de los mitos sobre benchmarks y más de los sistemas de identidad existentes, las reglas de compra, la madurez de los servicios gestionados y dónde tu equipo ya tiene experiencia operativa.
Para mantener la consistencia de empaquetado y runtime, Docker es el estándar por defecto. Kubernetes tiene sentido si necesitas control de scheduling, patrones de despliegue estandarizados u orquestación de múltiples servicios, y si estás preparado para operarlo bien. Si no, runtimes gestionados como AWS App Runner, Cloud Run, Azure Container Apps o funciones serverless pueden reducir la carga operativa.
Para CI/CD, las opciones comunes son Acciones de GitHub, GitLab CI, CircleCI, Bitrise, y Jenkins en configuraciones empresariales más controladas. Para la entrega específica en móviles, también necesitas herramientas para builds binarios, signing, automatización de releases en tiendas y distribución de assets/config en vivo. Esto es clave en stacks multiplataforma donde JavaScript, CSS, textos y assets estáticos pueden cambiar independientemente de los binarios nativos.
En cuanto a observabilidad, los equipos suelen combinar Datadog, Grafana, Prometheus, OpenTelemetry, Sentry, New Relic, y logging cloud-native. La clave no es la cantidad de herramientas, sino la correlación. Necesitas conectar errores del backend, crashes móviles, versiones de release, feature flags y eventos de despliegue en una sola línea de tiempo utilizable.
La calidad del workflow del desarrollador también importa. Un toolbox seleccionado cuidadosamente reduce errores de infraestructura porque los ingenieros pueden reproducir entornos, inspeccionar releases y entender fallos más rápido. Este resumen de herramientas de developer experience para equipos de apps modernos es útil si tu proceso de entrega aún depende de conocimiento tribal.
Para la instrumentación del cliente, la calidad de SDK importa porque el insight móvil solo es útil si respeta el rendimiento de la app y da a los equipos contexto accionable. Una referencia práctica es el SDK de Halo AI para insights móviles, especialmente para equipos que evalúan qué debe ejecutarse on-device y qué pertenece a la analítica del backend.
Gemelos digitales para staging en los que la gente puede confiar
La OCDE identifica los gemelos digitales como una forma prometedora de mejorar las decisiones y el engagement, pero advierte que deben reflejar las “realidades vividas” de las personas afectadas y construirse con transparencia en el informe de la OCDE sobre infraestructura inclusiva y gemelos digitales. En software, ese principio se aplica directamente al staging.
Un entorno de staging útil no es una copia reducida de producción con suposiciones falsas. Debe reflejar la topología de release, el comportamiento de la caché, los flujos de auth, el estado de los feature flags, los canales de actualización móvil y, al menos, los modos de fallo importantes. Si tu entorno de staging nunca incluye versiones antiguas de la app, dispositivos con recursos limitados o payloads de contenido realistas, no es un gemelo digital. Es un entorno de demo.
Lo que funciona es un staging transparente con huecos conocidos y explícitos. Documenta qué se replica y qué no. Incluye observabilidad similar a la de producción. Ensaya el rollback ahí. Prueba allí el comportamiento de live update. Un gemelo de staging no necesita ser perfecto, pero sí debe ser honesto.
Conclusión: tu roadmap de infraestructura y próximos pasos
La mayoría de los problemas de infraestructura no surgen por falta de esfuerzo. Surgen por tratar la planificación como un ejercicio de arquitectura inicial en lugar de una disciplina operativa. Las apps móviles críticas necesitan un plan que cubra infraestructura, mecánicas de release, observabilidad, recuperación y las realidades de dispositivos y redes que no controlas.
Un primer roadmap sencillo es suficiente para ganar tracción.
Mes 1: Define los user journeys críticos, el ownership de los servicios y los KPIs base. Documenta las rutas de release actuales para backend, binario, configuración y assets en vivo. Anota la ruta de rollback de cada una.
Mes 2: Estandariza un entorno con infraestructura como code. Añade monitorización por versión para los releases de backend y mobile. Configura reglas de canary o staged rollout. Revisa tus puntos únicos de fallo.
Mes 3: Haz un simulacro de recuperación. Restaura un backup en un entorno no productivo. Simula un rollout fallido. Verifica que soporte e ingeniería identifiquen las versiones afectadas y contengan el problema rápidamente.
Una buena planificación de infraestructura no elimina la complejidad. La sitúa donde el equipo puede gestionarla de forma segura.
Si la dirección necesita una visión más amplia de cómo la planificación técnica impulsa el crecimiento del negocio, esta guía de planificación estratégica de TI es el complemento ideal. Ayuda a conectar las decisiones de ingeniería con la disciplina del roadmap sin caer en lenguaje vago de transformación.
Los equipos que hacen deploy con confianza no son los que tienen el stack más llamativo. Son los que saben cómo se comporta su sistema, cómo falla y cómo se recuperan.
Si tu equipo mobile necesita una ruta de live update más segura para apps de CapacitorJS o Electron, Capgo te ofrece entrega de bundles firmados, canales de despliegue segmentados, protección contra rollback y observabilidad de releases para que corrijas problemas de JavaScript, CSS, configuración y assets sin esperar a la revisión de la app store.
