Bouw 3 apps, betaal 1 keer: de voor- en nadelen van cross-platform app-ontwikkeling

He Jeroen,

Goed om te horen dat de mails je zo bevallen :)

Als je voor de keuze staat voor een ontwikkelmethode, dan is het goed om te weten hoe een ontwikkelaar werkt. Wellicht heb je je al hierin verdiept, maar bij deze even de uiteenzetting.

Als een app geprogrammeerd wordt voor iPhone en Android, dan wordt deze voor ieder platform in zijn eigen programmeertaal gemaakt. Android apps worden geprogrammeerd in Java en voor iPhone wordt Objective-C of Swift gebruikt. Vergelijk het met Frans en Duits: twee talen die moeilijk verenigbaar zijn en als je erin wil communiceren, dan doe je dat voor iedere taal apart.

Omdat er twee keer geprogrammeerd wordt heb je ook twee keer de kosten. Daarnaast moet er ook twee keer een interface ontworpen worden: voor zowel Android apps als iPhone apps zijn gebruikers een ander interface gewend. Daarbij komt nog kijken: als de app ook beschikbaar gemaakt moet worden voor Windows Phone (dat in Nederland een marktaandeel heeft van ongeveer 1 procent), dan moet de app nóg een keer de kosten kwijt. In de talen analogie van Frans en Duits dan staat Windows Phone voor een app in het Slowaaks. Je gaat dan inderdaad opnieuw programmeren en opnieuw een interface maken. En stel je nou eens voor dat je onderhoud moet doen aan de app. Of functies wil toevoegen. Inderdaad: voor ieder platform apart.

Nu zijn er slimmeriken geweest die hebben gezegd: wat als we nu een universele taal gebruiken en vanuit daar automatisch vertalen naar ieder besturingssysteem? Zeg maar je app in het Engels via een automatische tolk vertalen naar het Frans, Duits en het Slowaaks. Super handig: dan maak je de app in één keer en ook onderhoud en aanpassingen gaan dan in één keer. Scheelt kosten, maakt de app beheersbaarder en de app is sneller klaar.

Verschillende leveranciers zijn hierin gesprongen: Apache Cordova (voorheen Phonegap), M2Active, Xamarin, Flutter en Maji Mobile zijn zogenaamde "Cross-platform" ontwikkelmethodes. Zij zorgen ervoor dat jouw app de eerste keer in een universele taal wordt geschreven, zoals HTML of C# en daarna via hun "automatische vertaler" wordt omgezet in een taal die de smartphone begrijpt.

Een voorbeeld hiervan is Yellowbrick. Zij willen iedere Nederlandse smartphonegebruiker bedienen, ook de Windows Phone gebruiker. Daarnaast zijn ze actief in verschillende landen, waar de app door andere omstandigheden zoals regelgeving, er heel anders uit zou zien. Met een traditionele aanpak waarbij voor ieder platform ontwikkelt wordt, moet de app 3 x het aantal landen ontwikkelt én onderhouden worden. Als ze bijvoorbeeld actief zijn in 8 landen, betekent dat 3 x 8 = 24 verschillende versies van de app die gemaakt en onderhouden moet worden. Een onmogelijke klus. Daarom koos Yellowbrick voor Maji Mobile, waarbij ze slechts één versie van de app hebben per land. Zo wordt hun app veel beheersbaarder en betaalbaarder. Zo verdienen ze de investering in hun app sneller terug, hebben ze minder onderhoudskosten en is hun "business case rond".

Heeft deze aanpak dan ook nadelen? Ja, helaas wel. Het is namelijk zo dat het automatische vertalen zijn beperkingen heeft. Ondanks dat deze platformen in de afgelopen jaren veel sneller zijn geworden (om allerlei technische redenen), kunnen gebruikers van oude of goedkope toestellen last hebben van vertragingen in de app. Ook betekent deze aanpak dat er vaak maar één gebruikersinterface wordt ontworpen. Oftewel, op zowel Android, iPhone en Windows Phone ziet de app er hetzelfde uit voor gebruikers. Vaak wordt er gekozen voor een nieuw interface dat niet lijkt op een van de drie, maar los staat van ieder besturingssysteem. Dat betekent dat gebruikers zich niet 100% zullen herkennen in het interface een hieraan zullen moeten wennen. Als laatste zal de automatische vertaler niet alle functies kennen. Stel, je wil van het betalingssysteem van Apple gebruik maken voor je app, dan zul je in veel gevallen een aanpassing moeten schrijven op de automatische vertaler voor alleen het Apple platform. Dat verkleint de beoogde beheersbaarheid en zorgt dat het implementeren van nieuwe functies langzaam kan gaan.

Dus, cross-platform app-ontwikkeling:
- maakt je app beheersbaarder;
- is betaalbaarder;
- heeft een kortere ontwikkeltijd, máár;
- vermindert het gebruiksgemak voor de eindgebruiker;
- nieuwe functies laten op zich wachten.

Een gebrek aan gebruiksgemak kan leiden tot frustratie bij de eindgebruiker. Uit ons eigen onderzoek blijkt dat frustratie met een app niet alleen zorgt voor de-installatie maar tegelijkertijd ook de belangrijkste reden is om naar een concurrerende app op zoek te gaan. Verder weten we dat gebruikers als ze op zoek gaan naar een app, vooral kijken naar het "nut" ervan: de toegevoegde waarde in de ogen van de gebruiker. Dit nut is een logisch gevolg van bestaande en nieuwe functies van een app.

Een bedrijf dat daar last van had was Rabobank. In het verleden lanceerden ze een nieuwe app die was gebaseerd op een cross-platform ontwikkelmethode. Binnen de kortste keren regende het klachten van gebruikers die o.a. op internet hun mening uitten. Hun meningen? De app was trager geworden, het interface was niet handig en functies die ze voorheen wel hadden waren nu verdwenen. Daar kwam nog eens bij dat doordat Rabobank een nieuw interface introduceerde waardoor mensen erg onwennig waren met hun app. En dat terwijl een bank juist vertrouwen en degelijkheid zou moeten uitstralen. Alles bij elkaar een problematische situatie voor de Rabobank, terwijl hun mobiele applicatie een steeds belangrijker contactpunt met de klant is. De concurrenten van Rabobank zaten ondertussen ook niet stil, zo was de ING al bezig met nieuwe "nuttige" functies, zoals een smartwatch uitbreiding van haar app en betalingsverzoeken. De cross-platform app-ontwikkeling heeft dus Rabobank's concurrentiepositie ondermijnd.

Eerlijk is eerlijk: de oud Rabobank app was ook gebaseerd op een cross-platform ontwikkelmethode en tot de vernieuwing ervan werkte deze app prima. Rabobank is een logge en bureaucratische organisatie, dus er is waarschijnlijk is er ook iets intern fout gegaan. Tegelijkertijd wil ik je laten zien wat de voor- en nadelen zijn van een cross-platform app-ontwikkeling en waar je op moet letten.

Gaat het zo lukken om een beslissing te maken?

Met vriendelijke groeten,

-David

He Jeroen,

Ik moet zeggen dat ik Xamarin al een tijdje niet meer bekeken had, maar het blijkt dat zij vanaf mei vorig jaar inderdaad de mogelijkheid hebben een apart Android en iOS design te maken binnen hun platform. Dan wordt inderdaad een deel van het cross-platform app-ontwikkeling probleem opgelost. Wellicht zit je dan wel nog met een relatief trage app en beperkte mogelijkheden om nieuwe functionaliteiten toe te voegen.

Als je wil weten of de traagheid een probleem gaat worden, doe dan het volgende. Test met een oude of goedkope Android mobiel of de apps die een Xamarin developer al heeft gemaakt snel genoeg werken. Oude of goedkope toestellen zijn natuurlijk altijd trager, dus vergelijk met een aantal apps die er al op staan.

Als het gaat om de vraag of je genoeg nieuwe features kunt toevoegen: maak een zogenaamde MoSCoW analyse van je app. Hierin verdeel je de functies die je wil hebben of ooit wil laten maken in Must haves, Should haves, Could haves en Won't haves (vandaar de afkorting MoSCoW). Oftewel: zaken die essentieel voor het werken van je app (Must haves), dingen die er eigenlijk wel in moeten zitten maar niet essentieel zijn (Should haves), dingen die je wel leuk vind maar ook makkelijk uit je app gelaten kunnen worden (Could haves) en dingen die je in ieder geval niet gaat doen (Won't haves). Neem deze functionaliteiten mee naar het gesprek met de ontwikkelaar en vraag of deze ontwwikkeld kunnen worden in Xamarin. Mocht het zo zijn dat er enkele Could haves niet mogelijk zijn, dan is dat geen ramp. Maar als er Must haves of Should haves niet mogelijk zijn, dan moet je je achter het oor krabben. Zitten er beperkingen in Xamarin waar je niet omheen kan maar die in je Won't haves staan? Dan is cross-platform app-ontwikkeling met Xamarin waarschijnlijk niet voor jou.

Hopelijk ben je hiermee verder geholpen :)

-David