De app deel 3: iOS of Android?

Vorige keer hebben we al uitgelegd dat we de ontwikkeling van de app hebben opgesplitst in 2 delen. Eerst gaan we een MVP vrijgeven, daarna gaan we de overige functionaliteit toevoegen, zodat de app compleet wordt. Het einde van de ontwikkeling van het MVP lijkt in zicht te komen. Bijna alle functionaliteit zit erin en bijna alle schermen zien er mooi uit.

Diana moet alleen nog een hoop details en foutafhandeling verwerken. Vooral die laatste is belangrijk, want jij wilt als gebruiker geen foutmelding krijgen waar je niks mee kan. Dat moeten wij voor je oplossen. Terwijl Diana ervoor zorgt dat de app foutmeldingen geeft waar je iets mee kunt, gaat Joep de handleiding maken. Samen moet dat ervoor zorgen dat jij als gebruiker nooit vastloopt.

Trello board with task or todo lists
Wij gebruiken Trello om onze taken bij te houden.

Eigenlijk hebben we de ontwikkeling van de app in meer dan twee delen opgesplitst. Software is namelijk nooit af. Deel 3 van de ontwikkeling is onderhoud aan de app: kleine dingen verbeteren, foutjes oplossen, dingen handiger maken, en nieuwe dingen toevoegen. Dat soort dingen zetten we op onze backlog om “someday” te doen.

Ontwikkelen voor iOS en Android

Als je een app gaat maken, zul je moeten kiezen voor welk besturingssysteem je dat gaat doen. Je moet dus kiezen welke telefoons en tablets je gaat ondersteunen en welke niet. Gelukkig worden dat soort keuzes tegenwoordig steeds makkelijker. Ten eerste omdat er nog maar twee systemen echt de moeite waard zijn: iOS en Android.

Ten tweede omdat Apple en Google hun best doen om zoveel mogelijk te “regelen” in hun besturingssystemen, iOS en Android respectievelijk. Als ontwikkelaar hoef je dus niet meer na te denken over alle telefoons en tablets. Je hoeft alleen nog maar de minimum versie van dat systeem te bepalen, bijvoorbeeld alle telefoons met iOS 11 of hoger.

Ten derde zijn er tegenwoordig volwassen ontwikkelplatforms die het meeste werk voor je uit handen nemen. Jij maakt 1 app en het platform maakt daar twee van, een voor iOS en een voor Android. Wij hebben gekeken naar Xamarin, Flutter, Ionic en React-Native, maar er zijn er nog veel meer. Uiteindelijk hebben we gekozen voor React-Native.

pughmatrix
In een Pugh matrix vergelijk je verschillende opties zo objectief mogelijk.

Toch nog zelf doen

Ondanks dat zo’n ontwikkelplatform je veel werk uit handen neemt, zijn er altijd dingen die toch niet lekker werken. Zo kwamen wij erachter dat inloggen op onze webAPI net iets anders wordt gedaan op een iPhone.

Op Android leiden we je naar een inlogpagina op onze website. Dat doen we om ervoor te zorgen dat je wachtwoord veilig blijft (hoe dat precies werkt leggen we een andere keer uit). Zodra jij daar hebt ingelogt, stuurt de website (de webAPI om precies te zijn) je terug naar de app en geeft daarbij een seintje dat het inloggen gelukt is.

Op iOS leiden we je ook naar die inlogpagina. Zodra jij daar hebt ingelogt, stuurt de website je terug naar de app. Tot zover niks aan de hand, maar op iOS kunnen we geen seintje meesturen. De app weet dus niet dat het inloggen gelukt is. Op een iPhone blijft de app dus vragen: “is het gelukt?…is het gelukt?…is het gelukt?”, totdat hij “ja” als antwoord krijgt.

permission dialog to go to jodibooks.com

Andere design filosofie

Alles wat we tot nu toe beschreven hebben is relatief makkelijk op te lossen. De gebruiker merkt er waarschijnlijk ook helemaal niks van. Dat komt omdat we het belangrijkste verschil nog niet besproken hebben: het design en gebruik. Google en Apple zijn het niet eens over hoe een app eruit moet zien, hoe ze dezelfde onderdelen noemen, welke “gestures” je moet gebruiken en zelfs hoe de icoontjes eruit horen te zien.

Voor het design zegt Google dat de “Material” design filosofie het beste is. Ze beschrijven op material.io uitgebreid hoe je alles zou moeten maken. Apple heeft ook ideeën daarover die ze op hun website beschrijven. Dan moet je wel weten hoe hetzelfde ding bij beide heet. Op dit blog staan een paar mooie voorbeelden.

android en ios render van hetzelfde scherm met een picker element
Links het scherm zoals gerendered op een Android 9 toestel. Rechts op een iPhone 6s (iOS 12.4).

Maar daarmee ben je er nog niet. Want Android heeft andere standaard knoppen en gebaren dan iOS. Die laatste heeft bijvoorbeeld alleen een home-knop. Android telefoons hebben meestal meerdere (zie de zwarte balk op het plaatje hierboven). Op Android klik je een popup altijd weg door op een kruisje of OK te drukken. Op iOS door gewoon ernaast te drukken.

Al die dingen maken het lastig om een zo “native” mogelijke app te maken. Met native wordt bedoeld dat de app opgaat in zijn omgeving, in dit geval het besturingssysteem iOS of Android. Daarmee hopen we dat zowel mensen met een iPhone als mensen met een Android toestel niet hoeven na te denken over hoe ze de app moeten bedienen.

Wij zijn allebei Android mensen. Dus ons grootste probleem is weten hoe iets eruit moet zien op iOS. We hebben wel de guidelines van Apple, maar we kennen geen echt goede voorbeelden. In het plaatje hierboven zie je bijvoorbeeld hoe we verschillende “pickers” hebben gemaakt, maar is dit ook hoe het eruit hoort te zien? Laat het ons vooral weten, dan passen we het aan in volgende versies van de app.

App store(s)

Wat steeds dichterbij komt is het uiteindelijk echt releasen van de app. Dat doe je door de app als download aan te bieden. Je kunt dat doen op je eigen website, maar het is veel om je app in de App store van Apple en de Play store van Google aan te bieden. Hoe dit werkt weten we nog niet precies.

Wat we wel weten is dat we een iOS en Android app moeten “bouwen” (builden in het Engels). Omdat wij onze app ontwikkelen met React-Native kunnen we gebruik maken van een dienst genaamd Expo. Dit is een soort laagje om onze app heen, dat ons helpt met het builden en testen van de app.

Maar daarmee staat de app nog niet in de stores. Ook daar helpt Expo ons gelukkig mee door een distibutie handleiding te maken. Gelukkig maar, want het proces bij Apple is heel anders dan bij Google. En dan hebben we het nog niet eens over de prijs: $99 per jaar bij Apple, eenmalig $25 bij Google.

Leave a Reply