Je oude app vernieuwen

Misschien zit je huidige app vol met spaghetticode en bugs of worden fundamentele tools en frameworks, waarmee de app gemaakt is, niet meer ondersteund. Of je wilt gewoon echt die nieuwe frisse start.

Wat de reden ook is, tijd voor een geheel vernieuwde app. Top, the sky is the limit!
Maar, kan dat wel? Hoe zit het dan met alle bestaande gebruikers? Die wil je niet kwijt!
Dat snappen wij als geen ander, dus al die gebruikers gaan “gewoon” automatisch over naar je nieuwe app.

Misschien klinkt dat nog een beetje te mooi om waar te zijn, maar wij houden wel van een uitdaging. Samen met Reinigingsdiensten Rd4 zijn we precies die uitdaging aangegaan: van de oude Milieu App naar de nieuwe Rd4-app. Dus hoe hebben we de Milieu App met ruim 200.000 gebruikers compleet vernieuwd? Dat leggen we je stap-voor-stap uit.

Stap 1: de kaders

Voordat je begint aan een vernieuwing van je app is het belangrijk om de kaders te bepalen. En in het geval van Rd4 waren deze kaders super helder:

• Welke functionaliteiten zitten er in de oude app en welke komen er in de nieuwe?

De nieuwe app wordt een verbeterde versie van de oude met op hoofdlijnen dezelfde functionaliteiten. 

• Wat zijn de belangrijkste verschillen tussen de oude en de nieuwe app?

De app moet stabiel en toekomstbestendig worden.

• Maakt je app gebruik van een eigen API en moet deze ook vernieuwd worden?

Ja en alle eigen API’s moeten samen met de app vernieuwd worden.

• Hoe willen we dat gebruikers de overgang ervaren?

Gebruikers mogen geen last hebben van deze (technische) vernieuwing.

• Wat is de deadline en hoeveel mag het kosten?

Er is geen harde deadline en ook geen vast budget.
 

De aanpak was daarmee ook super duidelijk en in één woord te beschrijven: app-update. De nieuwe app (en API) moest voor gebruikers aanvoelen als een “normale” update van de oude app. Geen gedoe met een nieuwe app downloaden of een onbruikbare oude app, gewoon een update.

Stap 2: een nieuwe API

Met de heldere kaders en functionele scope starten we met de vernieuwing van de API. De API is voor veel apps namelijk de basis die bepaalt wat er wel en niet mogelijk is, welke data er wel en niet getoond kan worden en hoe die data eruitziet.

Tijdens de ontwikkeling van een (nieuwe) API kijken we goed naar alle data, wat die betekent en hoe we die logisch kunnen opslaan:

• Is het maken van een dumpafval melding een hele specifieke functionaliteit of enkel een voorbeeld?

Als je gedumpt afval tegenkomt dan kun je dit als gebruiker melden via de app. Je geeft de locatie en een foto door en dan zorgt Rd4 dat het afval wordt opgeruimd. Dat klinkt in eerste instantie natuurlijk als een zeer specifieke functionaliteit.
Maar als je er iets langer over nadenkt, is dat niet per se het geval. Je zou in de toekomst namelijk op een vergelijkbare manier melding kunnen maken van een defecte ondergrondse container. In beide gevallen maak je een soort support ticket aan, gaat Rd4 daarmee aan de slag en ontvang je daarna een (status) update. Door de dumpafval meldingen functionaliteit meteen abstracter te ontwikkelen kunnen we in de toekomst eenvoudig meer soortgelijke functionaliteiten toevoegen.

• Zijn alle afval aanbiedingen hetzelfde en wat zouden we willen weten van een aanbieding?

Je kunt als inwoner afval op verschillende manier aanbieden, via je eigen container, bij een ondergrondse container, bij het grondstoffenpark of simpelweg door het aan de straat te zetten. Voor de gebruiker is dit in veel gevallen gewoon een aanbieding van een bepaald soort afval. Maar er zit weldegelijk verschil in deze soorten aanbiedingen. Bij het grondstoffenpark kun je bijvoorbeeld meerdere soorten afval tegelijk aanbieden en bij een ondergrondse container rekenen we met volume i.p.v. met gewicht. Voor een lijst van aanbiedingen is dat niet super interessant maar wel als je (later) meer inzicht wilt krijgen in je aanbiedingen.

• Hoe zouden we de afvalkalender informatie (in de toekomst) willen gebruiken?

Elk adres heeft zijn eigen afvalkalender. Gebruikers willen die vaak per maand of jaar bekijken in een kalenderoverzicht.
Maar het is bijvoorbeeld ook handig om te weten wat het eerstvolgende ophaalmoment is of welk afval er vandaag wordt opgehaald. We moeten dus niet alleen de hele kalender makkelijk kunnen ophalen maar ook de losse momenten.
 

Het is natuurlijk altijd belangrijk om goed na te denken over je data en hoe je bepaalde functionaliteiten gaat ontwikkelen. Maar bij het vernieuwen van een applicatie moet je rekening houden met zowel de nieuwe als de oude app. Hierbij is het belangrijk om de oude app zo veel mogelijk los te laten en echt naar de ideale opzet toe te werken. Kun je de oude app dan helemaal negeren? Nee, want we willen immers ook de oude app blijven ondersteunen.

Als het gaat om de oude app dan kijk je bij de ontwikkeling van de nieuwe API vooral naar mogelijkheden. Je zorgt er dus bijvoorbeeld voor dat je alle data hebt om een bepaalde functionaliteit te kunnen ondersteunen. Hoe je die functionaliteit dan maakt in je nieuwe API staat helemaal los van je oude app.

Stap 3: de compatibility API

Oké, maar als we die nieuwe API dan hebben dan kan de oude app daar dus helemaal niet mee praten? Precies! Zodra (een deel van) je nieuwe API compleet is gaan we aan de slag met de compatibility API.

De compatibility API is een klein laagje over je nieuwe API heen. Met deze laag vertalen we de aanvragen vanuit je oude app zodat de nieuwe API hiermee overweg kan. Deze laag fungeert dus eigenlijk als een tolk.

Hoe de compatibility API met de oude app moet gaan communiceren staat al vast, want die oude app kunnen we niet meer aanpassen, die wordt immers al door duizenden gebruikers gebruikt. Dus nu gaan we per functionaliteit kijken hoe we die zo goed mogelijk in de oude app kunnen ondersteunen. En dat kan globaal op 3 manieren:

• Door de functionaliteit te vertalen naar een functionaliteit in de nieuwe app/API.

Denk hierbij bijvoorbeeld aan een nieuws functionaliteit die in zowel de oude als nieuwe app aanwezig is.

• Door vaste waarden of logica te gebruiken in de compatibility API.

Bijvoorbeeld voor tekstuele pagina’s die in je nieuwe app niet meer bestaan.

• Door de functionaliteit niet beschikbaar te maken in de oude app.

De nieuwe berichten inbox, die is dus echt alleen beschikbaar in de nieuwe app.
 

De grootste uitdaging zit hem in het vertalen van de functionaliteiten, neem bijvoorbeeld de nieuws functionaliteit in de Rd4-app. In de nieuwe app kan Rd4 algemene nieuwsberichten plaatsen maar ook persoonlijke nieuwsberichten voor specifieke adressen.

Stel de vuilniswagen heeft pech en ze komen niet vandaag maar morgen je afval ophalen, dan wil je zo’n bericht natuurlijk alleen naar de getroffen adressen sturen. Dat is dus een persoonlijk bericht in de nieuwe app, alleen zichtbaar voor die specifieke adressen. Maar in het geval van de oude app weten we niet voor welk adres we een nieuwsoverzicht moeten ophalen. De informatie die de oude app naar de (compatibility) API stuurt bevat simpelweg niet de juiste informatie om het adres te bepalen.

Voor zulke gevallen bepalen we samen wat het gewenste resultaat is voor de oude app. In dit geval hebben we ervoor gekozen om alle persoonlijke berichten op te nemen in het nieuwsoverzicht met een korte disclaimer in de tekst. Gebruikers in de oude app zien daarmee alle persoonlijke berichten. Niet optimaal maar beter dan het niet kunnen zien van deze belangrijke berichten. Is het persoonlijke bericht echt voor jouw adres bedoeld? Dan krijg jij een push notificatie van dat bericht, zo ben je altijd op de hoogte van de belangrijke informatie rondom je afvalinzameling.

Stap 4: een nieuwe app

De nieuwe app, daar is het natuurlijk allemaal om te doen. Eigenlijk een vrij normaal ontwikkeltraject maar dan wel met de bijzondere update flow erbij. Want alle bestaande gebruikers moeten zonder veel moeite in de nieuwe app komen.

Voor de Rd4 app-update flow zijn we uitgekomen op een semi-geautomatiseerde onboarding. De update moest soepel en zonder veel moeite verlopen, maar we wilden gebruikers tegelijkertijd wel ondersteunen in de overgang naar de nieuwe app.

Concreet kom je als gebruiker binnen op de “welkom in de nieuwe app” pagina met een automatische login-actie. Door de informatie uit de oude app te gebruiken kunnen we de gebruiker automatisch inloggen in de nieuwe app. Wel zo fijn, dan hoef je namelijk niet zelf je postcode, huisnummer en milieupasnummer in te vullen (want wat was dat nummer ook alweer?!). Lukt het automatisch inloggen niet? Of was je nog niet ingelogd met een milieupasnummer? Dan vragen we alleen naar de ontbrekende informatie.

In 99% van de gevallen is een gebruiker dus met 1 druk op de knop ingelogd in de nieuwe app. Vervolgens laten we deze gebruiker wel nog even door de overige onboarding stappen heen gaan zodat we zeker weten dat alle instellingen nog naar wens zijn. Maar ook hier zorgen we ervoor dat al je bestaande instellingen al vooraf ingevuld zijn. Staat alles al goed? Dan zit je in 3 klikken op het dashboard van de nieuwe app.

Je oude app gegevens gerecycled naar een compleet vernieuwde app. Helemaal volgens de filosofie van Rd4!

Stap 5: testen, testen, testen

Oké, door naar de volgende stap: testen. We kunnen het niet vaak genoeg zeggen. Testen is altijd belangrijk, maar helemaal bij het vernieuwen van je app. Je krijgt namelijk maar 1 kans om je gebruikers zonder problemen over te zetten naar een nieuwe app. Eén probleem, hoe klein ook, kan de migratie flow van duizenden gebruikers permanent verstoren.

Bij de vernieuwing van de Milieu App hebben we in het bijzonder 2 testmethodes gebruikt die cruciaal zijn geweest voor de soepele overgang naar de nieuwe app:

• Automated endpoint tests

Alle endpoints van zowel de nieuwe als de compatibility API worden automatisch getest op basis van de gedefinieerde afspraken met de oude en nieuwe apps. Aangezien de meeste logica in de API gedeeld is tussen de nieuwe API en de compatibility laag is het extra belangrijk dat we aanpassingen valideren. Het contract met de oude app staat immers vast.

• De regressietest dag

We ontwikkelen compleet nieuwe applicaties, maar de oude app moet hoe dan ook blijven werken zoals voorheen.
Door samen met diverse testers van Rd4 de volledige update flow van A tot Z zorgvuldig te testen hebben we allemaal met een goed gevoel kunnen starten aan de daadwerkelijke migraties en updates.
 

Nice to know:

Door onze eigen generale repetitie van de regressietest dag hebben we nog een belangrijke bug kunnen fixen die er anders voor had gezorgd dat alle gebruikers opnieuw hadden moeten inloggen. De oorzaak? We maakten in de nieuwe API gebruik van een andere identifier voor een adres. Test de oude app met de nieuwe API en alles gaat goed, maar zet bestaande installaties over en de identifiers komen niet meer overeen.

Stap 6: de API switch

Nu we zowel de API als de app vernieuwd en getest hebben is het tijd om te starten met de migratie. Als eerste hebben we de oude API door de nieuwe vervangen zodat de oude app gebruik maakt van de nieuwe (compatibility) API.

Daarvoor hebben we wel nog de gegevens van alle gebruikers nodig. Dus in de weken voor de API switch hebben we eerst in stappen een grote hoeveelheid data geëxporteerd uit de oude database en vervolgens in de nieuwe database geïmporteerd. Door middel van export en import scripts zijn alle gegevens uit de oude database vertaald naar de nieuwe datastructuur en in de nieuwe database geïmporteerd.

De export/import van de gegevens hebben we met opzet in “kleine” stappen gedaan. Door te beginnen met de grote hoeveelheid historische data en vervolgens elke paar dagen alleen nog aanpassingen over te zetten, hadden we het meeste werk al gehad voordat we begonnen aan de daadwerkelijke switch van de API. Hierdoor duurde het op de migratie dag nog geen 30 minuten om de nieuwe database up-to-date te krijgen met alle gebruikersgegevens.

Met alle data in de nieuwe database was het tijd voor de switch. Achtergrond processen werden uitgeschakeld en de DNS werd aangepast. Een paar klikken en alle API aanvragen van de oude app werden naar de nieuwe API gestuurd. Magisch, niet?

Als laatste stap hebben we nogmaals een export en import van de data uitgevoerd om ook de laatste aanpassingen in de nieuwe omgeving te krijgen. Met alle data in de nieuwe omgeving zijn vervolgens met terugwerkende kracht alle achtergrondprocessen op de nieuwe omgeving gestart. Eventueel gemiste notificaties werden met een kleine vertraging dus alsnog verstuurd.

Een zeer gedetailleerd stappenplan met als doel: zero-downtime. Het ergste dat gebruikers hadden moeten merken was het voor een paar minuten niet kunnen aanpassen van hun instellingen en eventueel een iets vertraagde notificatie.

Op zichzelf al acceptabel, maar om het aantal mogelijk getroffen gebruikers nog verder te beperken hebben we samen met Rd4 gekeken naar een goed moment om deze migratie uit te voeren. Een moment waarop er weinig gebruik van de app was. Van daadwerkelijk gebruik van de app tot de afvalkalender herinneringen die verstuurd moesten worden, we hebben alles zorgvuldig in kaart gebracht om het meest geschikte moment te bepalen.

Conclusie: sinds zaterdag 1 februari 2025 maakt de oude Milieu App gebruik van de geheel vernieuwde API.

(Niet zo) nice to know:

Ondanks al onze inspanningen en tests hebben we de zero-downtime niet gehaald 🥹.
In de maanden voor de daadwerkelijke overgang hadden we een unieke index verwijderd uit de database voor een “last minute” fix van een edge case. Die index bleek alleen zeer belangrijk voor de performance van de compatibility API. Uiteindelijk hebben we het dus 12 minuten zonder bruikbare API moeten doen voordat we weer een index in de database hadden. Geen zero-downtime maar die dag nog altijd een uptime van 99% en verder geen problemen. Daar doen we het voor!

Stap 7: de update

Nu de API vervangen is, hebben we het grootste deel van de overgang gehad. Nog even monitoren of er geen gekke dingen met de nieuwe API gebeuren en dan is het tijd voor de publicatie van de nieuwe apps!

Aan de publicatie van de update is niets bijzonders. Alle bijzonderheden hebben we tijdens de ontwikkeling al gehad, dus nu zetten we de app gewoon live en gaan we wachten tot alle gebruikers de automatische update hebben ontvangen.
Statistieken op het grote scherm en wachten maar! 🍿

Fun fact: na 1 week zat al bijna 40% van alle gebruikers in de nieuwe app.

Sinds de lancering van de nieuwe app (update) draaien dus zowel de nieuwe als de oude app naast elkaar op de nieuwe API. Dumpafval meldingen uit de oude app zie je ook in de nieuwe app en vice versa. Echt zoals een app-update!

Uiteraard willen we niet voor altijd de oude app blijven ondersteunen, want het onderhouden van de compatibility API kost ook tijd. Tijd die we liever stoppen in het ontwikkelen van nieuwe functionaliteiten. Dus naar verwachting gaat de stekker eind 2025 uit de compatibility API en stopt de oude app met werken. In de tussentijd kijken we met een goed gevoel terug op de overgang en maken we mooie plannen voor de nieuwe app!

Is dit wat voor mijn app?

Tja, dat hangt ervan af. Een vernieuwing zoals die van de Rd4 Milieu App is, zoals je gemerkt hebt, geen klein project. Maar voor een app met duizenden gebruikers is de gebruikerservaring toch echt wel heel belangrijk. Kun je kleinere apps dan niet vernieuwen? Jazeker wel! Een vernieuwingstraject maak je op maat. Benieuwd naar wat we voor jouw app kunnen betekenen? Neem dan vrijblijvend contact met ons op.