Top 10 fouten bij app ontwikkeling

Er kan een hoop fout gaan bij het ontwikkelen van een mobiele app omdat het een complex product is. Echter zien wij dat bepaalde fouten bij veel bedrijven voorkomen wanneer ze een app maken en dat de industrie als een geheel hieronder lijdt.

Sommige van deze fouten zijn nog te herstellen, maar anderen zorgen ervoor dat het app project geen hoop meer heeft op een succesvolle afronding. Hierdoor wordt het probleem waar de klant mee worstelt niet verholpen, en dat is jammer. Zeker omdat het tijd en geld kost om een mobiele app te laten maken.

Laten we gaan kijken naar de top 10 fouten!

10. Verouderde technieken

Net zoals dat iOS af en toe een update krijgt, krijgt Xcode, het programma waarmee men iOS apps maakt, ook op gelijke tijden een update. Daarin worden altijd nieuwe technieken van het ontwikkelen van iOS apps meegegeven. Het niet leren wat er nieuw is en dit integreren in de app kan uiteindelijk fataal zijn.

Dit geldt niet alleen voor Xcode, maar ook voor Android Studio (de ontwikkelomgeving voor Android), Swift (de Apple programmeertaal), Kotlin (de Android programmeertaal), de Google Play Store en de Apple App Store. Ze veranderen allemaal maandelijks met telkens nieuwe mogelijkheden om op te reageren.

9. Testen is toch niet belangrijk?

Iedereen weet dat software getest moet worden. Een app is niet anders. Verwarring ontstaat pas bij de definitie van "testen".

Stel, een app ontwikkelaar ontwikkelt de app door telkens de app te draaien op de nieuwste iPhone met de nieuwste iOS versie op WiFi en elke keer wat code toe te voegen. Op een gegeven moment werkt de app zoals bedoelt. Maar de ontwikkelaar heeft enkel nog maar gekeken naar de nieuwste iPhone met de nieuwste iOS versie.

In de software wereld wordt dit "Developer tested" genoemd. De ontwikkelaar heeft iets gemaakt en heeft bevonden dat het werkt op zijn toestel. Maar nu is de grote vraag: Werkt het ook op de nieuwste iPad met een traag mobiel netwerk? En een oudere iPhone met een oudere iOS versie?

Dit kan niet met zekerheid gezegd worden tenzij alle mogelijke stappen met die configuratie doorlopen worden. Dit kost helaas veel tijd, zeker als dat handmatig moet. Maar het is wel de enige manier om te garanderen dat een app blijft werken als die door vele verschillende klanten met vele verschillende apparaten gebruikt gaat worden.

"Developer tested" is een misleidende term omdat er slechts 1 configuratie en waarschijnlijk ook alleen de happy flow getest is. Een klassiek geval van "de slager keurt zijn eigen vlees". Helaas is dit wat veel bedrijven bedoelen als ze zeggen dat ze "getest" hebben.

Alle code is schuldig totdat het tegendeel bewezen is

In een grote app kan het aantal werkingen exponentieel uitlopen. Stel: De app heeft een login scherm met een gebruikersnaam en een wachtwoord en er wordt iets gewijzigd. Werkt het login formulier dan nog steeds als men een emoji invult bij de gebruikersnaam? En bij het wachtwoord? En als de gebruiker er een gebruikt bij beide? Wat gebeurt er dan?

Emoji’s zijn een voorbeeld van waar ontwikkelaars rekening mee moeten houden waar men als gebruiker zich nauwelijks bewust van zijn. Dit komt omdat 99 van de 100 gebruikers alleen maar alphanumerieke karakters (A-Z en 0-9) gebruikt bij een login.

8. Quick and dirty

Sommige mensen hebben het geduld niet om iets goed te maken en er de benodigde tijd aan te besteden. Snel met omwegen is dan het pad dat bewandeld wordt. Niet opvallende aspecten zoals security worden overgeslagen om tijdwinst te verkrijgen, oude template-code wordt gebruikt.

De moeilijkheid in app ontwikkeling zit hem niet in een app maken. De moeilijkheid zit hem in een app maken die 3 wijzigingen en 4 iOS en Android updates later nog steeds perfect werkt

Stel: Als app ontwikkelaar stel ik bij een scherm de achtergrondkleur in op wit. De klant krijgt een demo te zien en alles ziet er geweldig uit volgens design. Een jaar later introduceert Apple iOS 13 met dark mode. Ineens zorgt de harde koppeling tussen dat scherm en de witte achtergrond dat de app er beroerd uit ziet in dark mode!

De achtergrond is wit (dat was hard ingesteld), en de tekstkleur wordt nu automatisch ook wit door dark mode. De gebruikers zien geen tekst meer omdat die compleet wegvalt tegen de achtergrond. Een betere optie met wat meer moeite was om de system background kleur te gebruiken. Deze veranderd namelijk wel dynamisch mee.

Software ontwikkelaars moeten in feite de toekomst voorspellen. Wat kan er mogelijk veranderen waardoor mijn code in de toekomst niet meer zal werken? Goede software ontwikkelaars voorspellen de toekomst niet echt, ze dichten slechts elke mogelijkheid af, hoe onwaarschijnlijk die ook lijkt. Zo hoeven ze de toekomst niet echt te voorspellen, maar is hun code er wel klaar voor.

7. Verandering niet inbegrepen

Alle apps moeten ooit veranderd worden, bijvoorbeeld wanneer de klant zijn wens veranderd, maar ook als er een nieuw operating system uitkomt, bijvoorbeeld de nieuwste versie van iOS. Bij iOS 13 was het dat apps met slides konden werken, met iOS 14 dat apps in picture-in-picture modus konden draaien. Elke operating system update brengt verandering met zich mee waarop ingespeeld moet worden.

Stilstaan is achteruitgaan

Helaas is het ook mogelijk om zo software te ontwikkelen dat verandering maar moeilijk doorgevoerd kunnen worden omdat er te veel concrete, in plaats van abstracte concepten gebruikt zijn.

Nooit gaat er een moment komen dat een softwareproject goed is tot in de oneindigheid. Elk stuk software heeft een houdbaarheidsdatum, ook de software die gemaakt wordt door Google, Apple en Facebook. De wereld van software evolueert veel te snel om stil te staan.

6. Te weinig marketing

Een app kan in alle opzichten perfect zijn, maar als niemand weet dat er een app is om te downloaden dan gaat een app niet veel opbrengen. Dit kan al verholpen worden door simpelweg verbaal aan te geven dat een bepaalde dienst een app heeft.

Wat ook helpt is om op al bestaande producten te vermelden dat er een nieuwe app is die van toegevoegde waarde kunnen zijn voor al bestaande klanten.

5. Een website is al bijna een app toch?

Nee. Een app ontwikkelen is andere koek dan een website ontwikkelen. Een app kan een smartphone laten vibreren, push-notificaties versturen, een vingerafdruk of gezicht herkennen, informatie uitwisselen bij contact via NFC, heeft een eigen pagina in de app stores en nog veel meer.

Daarnaast heeft vooral Apple, maar ook Google een hoop richtlijnen die nageleefd moeten worden, of de app komt niet in de stores. Denk aan een leeftijdsclassificatie van PEGI. Er zijn wel honderd zaken waar een app rekening mee moet houden en een website niet.

Ook is het belangrijk om te beseffen dat een website in een browser draait die vervolgens op een OS draait, en dus afhankelijk is van wat de browser van het OS vrijgeeft. Een app draait altijd direct op het OS en is daarom altijd een stuk minder afhankelijk.

Dit is een probleem voor hybrid (website) apps bij updates van iOS of Android. Toen Apple in iOS 12 gezichtsherkenning toegevoegd heeft konden de native apps een maand voor de release van iOS 12 via de beta hier op ontwikkelen. De hybrid (website) apps konden dit pas nadat de browser waar ze op draaiden dit hadden ontsloten van het OS. Hierdoor kan het goed dat de hybrid (website) apps twee maanden later zijn.

Een websiteontwikkelaar zal moeite hebben met alle app specifieke onderdelen zoals bijvoorbeeld batterij en netwerk besparing omdat dit een veel groter aspect is bij een app dan bij websites.

4. Te vage definities

De klant wil een app laten maken waarmee producten verkocht worden. Maar ja, wat zijn producten? Zijn er wetten verbonden aan een app die deze producten verkopen zoals bij medicijnen? Alleen het weten dat een klant producten verkoopt en een generieke app template uit de kast halen is niet voldoende omdat verschillende producten verschillende eisen met zich mee brengen.

De app moet op Android en iOS werken. Is dit dan iOS 10+ of iOS 12+? Simpelweg het laagste nummer pakken om zo veel mogelijk klanten te ondersteunen is niet altijd mogelijk omdat sommige features waar de app van afhankelijk is pas toegevoegd zijn in iOS 12 en daarom niet beschikbaar zijn op iOS 10.

Geen zorgen, een professionele app ontwikkelaar zal deze vragen alleen stellen aan de klant als blijkt dat er problemen kunnen ontstaan. Anders wordt het optimale pad gekozen, zoals bijvoorbeeld een zo laag mogelijke minimale versie van iOS om zoveel klanten te kunnen ondersteunen.

3. Onderschatting van de complexiteit

Dit is een vervelende, omdat het maar al te menselijk is om werk positiever in te schatten dan dat het echt gaat zijn. Zeker in de softwareontwikkeling is dit een valkuil waar de meest ervaren ontwikkelaars nog voor vallen. We hebben het allemaal meegemaakt. Iets beloven is makkelijk, het daadwerkelijk leveren is moeilijker.

Dit komt omdat er bij software vaak 80% onder de motorkap afspeelt en maar 20% visueel is.

Denk bijvoorbeeld aan security van software. Cruciaal, zal iedereen je weten te vertellen, maar het is iets dat niet opvalt als het er niet is, tenminste, als er geen aanval gedaan wordt. Eenzelfde idee als rookmelders in een huis, het wordt niet gemist totdat het te laat is. Helaas kost het wel tijd om security zo dicht mogelijk te maken.

2. Te lang geen feedback van de klant verwerkt

Een app laten maken kan soms lang duren. Er is een 100% kans dat het gehele concept na 1 gesprek tussen de klant en app ontwikkelaar nog niet voldoende overgedragen is. Communicatie is altijd lastig, en misverstanden gaan ontstaan. Evenals zaken die besproken hadden moeten worden maar niet besproken zijn.

Dit kan verholpen worden door elke twee weken iets op te leveren aan de klant en daar dan over in gesprek te gaan. Zo kan de klant gemakkelijk bijsturen.

Naarmate een project vordert ontstaan er altijd vragen of opties voor de klant waar ontwikkelaars nog te vaak over beslissen. Er is maar een bron van waarheid en dat is wat de klant wil. Kijk snel naar de nummer 1 fout om te zien wat hier bedoeld wordt.

1. Onvoldoende aandacht voor de wens van de klant

Met verre afstand de meest voorkomende fout bij een app laten maken en tevens ook de meest fatale fout voor een app.

Er is maar een manier om een app een succes te maken, en dat is niet door de meest geweldige animaties in een app te stoppen (al ziet dat er wel mooi uit) of om het design zo mooi mogelijk te maken. Nee, de enige manier om een app een succes te maken is als de app van toegevoegde waarde is voor de klant. Als dit niet het geval is dan kan de app zo technisch geweldig en mooi zijn als maar kan, maar dan zal het project helaas alsnog falen.

Er dient gedegen aandacht gestopt te worden in het uitzoeken wat een klant nou echt wil in plaats van zo snel mogelijk te beginnen met coderen.