7 technische UX-beslissingen die het aantal app-crashes vóór de lancering verminderen

7 technische UX-beslissingen die het aantal app-crashes vóór de lancering verminderen

De meeste teams gaan ervan uit dat crashes een testprobleem zijn. Dat zijn ze niet. Tegen de tijd dat QA een crash vindt, werd de beslissing die hem veroorzaakte drie sprints eerder genomen, meestal in een ontwerpbespreking of een architectuurgesprek waar niemand nadacht over wat er mis kon gaan. Dit artikel benoemt zeven specifieke technische UX-beslissingen die bepalen of je app crasht in productie, en wat je bij elk ervan anders kunt doen.

Het crashpercentage waarmee je app wordt gelanceerd is grotendeels een ontwerpbeslissing die zich vermomt als een bugrapport.

Waarom UX-beslissingen crashes veroorzaken, niet alleen codefouten

UX-beslissingen veroorzaken crashes omdat ze bepalen welke statussen de app moet kunnen verwerken, en de meeste ontwerpprocessen definiëren alleen het ideale pad. Wanneer een ontwerper een scherm specificeert zonder rekening te houden met lege statussen, laadfouten of onderbroken processen, vult de ontwikkelaar de gaten in onder tijdsdruk. Die gaten worden crashvectoren. Een crashvector is elk codepad waarbij een onverwerkte situatie ervoor zorgt dat de app onverwacht stopt.

Dit is geen argument om de ontwerper de schuld te geven. Het is een procesargument. Op het moment dat een scherm wordt overgedragen zonder een gedefinieerde foutstatus, heeft de app een structurele zwakte. Bij native iOS- en Android-ontwikkeling zal een onverwerkte null-referentie of een ontbrekende terugvaloptie voor een lege API-reactie het proces volledig beëindigen. In platformoverstijgende raamwerken zoals React Native of Flutter levert dezelfde omissie een rood scherm op tijdens ontwikkeling en een stille crash in productie.

Als app design bureau ziet Studio Ubique het vaakst niet één catastrofale beslissing, maar een reeks kleine omissies die zich opstapelen. Een ontbrekende laadstatus hier, een aangenomen netwerkverbinding daar, en plotseling zit het crashpercentage bij lancering op vier procent, terwijl de acceptabele drempel voor de meeste app stores onder de één procent ligt.

Vier procent klinkt klein. Het betekent dat één op de vijfentwintig gebruikers de eerste keer dat ze het product proberen te gebruiken tegen een muur loopt.

Statusbeheer: de stille crashfabriek

Statusbeheer, het systeem dat bijhoudt welke gegevens de app heeft en welk scherm op elk moment moet worden weergegeven, is de grootste bron van vermijdbare crashes in mobiele apps. Wanneer de status inconsistent wordt beheerd, kan de app een scherm bereiken met gegevens die het niet verwacht, of helemaal geen gegevens, en stoppen in plaats van herstellen.

Het specifieke faalpatroon ziet er zo uit: een gebruiker navigeert naar een detailscherm, de app haalt gegevens op, de gebruiker zet de app op de achtergrond, het besturingssysteem maakt geheugen vrij, de gebruiker keert terug, en de app probeert een scherm te tonen met een leeg gegevensobject. Op Android levert dit een ANR-gebeurtenis (Application Not Responding) of een harde crash op. Op iOS een vergelijkbare beëindiging. Geen van beide is herstelbaar zonder een bewuste terugvaloptie.

De UX-beslissing die dit voorkomt is ontwerpen voor terugkeer. Elk scherm dat afhankelijk is van opgehaalde gegevens heeft een gedefinieerd gedrag nodig voor het geval die gegevens niet meer in het geheugen staan. Dat gedrag moet worden vastgelegd in het ontwerp, niet worden geïmproviseerd in de code.

In projecten waarbij de architectuur voor statusbeheer werd overeengekomen vóór de ontwerpoverdracht, daalden crashpercentages uit deze categorie merkbaar in de eerste twee weken na lancering. In projecten waar het aan de ontwikkelaar werd overgelaten om te beslissen, verscheen dezelfde categorie crashes in het eerste crashrapport binnen 48 uur na livegang. Dat patroon is consistent genoeg om een regel te zijn.

Beslisbox

• Geschikt als: je app meerdere schermen heeft die afhankelijk zijn van opgehaalde of door gebruikers gegenereerde gegevens, overgangen van achtergrond naar voorgrond, of sessiegebaseerde authenticatie.
• Minder geschikt als: je app een enkelvoudig hulpmiddel is zonder netwerkafhankelijkheid en zonder blijvende status tussen sessies.
• Waarschijnlijk overbodig als: je een prototype of MVP bouwt waarbij crashpercentage nog geen succesmaatstaf is.

Invoervalidatie en foutafhandeling op de juiste laag

Invoervalidatie voorkomt crashes wanneer het op de juiste laag plaatsvindt, zowel de UI-laag als de gegevenslaag, niet slechts één van de twee. Alleen vertrouwen op validatie aan de serverzijde betekent dat de app een onverwacht reactieformaat kan ontvangen en crasht bij het verwerken ervan. Alleen vertrouwen op validatie aan de clientzijde betekent dat een onjuist gevormde API-reactie nog steeds onbeschermd de weergavelogica bereikt.

De praktische beslissing is deze: elk gegevensobject dat de UI binnenkomt, moet worden gevalideerd voordat het wordt weergegeven. Dit gaat niet over foutmeldingen voor de gebruiker, hoewel die ook belangrijk zijn. Het gaat erom dat de app niet probeert een veld weer te geven dat niet in de reactie bestaat.

Foutgrenzen, een patroon dat beschikbaar is in React Native en vergelijkbare raamwerken en dat weergavefouten opvangt voordat ze de hele app laten crashen, zijn de structurele oplossing hier. Ze worden niet standaard gebruikt. Ze moeten bewust worden geplaatst. Een veelgemaakte fout is het plaatsen van één foutgrens bij de root van de app en aannemen dat die alles afdekt. Dat doet hij niet. Gedetailleerde foutgrenzen rondom gegevensafhankelijke componenten zijn wat het crashpercentage daadwerkelijk verlaagt.

De UX-beslissing is het specificeren welke componenten gegevensafhankelijk zijn en wat ze moeten tonen wanneer gegevens ontbreken of onjuist zijn gevormd. Die specificatie hoort in het ontwerp, niet in een beoordelingsbeslissing van een ontwikkelaar om elf uur ’s avonds voor een release.

Navigatiearchitectuur en crashes in de navigatiestapel

Navigatiearchitectuur bepaalt hoe de app zijn geschiedenis van schermen beheert, de navigatiestapel genaamd, en het verkeerd aanpakken ervan is een van de meest betrouwbare manieren om crashes te produceren die moeilijk te reproduceren zijn tijdens het testen. Een crash in de navigatiestapel treedt op wanneer een gebruiker in een onverwachte volgorde navigeert en de app probeert terug te keren naar een scherm dat niet meer in het geheugen bestaat, of probeert gegevens door te sturen naar een scherm dat nooit is geïnitialiseerd.

Het specifieke scenario dat de meeste problemen veroorzaakt is diep koppelen gecombineerd met voorwaardelijke navigatie. Een gebruiker tikt op een pushmelding, belandt op een detailscherm, drukt op terug, en de app crasht omdat het bovenliggende scherm nooit is geladen. Dit is een beslissing over navigatiearchitectuur, geen bug. De architectuur hield geen rekening met toegangspunten buiten de normale stroom.

De oplossing is het definiëren van alle geldige toegangspunten tijdens de ontwerpfase en het specificeren hoe de navigatiestapel eruit moet zien voor elk toegangspunt. Dit kost ongeveer twee uur in een ontwerpbespreking en bespaart ruwweg twee dagen debuggen na lancering.

Nog iets wat het benoemen waard is: modale schermen die kunnen worden gesloten terwijl een asynchrone bewerking nog actief is, zijn een consistente crashbron. De bewerking wordt voltooid, probeert een scherm bij te werken dat niet meer bestaat, en de app stopt. Het ontwerpen van het sluitgedrag om de bewerking af te wachten of te annuleren is een UX-beslissing met een directe crashconsequentie.

Asynchrone bewerkingen, laadstatussen en race conditions

Asynchrone bewerkingen, elke actie waarbij de app een verzoek verstuurt en wacht op een reactie, zijn crashgevoelig wanneer de UI geen rekening houdt met de tijd tussen verzoek en reactie. Een race condition, waarbij twee bewerkingen in een onverwachte volgorde worden voltooid en een conflicterende status produceren, is het meest voorkomende gevolg. De app probeert twee versies van dezelfde gegevens tegelijkertijd weer te geven en stopt.

De UX-beslissing die dit voorkomt is het specificeren van laadstatussen als volwaardige ontwerpelementen, niet als bijzaak. Elk scherm dat een asynchrone bewerking activeert, heeft drie gedefinieerde statussen nodig: laden, succes en fout. Als het ontwerp alleen de successtatus toont, improviseert de ontwikkelaar de andere twee, en geïmproviseerde laadstatussen zijn waar race conditions ontstaan.

Een specifiek patroon dat het benoemen waard is: dubbelklik-crashes. Een gebruiker tikt op een knop, er lijkt niets te gebeuren omdat de laadstatus onzichtbaar of afwezig is, de gebruiker tikt opnieuw, en de app verstuurt twee identieke verzoeken. Afhankelijk van hoe de reactieverwerker is geschreven, kan dit een crash produceren wanneer beide reacties binnenkomen en beide hetzelfde statusobject proberen bij te werken.

Het uitschakelen van interactieve elementen tijdens asynchrone bewerkingen is een eenregelige UX-beslissing die een hele categorie crashes elimineert. Het is ook het soort beslissing dat wordt overgeslagen wanneer het ontwerp alleen voor het ideale pad is gebouwd.

Monitoring, releasedrempels en de feedbacklus die echt werkt

Monitoring werkt alleen als het is gekoppeld aan een beslissing. Een crashrapport dat niemand leest is geen monitoring, het is loggen. De feedbacklus die het crashpercentage van apps in de loop van de tijd daadwerkelijk verlaagt, is er een waarbij crashgegevens een specifieke actie activeren voordat de volgende release wordt uitgebracht.

Het hulpmiddel dat de meeste teams gebruiken is Firebase Crashlytics, dat realtime crashrapportage biedt gegroepeerd per probleem, met apparaat-, besturingssysteem- en sessiecontext erbij. Het nuttige getal is niet het totale aantal crashes maar het percentage crashvrije sessies, het aandeel sessies dat wordt voltooid zonder crash. De drempel van Google Android Vitals voor een goed percentage crashvrije sessies is 99 procent of hoger. De meeste apps zitten bij lancering tussen de 96 en 98 procent. Dat verschil is bijna altijd te herleiden tot de beslissingen die in de bovenstaande secties zijn beschreven.

Een releasedrempel is een regel die een nieuwe versie blokkeert om naar productie te gaan als het percentage crashvrije sessies tijdens gefaseerde uitrol onder een gedefinieerde drempel daalt. Die drempel instellen vóór lancering, niet na de eerste slechte release, is de beslissing die teams die crashes opvangen voordat ze alle gebruikers bereiken onderscheidt van teams die het horen via een recensie met één ster.

De feedbacklus sluit zich wanneer crashgegevens samen worden beoordeeld door de ontwerper en de ontwikkelaar, niet alleen door de ontwikkelaar. De ontwerper moet zien welke schermen crashen en waarom, omdat de oplossing vaak een ontwerpwijziging is, geen codewijziging.

Wat je maandelijks checkt

• Percentage crashvrije sessies, streefwaarde 99 procent of hoger, uitgesplitst naar besturingssysteemversie en apparaattype.
• ANR-percentage (Application Not Responding) op Android, apart bijgehouden van harde crashes.
• Top vijf schermen die crashes veroorzaken, maand over maand vergeleken om regressies op te sporen.
• Crashpercentage per app-versie, om te bevestigen dat nieuwe releases geen nieuwe crashcategorieën introduceren.
• Tijd tot eerste crash na een nieuwe release, als vroege indicator van releasekwaliteit.

App crashes verminderen is primair geen testprobleem. Het is een reeks ontwerp- en architectuurbeslissingen die worden genomen voordat de eerste regel productiecode wordt geschreven. Studio Ubique werkt samen met productteams om crashvectoren in de ontwerpfase te identificeren, waar het oplossen ervan uren kost in plaats van sprints. Volgens gegevens van Google Android Vitals (2024) worden apps met een percentage crashvrije sessies onder de 99 procent gemarkeerd als apps met slechte kernprestaties, wat direct invloed heeft op de zichtbaarheid in de app store.

Veelgestelde vragen

Wat is een goed percentage crashvrije sessies voor een mobiele app?

Google Android Vitals stelt 99 procent als drempel voor een goed percentage crashvrije sessies. Daaronder wordt je app in de Play Store gemarkeerd als app met slechte kernprestaties, wat de vindbaarheid beïnvloedt. De meeste apps zitten bij lancering tussen de 96 en 98 procent, wat betekent dat de eerste prioriteit na lancering bijna altijd het dichten van dat verschil is.

Hoe beïnvloeden UX-beslissingen het crashpercentage van apps?

UX-beslissingen bepalen welke statussen de app moet kunnen verwerken. Wanneer een ontwerp alleen het ideale pad specificeert en foutstatussen, laadstatussen en terugkeergedrag weglaat, vullen ontwikkelaars die gaten in onder tijdsdruk. Die geïmproviseerde oplossingen zijn de oorsprong van de meeste vermijdbare crashes. Expliciet ontwerpen voor faalstatussen is de meest directe manier om app crashes te verminderen voordat er één regel code is getest.

Wat is statusbeheer en waarom veroorzaakt het crashes?

Statusbeheer is het systeem dat bijhoudt welke gegevens de app heeft en wat er op elk moment moet worden weergegeven. Het veroorzaakt crashes wanneer de app een scherm bereikt dat gegevens verwacht die niet meer in het geheugen staan, doorgaans nadat de app op de achtergrond is gezet en het besturingssysteem geheugen heeft vrijgemaakt. Het ontwerpen van expliciet terugkeergedrag voor elk gegevensafhankelijk scherm voorkomt deze categorie crashes.

Wat is een race condition in een mobiele app?

Een race condition treedt op wanneer twee asynchrone bewerkingen in een onverwachte volgorde worden voltooid en een conflicterende status produceren. Het meest voorkomende voorbeeld is een gebruiker die twee keer op een knop tikt omdat er geen laadstatus zichtbaar is, waardoor twee identieke verzoeken worden verstuurd, en beide reacties tegelijkertijd hetzelfde gegevensobject proberen bij te werken. Het uitschakelen van interactieve elementen tijdens asynchrone bewerkingen elimineert de meeste race condition-crashes.