Mobile-App — el entorno más hostil en el que va a correr tu código

Overview

Un teléfono es un entorno hostil: red intermitente, batería limitada, el sistema mata tu proceso cuando quiere, la pantalla es chica, los permisos los concede (o niega) el usuario, y el paquete que publicas es leíble por cualquiera. Además, publicar tiene reglas de terceros con fechas límite: versiones mínimas del sistema, formatos de empaquetado, declaraciones de privacidad, requisitos técnicos que cambian cada año.

Lo que en web es un ajuste rápido, aquí es una versión nueva que la gente puede no instalar nunca.

Cuándo usar

• Construir o ampliar una aplicación móvil, nativa o híbrida.
• Generar, firmar o publicar un paquete.
• Permisos, notificaciones, almacenamiento local, trabajo sin conexión.
• Preparar una publicación en tienda o una distribución directa.

Cuándo NO usar

Diseño visual

Toda pantalla nueva o rediseñada aplica ui-design antes de darse por terminada: tokens de tipografía, espaciado y color definidos primero, cero emojis, un solo set de iconos SVG, y verificación con capturas en un teléfono chico y uno grande. Una interfaz que funciona pero parece plantilla generada por IA no está lista.

Regla de hierro: el paquete es público

TODO LO QUE VIAJA DENTRO DEL APK/IPA ES LEIBLE: CLAVES, ENDPOINTS, LOGICA, TEXTOS. NINGUN SECRETO VIVE AHI.

Cualquiera puede descomprimir el paquete y leerlo. Las claves de servicios de pago, bases de datos o APIs privilegiadas viven en tu servidor; la app solo habla con tu servidor. Las validaciones de negocio que importan se hacen del lado del servidor: la app se puede modificar.

Decisiones tempranas

Antes de empezar a construir, verifica los requisitos vigentes de la tienda (versión mínima del sistema objetivo, formato de publicación, requisitos técnicos del empaquetado, declaración de datos y privacidad) y sus fechas límite. Cambian todos los años y bloquean publicaciones sin aviso útil.

Construcción

Ciclo de vida y recursos

• El sistema puede suspender o matar la app en cualquier momento: guarda el estado, restaura al volver.
• Nada de trabajo pesado en el hilo principal; una interfaz que traba se siente rota.
• Cuidar batería y datos: nada de sondeos constantes, de ubicación continua sin motivo ni de descargas en red móvil sin avisar.
• Probar en gama baja, no solo en el mejor teléfono disponible.

Red intermitente

• Asume caída en mitad de la petición: tiempos límite, reintentos con retardo creciente, mensajes claros.
• Diferencia "sin conexión" de "el servidor falló": el usuario necesita saber si esperar o reintentar.
• Cola de acciones pendientes si la app permite crear datos sin conexión, con sincronización idempotente.

Permisos

• Pedir en el momento en que se usan, explicando para qué, no todos al abrir.
• Funcionar de forma degradada si el usuario niega; nunca bloquear la app entera.
• Pedir el mínimo: cada permiso sensible es fricción, riesgo de rechazo en tienda y desconfianza.

Almacenamiento

• Datos sensibles en el almacén cifrado del sistema, no en preferencias planas ni en archivos sueltos.
• Base local con migraciones versionadas y probadas desde la versión publicada anterior.
• Limitar el crecimiento de cachés: llenar el teléfono es motivo de desinstalación.

Interfaz

• Área segura, teclado que tapa campos, rotación, texto grande por accesibilidad, modo oscuro si el sistema lo pide.
• Áreas táctiles cómodas; navegación con el botón atrás coherente.
• Estados de carga/vacío/error en cada pantalla que trae datos.

Publicación

Gate específico de móvil

Anti-racionalización

Formato de salida

• Plataformas y versiones mínimas soportadas.
• Permisos solicitados y justificación de cada uno.
• Comportamiento sin conexión y estrategia de sincronización.
• Resultado del gate, incluido el escaneo de secretos sobre el paquete final.
• Estado de firma, respaldo de la clave y plan de publicación.
• Requisitos de tienda verificados con fecha de verificación.