Mobile Architecture

Decisiones de un cliente bajo control de plataforma

Para el Atlas, Mobile Architecture organiza responsabilidades, estado, ejecución, fronteras e interacciones externas de un cliente móvil bajo lifecycle administrado por plataforma, recursos compartidos, conectividad variable y dependencias backend. Es una síntesis editorial, no una definición estandarizada ni un patrón único. kind: concept conserva ese alcance sin declarar un Architecture Profile completo del sistema.

El foco son aplicaciones instalables/nativas o ejecutadas mediante runtimes móviles cuyo entorno controla ejecución y capacidades. No absorbe automáticamente Mobile Web o responsive Web: rendering-strategies conserva decisiones Web de producción de representación. Una app móvil no es simplemente el frontend con pantalla pequeña; tampoco todas las aplicaciones sufren por igual cada restricción móvil.

Elegir framework, MVVM o una estructura de capas no responde qué ocurre al perder proceso, permiso o conexión. frontend-and-client-architecture conecta dimensiones diferentes. Esta nota establece preguntas del entorno, sin convertir Android, iOS, Clean Architecture, Offline First o Synchronization en sinónimos del concepto.

Lifecycle: el proceso no dura lo mismo que el workflow

La aplicación no controla toda su continuidad de ejecución. Android documenta prioridad y terminación de procesos según componentes y condiciones del sistema. El lifecycle de una Activity y el del proceso tampoco son idénticos: destruir una pantalla y perder toda memoria del proceso tienen consecuencias distintas.

En UIKit, Apple describe lifecycle de app y scenes, con transiciones entre foreground, background y suspensión, y posible desconexión de scenes para recuperar recursos. Scene, Activity y proceso no son nombres de una misma máquina de estados universal. Conservar la semántica de cada plataforma evita diseñar contra callbacks imaginarios comunes.

Un workflow puede atravesar pantallas, sesiones de ejecución y reinicios. Process death no equivale a logout ni a fallo remoto. Que desaparezca memoria no demuestra que una autorización enviada no ocurrió. La sesión autenticada puede continuar bajo sus propias reglas; permisos o identidad también pueden cambiar mientras la aplicación no observa.

Restaurar información con duración explícita

client-state-management proporciona ownership, scope y lifecycle. Aquí hay que decidir qué sobrevive a navegación, recreación de UI, proceso, logout o reinstalación. Una animación puede descartarse; dirección en edición, recurso seleccionado o contexto de una operación pendiente pueden necesitar reconstrucción. No corresponde persistir toda la memoria por defecto.

Android distingue ViewModel, saved state y persistencia: ViewModel no sobrevive por sí solo a process death. El ejemplo de restauración de Apple muestra continuidad de actividades del usuario entre lanzamientos. Son mecanismos y términos de sus plataformas, no garantías idénticas de durabilidad.

Al reiniciar, puede combinarse información persistida, fuente remota y contexto de entrada. Restaurar un carrito visible no confirma sus precios; recuperar un borrador no lo vuelve Customer aceptado. Revisar identidad, vigencia y autorización antes de reutilizarlo. Un singleton en memoria no es almacenamiento durable para información que deba sobrevivir terminación.

Background no significa ejecución ilimitada

Un thread de background no concede derecho a seguir ejecutando cuando la app deja foreground. Android recomienda WorkManager para trabajo persistente apropiado, con condiciones y ventanas de scheduling; no lo presenta como solución para todo trabajo inmediato. La política concreta depende del mecanismo y plataforma.

Apple diferencia estrategias de background: continuar trabajo acotado, transferir archivos o programar procesamiento y refresh tienen condiciones diferentes. En sus tareas diferidas el sistema participa en decidir cuándo ejecutar. No extrapolar una hora solicitada a ejecución exacta universal ni copiar límites temporales entre sistemas.

Refresh, transferencias, media o ubicación pueden justificar trabajo fuera de foreground bajo modos permitidos. Declarar necesidad, interrupción y recuperación; no desarrollar un catálogo de APIs. CPU, red y radio consumen energía: polling continuo innecesario puede competir con prioridades de plataforma. No hay intervalo mágico ni permiso implícito para ejecutar siempre.

Recursos, startup y trabajo útil

Memoria, CPU, batería, almacenamiento y red son recursos finitos y compartidos; eso no significa que todo teléfono sea débil. Presión de memoria puede eliminar estado volátil. Crecer caches indiscriminadamente o mantener tareas sin consumidores afecta más que una métrica: puede alterar continuidad y recuperación del cliente.

Startup puede restaurar contexto, preparar dependencias, consultar datos y resolver navegación. Inicializar todo antes de ofrecer algo útil puede aumentar espera; diferir trabajo puede reducir costo inicial y trasladar latencia o complejidad a la primera interacción. Comparar necesidades del recorrido, sin recomendar lazy initialization para todo.

Elegir cuánto descargar, retener y refrescar requiere evidencia de dispositivos y escenarios reales. GPS, networking y background tienen costos energéticos, sin reducir performance a batería. web-performance trata experiencias browser, incluida Web móvil; sus métricas no deben imponerse automáticamente a UI nativa. Este canonical conserva consecuencias arquitectónicas, no técnicas de tuning.

Conectividad observada y resultado de una operación

La conectividad puede ser buena, degradada, intermitente o ausente. Android distingue capacidades y validación de red; incluso observar acceso no garantiza que nuestro backend responda ahora. Pasar entre Wi-Fi y celular puede interrumpir conexiones. Una señal de red es evidencia parcial, no confirmación de una operación comercial.

La pantalla puede dejar de observar una petición que continúa; una transferencia gestionada por plataforma puede durar más que la View. Separar lifecycle de UI y lifecycle de operación cuando el caso lo necesita. execution-model aporta preguntas sobre activación y duración, sin prometer que un proceso cliente permanezca vivo.

En Commerce, Pay puede alcanzar Payments antes de perder conexión. Un timeout local y posterior background no autorizan declarar Failed. Conservar contexto suficiente para consultar el resultado autoritativo; idempotency ayuda a repetir solo cuando el contrato lo permite. Cerrar la app o cancelar observación no revierte un pago remoto.

Persistencia local y copias con autoridad delimitada

Memoria, preferencias, archivos, base local y almacenamiento protegido cubren necesidades diferentes. Elegir por duración, sensibilidad, volumen y consultas, no por una obligación de usar database. Una base local puede conservar borrador o cache consultable sin convertir la app en Offline First ni hacerla autoridad del negocio.

Una actualización puede encontrar datos escritos por una versión anterior. data-migration aporta preguntas de transformación; aquí su aplicación está acotada al dispositivo. Prever migración, invalidación o reset y qué información sería inaceptable perder. Reinstalación, reemplazo de dispositivo, backup y tipo de almacenamiento pueden cambiar qué sigue disponible; no asumir supervivencia universal.

data-ownership distingue copia administrada por el cliente de autoridad sobre pago, inventario u orden. offline-first desarrolla utilidad sin red inmediata; synchronization, intercambio y reconciliación entre copias que pueden divergir. El lifecycle móvil condiciona cuándo ese trabajo puede ejecutarse, sin definir su política de conflictos. Persistencia, cache-first, offline-capable y Local First no se vuelven equivalentes por almacenar datos; sus mecanismos no se desarrollan aquí.

Native, cross-platform e híbrido son otra dimensión

Esta comparación organiza decisiones del Atlas; no clasifica universalmente todos los productos ni puntúa frameworks.

Enfoque	Posible alcance	Trade-off por investigar
Native por plataforma	Integración directa con su runtime y ecosistema UI.	Implementaciones y skills específicos frente a capacidades particulares.
Cross-platform	Compartir lógica, acceso a datos o UI en grados distintos.	Reutilización frente a divergencias de plataforma y dependencias.
Híbrido/WebView	Contenido Web dentro de una aplicación con integración nativa.	Fronteras entre runtimes, capacidades, rendering y actualización.

Kotlin Multiplatform permite compartir lógica con UI nativa o compartir UI; Capacitor describe un runtime nativo para aplicaciones Web. Son ejemplos distintos: cross-platform no significa necesariamente Web envuelta. Flutter, React Native, MAUI y otros tampoco deben suponerse realizaciones de un mismo modelo de ejecución.

Compartir un core y usar adapters específicos puede ser razonable: ports-and-adapters ayuda cuando protege decisiones relevantes, sin imponerse como requisito móvil. Abstraer capacidades puede filtrar diferencias o limitarse al mínimo común. Código específico de plataforma no es fracaso arquitectónico. trade-off-analysis permite comparar acceso, UI, skills, costos y evolución sin escalera de madurez.

Capacidades, permisos y frontera de confianza

Cámara, ubicación, sensores, biometría, archivos o Bluetooth introducen dependencias del dispositivo. Aislar mecanismos cuando ayude a conservar política comprensible. Android documenta permisos y decisiones del usuario: acceso concedido no debe tratarse como condición inmutable. Denegación, revocación o indisponibilidad requieren una respuesta contextual.

Si no puede usarse cámara, Commerce puede permitir otra interacción en vez de declarar caída total. Acceso a contactos, fotos o ubicación debe responder a una necesidad y minimizar exposición. El cliente vive fuera del control completo del backend: validación local mejora UX, pero no reemplaza autorización y reglas comerciales protegidas.

No incrustar secretos duraderos de servidor suponiendo privado el binario; OWASP documenta su recuperación desde paquetes. Persistencia tampoco garantiza confidencialidad. Al cambiar de cuenta, conservar separación de caches y borradores entre identidades. Esto delimita confianza y lifecycle sin desarrollar una guía de autenticación o privacidad.

Distribución y versiones que siguen instaladas

Publicar puede requerir build, firma, distribución y actualización por usuario o dispositivo. deployment distingue lo publicado de la población instalada: una versión nueva no actualiza simultáneamente todas las copias. interfaces debe considerar clientes antiguos que todavía usan backend y representaciones persistidas de versiones previas.

parallel-change puede sostener una ventana compatible; deprecation y sunsetting distinguen desaconsejar y retirar contratos. Compatibilidad indefinida también cuesta. Exigir versión mínima es una política de producto y operación, no recomendación universal; evaluar usuarios afectados y recuperación cuando no pueden actualizar.

Capabilities pueden variar por versión cliente, OS, dispositivo o configuración remota. No deducirlas solo de que la aplicación arrancó. Un módulo lógico tampoco es una app instalable independiente: modularity permite separar responsabilidades sin replicar deployment. La composición Web de Micro Frontends no se traslada automáticamente a módulos nativos.

Adaptar backend sin resolver todo el cliente

backend-for-frontend puede adaptar payload, protocolos o interacción si Web y Mobile divergen. No es obligatorio por existir una app móvil. Muchas llamadas pequeñas pueden aumentar espera y actividad de red; una respuesta gigantesca puede desperdiciar memoria y transferencia. Evaluar recorrido y condiciones, sin número universal de requests.

El BFF no conserva automáticamente borradores, resuelve lifecycle ni otorga autoridad a caches cliente. unidirectional-data-flow organiza propagación de cambios; MVVM, MVC y MVP organizan presentación. Android recomienda capas, repositories y UDF en su guía de arquitectura; son recomendaciones Android, no definición universal. model-view-viewmodel y clean-architecture pueden combinarse con otras decisiones móviles.

Push, entradas externas y restauración

Push es un mecanismo mediado por plataforma para señales y notificaciones; no demuestra sincronización ni recepción inmediata, ordenada o exactamente una vez. Apple no garantiza entrega de sus background notifications y puede demorarlas. Esa semántica específica no define todos los tipos de push; correctness comercial no debe depender exclusivamente de su llegada.

«Your order shipped» puede notificar al usuario; al abrir, consultar estado autoritativo. Un deep link a Order 123 aporta intención y contexto, no todo el estado restaurado. Puede llegar con proceso frío: reconstruir navegación, comprobar sesión y acceso pertinentes, y cargar representación actual sin exigir el árbol UI anterior.

Launcher, notificación, URL, acción de compartir o evento de background introducen entradas diferentes según plataforma. No asumir un startup lineal único ni que entrada externa reproduce una sesión anterior. Mantener contexto de navegación separado de permiso para acceder al recurso y del hecho comercial representado.

Form factors, concurrencia y diagnóstico

Teléfonos, tablets, plegables y ventanas introducen tamaños y condiciones cambiantes. Android documenta aplicaciones adaptativas; su comportamiento de configuración y UI no se universaliza a iOS. Separar estado duradero de layout evita atar negocio a una orientación. accessibility conecta servicios de asistencia, entrada y escalado de texto de plataforma; internationalization examina preferencias y recursos localizados bajo versiones instaladas, sin tratar locale del dispositivo como autoridad comercial.

Interacciones, tareas, callbacks, red y persistencia pueden superponerse. Apple recomienda preservar capacidad de respuesta del main thread; sus reglas y mecanismos son específicos. Trabajo bloqueante no debería ocupar el camino crítico de interacción. Concurrencia de operaciones no desaparece por mostrar una pantalla ni por usar UDF.

operability necesita evidencia cliente además de logs servidor: estos no ven un crash previo a request, interacción offline o fallo local. Versión, OS y condiciones del dispositivo pueden orientar diagnóstico; telemetría puede ser incompleta y debe respetar privacidad. testability requiere probar lógica, adapters, persistencia y recorridos reales con variación de entorno, sin convertir esta nota en matriz de dispositivos.

Commerce: continuar sin inventar confirmaciones

El cliente conserva cart representado, catálogo cacheado, dirección en borrador y navegación. Al entrar checkout, pasar a background y perder proceso, debe decidir qué reconstruir. No recuperar objetos completos por suponer continuidad de memoria: conservar contexto necesario y revisar vigencia. Orders, Inventory y Payments siguen gobernando sus hechos comerciales.

Si Pay pudo procesarse antes de desconexión, reabrir puede mostrar estado desconocido o consultando. La cuenta y sesión deben interpretarse por sus reglas actuales; process death no es logout. Si después llega notificación de envío y abre Order 123, resolver acceso y cargar estado vigente, sin convertir el payload push en autoridad. Son ejemplos propios de decisiones, no un protocolo de sincronización.