Wat er gebeurt als je app geen internet meer heeft (en hoe je kunt blijven werken)

Je WiFi valt uit. Je bent een formulier aan het invullen in je app — de helft van de velden is ingevuld, je bent hier al vijf minuten mee bezig. Wat gebeurt er?

Als je app alleen online werkt, is dit het verhaal: de pagina herlaadt of ververst. Je gegevens verdwijnen. Je begint opnieuw. Je sluit de app, en je komt nooit meer terug.

Als je app offline-first is, is het verhaal anders: je blijft typen. Je gegevens zijn veilig. Zodra de WiFi terug is (drie minuten later, of drie dagen later), synchroniseert alles. Dat is offline-first design in één zin: de app blijft werken zonder internetverbinding, slaat je wijzigingen lokaal op en synchroniseert ze zodra je weer online bent.

De meeste app builders slaan offline over omdat het simpeler is om te bouwen. Maar offline-first is niet ingewikkeld — het is bewust. Het is het verschil tussen een app waar iemand naar teruggrijpt en een app die ze verwijderen.

Wat gebeurt er precies als je app geen internet meer heeft?

Als je app geen internet meer heeft, blijft hij werken of niet — er is geen tussenweg. En verbindingsverlies is niet zeldzaam: een gebruiker in een vliegtuig heeft geen internet, een gebruiker in een tunnel heeft geen signaal, een gebruiker op een landelijke evenementenlocatie heeft wisselvallige dekking, een gebruiker wiens thuisrouter om 3 uur ‘s nachts herstart zit vast met dode WiFi, een gebruiker die getetherd is aan zijn telefoon bereikt zijn hotspotlimiet.

In al die gevallen werkt je app óf óf niet.

We bouwden een tijdregistratie-app voor freelancers. Die crashte offline. Eén freelancer (die de app gebruikte op bouwplaatsen zonder signaal) stopte met de app — die schakelde over op potlood en papier, want potlood werkt in ieder geval overal. Drie maanden later, na een offline-modus, kwam die terug en is nooit meer weggegaan.

De mechaniek is eenvoudig: werk lokaal opslaan als het internet eruit ligt, synchroniseren zodra de verbinding terugkomt. Dat is het hele verhaal.

Wat zijn de verschillende soorten offline?

Er zijn drie soorten offline waar je rekening mee moet houden: bewust, verrast en langzaam — en elk daarvan heeft een andere oplossing nodig.

Bewust offline — De gebruiker koos ervoor om offline te werken. Ze zitten in een vliegtuig of weten dat de WiFi slecht is. Ze verwachten later te synchroniseren. Het eenvoudigst te bouwen: sla concepten gewoon lokaal op en push ze zodra de verbinding terugkomt.

Verrast offline — Het internet viel onverwacht uit. De gebruiker was midden in iets bezig. Als je ze halverwege een zin afsnijdt, zijn ze boos. De oplossing is hetzelfde (concepten lokaal opslaan), maar de UX is vriendelijker: laat zien dat de app blijft werken, en vertel wanneer ze weer online zijn.

Langzaam offline — De verbinding is er wel, maar zo traag dat het net zo goed weg kan zijn. Een klant vult een formulier in, klikt op verzenden en wacht dan 20 seconden tot de inzending klaar is. Tegen die tijd denken ze dat er iets kapot is, en klikken ze nog een keer op verzenden (nu krijg je een dubbele inzending). Dit is de lastigste om te testen, maar de oplossing is eerlijk: laat zien dat er iets gebeurt (een spinner), of laat ze wegnavigeren zonder het concept te verliezen.

Hoe vraag je je builder om een offline-modus?

Je vraagt erom in stukjes, niet als één grote functie — offline-first is een designfilosofie, geen los vinkje. Hier zijn vijf concrete verzoeken die je bij je builder kunt neerleggen:

Concepten lokaal opslaan: “Als iemand een formulier of notitie invult, sla dat op op hun telefoon/browser. Als ze de pagina verversen, moet het formulier nog steeds ingevuld zijn.” Test het: vul iets in, sluit het browsertabblad, open het opnieuw, en het formulier staat er nog.
Offline werken: “Als er geen internet is, moet de app laten zien welke gegevens we hebben, de gebruiker laten lezen en wijzigingen laten maken, en de wijzigingen in de wachtrij zetten om te synchroniseren zodra het internet terugkomt.” Test het: zet je WiFi uit, probeer iets nuttigs te doen, zet de WiFi weer aan en kijk hoe de gegevens synchroniseren.
Stil synchroniseren: “Toon geen groot dialoogvenster als we wijzigingen aan het synchroniseren zijn. Toon een kleine indicator, zoals ‘Bezig met opslaan…’ bovenaan, die verdwijnt zodra het klaar is. Als opslaan mislukt, houd de wijziging dan lokaal en probeer het later opnieuw.”
Laat de waarheid zien: “Vertel de gebruiker welke gegevens vers zijn (net gesynchroniseerd met de server) en welke gegevens alleen lokaal zijn (nog niet gesynchroniseerd). Gebruik een kleine indicator of label — maak het niet eng, gewoon eerlijk.”
Eén workflow, lokaal eerst: “Het kernonderdeel waarvoor de gebruiker de app opent (een boeking bekijken, een notitie schrijven, tijd bijhouden) moet offline werken. Extraatjes (in alle oude records zoeken, live prijzen ophalen) mogen internet vereisen.”

Verhalen uit de praktijk

De trouwplanner bouwde een app om RSVP’s te beheren. Ze printte de lijst, liep rond op evenementen en vinkte reacties af. Maar de WiFi op locaties is vaak beroerd. Ze vroeg om offline-first: sla de checklist lokaal op, synchroniseer zodra ze thuiskomt. Nu is het haar belangrijkste hulpmiddel — ook al heeft ze telefoonsignaal, de app werkt zonder te wachten op data. Ze is er dol op.

De klasleraar gebruikte een app om de voortgang van leerlingen bij te houden. Verloor steeds wijzigingen bij het wisselen tussen lokalen met wisselvallige dekking. De offline-modus betekende dat ze vrij kon werken, later kon synchroniseren, en niet hoefde te kiezen tussen haar telefoon en haar werk. Eén verandering, enorme vertrouwensboost.

De schade-expert vulde schaderapporten in ter plekke (geen signaal in sommige landelijke gebieden). De oorspronkelijke app vereiste internet om in te dienen. We voegden offline-concepten toe. Nu vult hij het formulier in, dient hij het offline in, en synchronisatie gebeurt terwijl hij terugrijdt. Geen “ik kan pas iets indienen als ik thuis ben” meer.

Alle drie hadden opgelost kunnen worden met “zorg gewoon voor betere WiFi”, maar zo werkt de echte wereld niet. Offline-first was een grotere vertrouwensverschuiving dan betere synchronisatie.

Maakt offline-first je app sneller?

Ja — offline-first apps voelen sneller aan omdat je niet op de server hoeft te wachten. Je typt, de app slaat lokaal op (direct) en synchroniseert op de achtergrond. Geen spinner, geen wachten. Zelfs met internet is de ervaring vlotter, omdat de server niet in de weg zit.

Een app die alleen online werkt moet wachten tot de server elke wijziging bevestigt. Een toetsaanslag → netwerkverzoek → servervalidatie → antwoord → tonen aan gebruiker. Dat gaat normaal gesproken prima, maar op trage netwerken (of mobiel met een trage server) hapert elke interactie.

Wat kost het om offline-first te bouwen?

Offline-first kost vooraf ontwikkeltijd. Je builder moet nadenken over:

Lokale opslag: hoe gegevens op de telefoon/browser worden opgeslagen zodat ze niet verdwijnen als de app crasht. Niet moeilijk, maar het moet bewust gebeuren.
Conflictoplossing: als de gebruiker offline een veld wijzigt, en daarna wijzigt iemand anders (of een ander apparaat) datzelfde veld vóór de synchronisatie, wie wint dan? Meestal de online versie (die is verser), maar de gebruiker moet gewaarschuwd worden, niet verrast. Praktijkvoorbeeld: twee telefoons bewerken offline dezelfde notitie, beide komen online — de tweede die synchroniseert wint, de eerste gebruiker ziet “Jouw versie was ouder, hier is de huidige.”
Verouderde gegevens: als de gebruiker drie dagen offline was, moet de app dan alles stilzwijgend verversen zodra ze weer verbinding hebben, of eerst vragen? Vragen is veiliger — oude gegevens kunnen nog niet-opgeslagen wijzigingen bevatten.

Dit vergt wel nadenken, maar het is eenvoudiger dan je zou denken.

De opbrengst: apps die mensen vertrouwen. Een offline-first app verzint geen smoesjes (“je hebt internet nodig om dit te gebruiken”) en verliest je werk niet. Dat is enorm.

Hoe test je of je app offline werkt?

Je hoeft niet in een vliegtuig te stappen om het te testen — vliegtuigmodus op je telefoon is je testterrein. Zo doe je het:

Open en vul iets in: doe iets normaals (vul een formulier in, voeg een notitie toe).
Ga offline: zet vliegtuigmodus aan of zet WiFi uit.
Blijf werken: probeer hetzelfde nog een keer te doen. Als de app weigert, is offline-first er nog niet. Als de app werkt, goed. Als het verwarrend is, vraag je builder om een duidelijke “Je bent offline”-indicator.
Kom weer online: zet vliegtuigmodus uit.
Controleer de synchronisatie: zijn je wijzigingen automatisch gesynchroniseerd? Als je op een “synchroniseer”-knop moest klikken of moest verversen, is het nog niet helemaal in orde.

De beste offline-apps voelen zo normaal aan dat je niet doorhebt dat ze offline zijn — je merkt alleen dat de app blijft werken.

Moet de app die jij hebt gebouwd echt offline werken? Als het antwoord is “mijn gebruikers hebben wisselvallig internet, of ze werken op plekken zonder signaal”, dan ja. Als het antwoord is “ze zitten altijd op een stabiele WiFi”, dan kun je het voorlopig overslaan. Maar op het moment dat iemand zegt “ik ben mijn werk kwijt”, had je willen dat je erom had gevraagd voordat het te laat was.