Qué pasa cuando tu app se queda sin internet (y cómo seguir trabajando)

Se te va el WiFi. Estás llenando un formulario en tu app—llevas la mitad de los campos, cinco minutos invertidos. ¿Qué pasa?

Si tu app es solo-en-línea, la historia es esta: la página se recarga o se refresca. Tus datos desaparecen. Empiezas de nuevo. Cierras la app y no vuelves.

Si tu app es offline-first, la historia es otra: sigues escribiendo. Tus datos están a salvo. Cuando el WiFi regresa (tres minutos después, o tres días después), todo se sincroniza. Eso es diseño offline-first en una frase: la app sigue funcionando sin conexión a internet, guarda tus cambios localmente y los sincroniza en el momento en que vuelves a estar en línea.

La mayoría de los constructores de apps se saltan el modo offline porque es más simple de construir. Pero offline-first no es complicado—es deliberado. Es la diferencia entre una app a la que alguien vuelve y una que borra.

¿Qué pasa exactamente cuando tu app pierde internet?

Cuando tu app pierde internet, o sigue funcionando o no—no hay término medio. Y perder la conexión no es raro: un usuario en un vuelo no tiene internet, un usuario en un túnel no tiene señal, un usuario en un salón de eventos rural tiene cobertura intermitente, un usuario cuyo router se reinicia a las 3am se queda atascado con WiFi muerto, un usuario conectado por hotspot de su celular llega al límite de sus datos.

En todos esos casos, tu app funciona o no funciona.

Construimos una app de control de horas para freelancers. Se caía sin conexión. Un freelancer (que la usaba en obras de construcción sin señal) dejó de usarla—volvió a lápiz y papel porque al menos el lápiz funciona en cualquier lugar. Tres meses después, cuando agregamos un modo offline, regresó y nunca más se fue.

La mecánica es sencilla: guardar el trabajo localmente cuando no hay internet, sincronizarlo cuando vuelve la conexión. Eso es todo.

¿Cuáles son los diferentes tipos de offline?

Hay tres tipos de offline para los que debes planear: intencional, sorpresivo y lento—y cada uno necesita una solución distinta.

Offline intencional — El usuario eligió trabajar sin conexión. Está en un avión o sabe que el WiFi es malo. Espera sincronizar después. Es el más simple de construir: solo guarda borradores localmente y los envía cuando vuelve la conexión.

Offline sorpresivo — El internet se cayó sin avisar. El usuario estaba en medio de algo. Si lo dejas a la mitad de una frase, se enoja. La solución es la misma (guardar borradores localmente), pero el trato es más amable: muéstrale que la app sigue funcionando, y avísale cuando vuelva a estar en línea.

Offline lento — La conexión está ahí, pero es tan lenta que da lo mismo que no exista. Un cliente llena un formulario, hace clic en enviar y luego espera 20 segundos a que termine el envío. Para entonces, cree que algo se rompió y hace clic en enviar otra vez (y ahora tienes un duplicado). Este es el más difícil de probar, pero la solución es honesta: muéstrale que algo está pasando (un spinner), o déjalo navegar a otra pantalla sin perder el borrador.

¿Cómo le pides a tu builder el modo offline?

Se pide por partes, no como una sola funcionalidad grande—offline-first es una filosofía de diseño, no una casilla que se marca. Aquí tienes cinco pedidos concretos que puedes llevarle a tu builder:

Guardar borradores localmente: “Cuando alguien llena un formulario o una nota, guárdalo en su celular/navegador. Si refresca la página, el formulario debe seguir lleno.” Pruébalo: llena algo, cierra la pestaña del navegador, vuelve a abrirla, y el formulario sigue ahí.
Trabajar sin conexión: “Si no hay internet, la app debe mostrar los datos que ya tenemos, dejar que el usuario los lea y haga cambios, y poner en cola esos cambios para sincronizarlos cuando vuelva el internet.” Pruébalo: apaga tu WiFi, intenta hacer algo útil, luego vuelve a encender el WiFi y observa cómo se sincronizan los datos.
Sincronizar en silencio: “Cuando estemos sincronizando cambios, no muestres un cuadro de diálogo grande. Muestra un indicador pequeño, como ‘Guardando…’ arriba, que desaparece cuando termina. Si falla el guardado, conserva el cambio localmente e inténtalo de nuevo después.”
Mostrar la verdad: “Dile al usuario qué datos están frescos (recién sincronizados del servidor) y cuáles son solo locales (aún no sincronizados). Usa un indicador o etiqueta pequeña—no lo hagas alarmante, solo honesto.”
Un flujo, primero local: “Lo principal que el usuario viene a hacer (revisar una reserva, escribir una nota, registrar horas) debe funcionar sin conexión. Los extras (buscar en todo el historial, traer precios en tiempo real) sí pueden requerir internet.”

Historias reales

La organizadora de bodas construyó una app para gestionar confirmaciones de asistencia. Imprimía la lista, caminaba por los eventos y marcaba las respuestas. Pero el WiFi en los salones es pésimo. Pidió offline-first: guardar la lista localmente, sincronizar al llegar a casa. Ahora es su herramienta principal—aunque tenga señal en el celular, la app funciona sin esperar a que carguen los datos. Le encanta.

La maestra de salón de clases usaba una app para dar seguimiento al progreso de sus alumnos. Perdía ediciones constantemente al moverse entre salones con cobertura irregular. El modo offline significó que podía trabajar libremente, sincronizar después, y no tener que elegir entre su celular y su trabajo. Un solo cambio, un enorme salto de confianza.

El ajustador de seguros llenaba reportes de daños en el sitio (sin señal en algunas zonas rurales). La app original necesitaba internet para enviar. Le agregamos borradores offline. Ahora llena el formulario, lo envía sin conexión, y la sincronización ocurre mientras maneja de regreso. Se acabó el “no puedo enviar nada hasta que llegue a casa.”

Los tres casos se podrían haber resuelto con “consigue mejor WiFi,” pero así no funciona el mundo real. Offline-first fue un cambio de confianza mucho más grande que una mejor sincronización.

¿El offline-first hace tu app más rápida?

Sí—las apps offline-first se sienten más rápidas porque no esperas al servidor. Escribes, la app guarda localmente (al instante) y sincroniza en segundo plano. Sin spinner, sin espera. Incluso con internet, la experiencia es más ágil porque el servidor no estorba.

Una app solo-en-línea tiene que esperar a que el servidor confirme cada cambio. Una tecla presionada → solicitud de red → validación del servidor → respuesta → se muestra al usuario. Normalmente eso está bien, pero en redes lentas (o en móvil con un servidor lento), cada interacción se traba.

¿Cuánto cuesta construir offline-first?

Offline-first cuesta tiempo de ingeniería por adelantado. Tu builder necesita pensar en:

Almacenamiento local: cómo guardar datos en el celular/navegador para que no desaparezcan si la app se cae. No es difícil, pero tiene que ser deliberado.
Resolución de conflictos: si el usuario cambia un campo sin conexión y luego alguien más (u otro dispositivo) cambia ese mismo campo antes de sincronizar, ¿cuál gana? Normalmente gana el que está en línea (es el más reciente), pero al usuario hay que avisarle, no sorprenderlo. Ejemplo real: dos celulares editan la misma nota sin conexión, ambos vuelven a estar en línea—el segundo en sincronizar gana, y el primer usuario ve “Tu versión era anterior, aquí está la actual.”
Datos desactualizados: si el usuario estuvo sin conexión durante tres días, ¿debe la app refrescar todo en silencio al reconectarse, o preguntarle primero? Preguntar es más seguro—los datos viejos podrían tener cambios sin guardar asociados.

Pensar en esto no sale gratis, pero es más simple de lo que imaginas.

La recompensa: apps en las que la gente confía. Una app offline-first no pone pretextos (“necesitas internet para usar esto”) y no pierde tu trabajo. Eso es enorme.

¿Cómo pruebas si tu app funciona sin conexión?

No necesitas subirte a un avión para probarlo—el modo avión de tu celular es tu campo de pruebas. Así se hace:

Abre y llena algo: haz algo normal (llena un formulario, agrega una nota).
Ponte sin conexión: activa el modo avión o apaga el WiFi.
Sigue trabajando: intenta hacer lo mismo otra vez. Si la app se niega, offline-first no está implementado. Si la app funciona, bien. Si es confuso, pídele a tu builder un indicador claro de “Estás sin conexión.”
Vuelve a estar en línea: apaga el modo avión.
Revisa la sincronización: ¿tus cambios se sincronizaron automáticamente? Si tuviste que hacer clic en un botón de “sincronizar” o refrescar, todavía no está del todo listo.

Las mejores apps offline se sienten tan normales que no notas que están sin conexión—solo notas que la app sigue funcionando.

¿La app que construiste realmente necesita funcionar sin conexión? Si la respuesta es “mis usuarios tienen internet intermitente, o trabajan en lugares sin señal,” entonces sí. Si es “siempre están en un WiFi estable,” puedes saltártelo por ahora. Pero en el momento en que alguien diga “perdí mi trabajo,” desearás haberlo pedido antes.