Een mobile app laten ontwikkelen, wat komt daar bij kijken?

Ik wil een app laten ontwikkelen… wat nu?

Eén van de minder bekende diensten die WordXPression aanbiedt (bewust) is het ontwikkelen van mobile apps. Eén van de redenen, dat ik er de laatste jaren niet mee te koop heb gelopen is vooral omdat de acquisitie voor een ‘mobile app’ project veel meer tijd en energie kost dan de acquisitie voor een WordPress website. Dat heeft niets te maken met het feit, dat het moeilijk is om willende klanten te vinden, maar meer met het feit, dat het moeilijk is om klanten te vinden die ook weten wat ze willen. Want een mobiele app laten ontwikkelen valt niet echt mee…

Voor veel ondernemers is een ‘eigen app’ de heilige graal naar een ongebreidelde bron van inkomsten. In 2015, toen ik begon met de ontwikkeling van apps en dit in een -inmiddels niet meer bestaande- blogpost aankondigde kreeg ik ongeveer 20 vragen per maand voor het ontwikkelen van een app voor ‘BMI’ (Body Mass Index). Gewichtsconsulenten, Personal Trainers, Health Consultants, Sportschool eigenaren en andere mensen die ook maar iets te maken hadden met gezondheid en gewicht, dachten dat het ontwikkelen van een ‘BMI app’ toch wel een geweldige manier was om zichzelf als expert te profileren.

Destijds bleek uit een simpele zoekopdracht in de Google Play Store, dat er destijds al meer dan 300 ‘BMI calculators’ waren. Ik heb er geen flauw idee van, hoeveel het er nu zijn.

Na deze ervaring besloot ik om toch iets minder tijd te besteden aan de acquisitie voor apps. En het aanbod om apps te ontwikkelen beperkte ik eigenlijk vooral tot klanten die met hun door mijn gebouwde websites al behoorlijk wat succes hadden en dit uit wilden breiden. ‘Denk je niet, dat een app een goede vervolgstap zou kunnen zijn?’

Maar mobile apps ontwikkelen is leuk. Echt! Het spreekt mijn professionele ICT-er hart aan. En wanneer iemand een mobile app wil laten ontwikkelen en werkelijk een goed idee heeft, waarom zou ik die persoon dan niet op weg helpen?

En dat is de reden dat ik deze blogpost heb geschreven voor al die mensen die denken over een mobile app te laten ontwikkelen. Zie het als een soort zeef. Ik probeer 90% van de lezers te ontmoedigen om het te doen, maar die 10% die na het lezen van mijn artikel nog steeds interesse hebben… daar kom ik graag mee in contact.

1. Benoem het zakelijke doel van je app

Wat wil je eigenlijk zakelijk met je app bereiken. Om even terug te komen op de BMI-calculator geïnteresseerden die ik heb gesproken… het zakelijke doel van hun app was vooral om meer bekendheid te krijgen. En op zich, daar is natuurlijk niets mis mee. Het doel van deze ondernemers hun app-idee was ok, maar het middel wat ze in wilden zetten niet.

Eén van de redenen dat ik nog geen ‘WordXPression app’ in de app stores heb staan is vooral, omdat ik geen enkel zakelijk doel voor zo’n app kan bedenken. Wat kan ik bieden met zo’n app? Wanneer ik kijk naar mijn doelgroep, dan weet deze mij toch ook nu al goed te vinden. Ook mobiel.

De ‘meerwaarde’ van een app zou kunnen zijn, dat mijn trouwe lezers een ‘push bericht’ zouden krijgen, wanneer er een nieuwe blogpost zou zijn. Maar dat is ook op andere manieren te realiseren, zoals in ‘browser push berichten‘, die ook op je mobiel verschijnen, wanneer je daar om vraagt.

Mocht jij wel interesse hebben in een app met de blogposts van WordXPression, en er zijn genoeg mensen zoals jij, dan ben ik heel erg bereid de app (hij is klaar, alleen niet gepubliceerd) beschikbaar te stellen. Laat het weten in de commentaren hieronder en bij 50 commentaren zal ik mijn app alsnog publiek maken, maar voorlopig zie ik geen meerwaarde in mijn app.

Wat zijn zakelijke doelen

Wil je een app laten ontwikkelen, dan zal je ook goed voor de bril moeten hebben, wat een ‘geldig’ zakelijk doel is. Vandaar enkele voorbeelden

• Grotere naamsbekendheid
  Dat is een reden, waarom ik zou kunnen overwegen om mijn ‘WordXPression app’ ooit te publiceren. Wanneer meer mensen mijn blog lezen, of mensen vaker mijn blog zouden bezoeken, is dat een geldig zakelijk doel.
• Meer omzet
  Ok, dat is natuurlijk het ultieme zakelijk doel. Daar zijn we allemaal toch ondernemer voor geworden, nietwaar?
  Meer omzet kan je bijvoorbeeld behalen, door nieuwe markten aan te boren. En een voorbeeld van een nieuwe markt aanboren is door jouw productaanbod aan te bieden aan een doelgroep die het liefst ‘per app’ winkelt.
  In 2012, toen ik begon met het ondersteunen van WooCommerce, kreeg ik nog heel vaak te horen ‘mijn publiek koopt niet online’. Zelfs zonder COVID was dit in 2019 al niet meer waar. Meer dan 60% van grote aankopen werd toen al online gedaan. Tijdens COVID is dit percentage gestegen, en omdat we er aan gewend zijn geraakt, zal straks na COVID dit percentage niet veel omlaag gaan.
  Ons jongere publiek doet steeds meer met de mobiel en steeds minder met de ’traditionele’ computer. Wil je dat publiek (blijven) bereiken is niet alleen een mobiele aanwezigheid, maar liever nog een eigen ‘e-commerce app‘ een belangrijke investering in de toekomst van je bedrijf.
• Een aanvullend product. Zoals eerder aangegeven, een BMI calculator om aandacht te krijgen als gewichtsconsulent is niet echt een goed idee, maar een app aanbieden aan een bestaande klantengroep weer wel. Op deze manier onderscheidt je je van je concullega’s. Hierbij kun je aan een aantal zaken denken, zoals bijvoorbeeld een ‘logboek’ voor je klanten op de app, waar ze periodiek gegevens rond gewicht e.d. bij kunnen houden. Of dagelijkse recept ideeën om toch lekker te blijven eten. Jouw app is dus niet direct een ‘promotiemiddel’ om ‘via de appstore’ nieuwe klanten te krijgen, maar een goede ondersteuning van diensten die je aanbiedt aan bestaande klanten.
  

Heb je zo’n zakelijk doel benoemd, dan is het een goed idee om verder te kijken. Want een mobiele app laten ontwikkelen vraagt om nog heel wat meer beslismomenten.

2. Besluit voor welke platforms je wilt laten ontwikkelen

Wanneer ik een klant vraag voor welk platform deze een app wil laten ontwikkelen, dan kan ik het antwoord al voorspellen.

‘Allemaal!’

Dat kan een goed idee zijn, maar hoeft niet altijd zo te zijn. Vandaag de dag (April 2021) gebruikt iets meer dan 27% van de mensen iOS, bijna 72% gebruikt Android en de resterende ongeveer 1% gebruikt ‘iets anders’. In Nederland gebruikt een wat groter percentage iOS (iets meer dan 39%) en een wat kleiner percentage Android (bijna 60%), maar hoe je het ook bekijkt, Het is de moeite niet, om tijd en energie te steken in iets wat geen Android of iOS is.

Maar zelfs dan is het de vraag, of je inderdaad voor beide platforms wilt laten ontwikkelen. En dat is afhankelijk van twee factoren:

Welke platform gebruikt het grootste deel van je klanten?

De keuze voor een mobiele telefoon is tegenwoordig niet alleen een ‘apparaat keuze’, maar ook een ‘lifestyle’ keuze. Wanneer je bijna geen klanten hebt, die één van de beide platforms gebruiken, wil je dan werkelijk tijd en geld investeren in een app voor dat platform?

Is jouw type app toegestaan op het platform?

Apps worden doorgaans geïnstalleerd via de Apple app store of Google Play. En beide stores hebben hun regels over wat er wel en niet mogelijk is, waarbij in de meeste gevallen Apple de meest restrictieve regels heeft, maar in sommige gevallen kan ook Google Play de spelbreker zijn.

Verkoop je bijvoorbeeld tabaksartikelen online dan zie je al snel jouw app ideeën in rook opgaan, omdat beide stores hier beperkingen aan gesteld hebben. Heb je een webwinkel met ‘speelgoed voor volwassenen’, dan kan het een harde dobber worden om je app bij Apple goedgekeurd te krijgen.

Kortom, doe je marktonderzoek voor je met de daadwerkelijke ontwikkeling van je app begint.

Soms kan je de regels een beetje buigen. Zo moest bijvoorbeeld de Staatsloterij onlangs hun app aanpassen, omdat ‘kansspelen online’ niet meer mag in de Google Play store, maar je kan nog steeds de uitslagen controleren en je gekochte loten (online via het web of in de winkel) vanuit de app controleren. Apple schijnt minder moeite met ‘online kansspelen’ te hebben.

Laten we er vanuit gaan, dat je mobiele app laten ontwikkelen nog steeds een goed idee lijkt, en je besluit het op beide platforms te willen doen. Waar loop je dan tegen aan?

3. Native app of niet?

De volgende keuze die je zal moeten maken, is of je wel of geen ‘native app’ wilt laten ontwikkelen. Een ‘Native app’ is een app die geschreven is in een programmeertaal die voor het specifieke app platform is bedoeld. Voor iOS zijn Object-C / X-Code en Swift. Voor Android zijn dat Java en Kotlin.

De voordelen van een native app

Wanneer je een native app ontwikkelt, dan weet je zeker, dat je toegang tot alle ‘kenmerken’ van de telefoon hebt. De taal en het besturingssysteem zijn namelijk helemaal op elkaar afgestemd. Ook kan je ervan uitgaan, dat er geen ‘overbodige ballast’ meekomt in de programmeertaal, waardoor de app zeer snel zal reageren, en vaak met een relatief laag geheugengebruik.

De nadelen van een native app

Omdat het twee totaal verschillende omgevingen zijn, betekent het eigenlijk dat je niet één, maar twee apps laat ontwikkelen. Dat is niet alleen financieel kostbaar, maar het zal je ook meer tijd kosten in overleg met je ontwikkelaar(s). Bovendien krijg je twee apps die je moet gaan onderhouden.

Of het helemaal waar is weet ik niet, maar van een klant die zelf een mobiele app heeft laten ontwikkelen, kreeg ik te horen, dat ’twee apps driemaal zoveel kost als één app’.

Wanneer is een native app wel een goede keuze?

Een 100% native app is niet alleen een goede, maar zelfs de beste keuze, wanneer je besloten hebt dat -gezien je doelgroep of je marketing mogelijkheden via de stores- maar voor één platform wilt gaan ontwikkelen. Denk je over twee verschillende platforms, dan heb je een aantal andere mogelijkheden.

4. De keuze van een ‘platform onafhankelijke ontwikkel tool’

Een mobiele app laten ontwikkelen wil zeggen, dat je moet kiezen. En vaak moet kiezen. Heb je de keuze voor een ‘platform onafhankelijke ontwikkeling’ gekozen, dan ben je er nog niet. Want dan komt de volgende keuze. En die volgende keuze zal je zelf moeten maken, omdat jouw ontwikkelaar je meestal de tool zal adviseren, waar hij of zij bekend mee is.

Wat is een ‘platform onafhankelijke ontwikkel tool’?

Het probleem van ‘meerdere platforms’ speelt al sinds de tijd van de eerste smartphones. Het zal je dan ook weinig verbazen, dat er al heel vroeg werd nagedacht over manieren om een omgeving te ontwikkelen waar je door één keer te programmeren voor meerdere platforms kan ontwikkelen.

En er zijn letterlijk tientallen tot honderden van dit soort platforms, waarbij overigens veel platforms een ‘spinn off’ van een ander platform zijn.

In deze blogpost beperk ik mij tot een aantal van deze platforms die zich kunnen verheugen op een groot marktaandeel. Dit om twee redenen. Of eigenlijk maar één. Continuïteit. Maar die continuïteit uit zich op twee manieren.

Technische continuïteit

De techniek in- en achter mobiele telefoons ontwikkelt zich razendsnel. En ‘Build once, deploy until armageddon’ werkt niet. Zelfs wanneer je niets aan je app aanpast, zal je in ieder geval iedere paar jaar een nieuwe versie moeten uploaden, omdat de nieuwste veiligheidsprotocollen geïmplementeerd moeten worden, of anders verdwijnt jouw app uit de store.

Je zal er dus op moeten kunnen vertrouwen, dat over twee, drie of vijf jaar het platform waarop jouw app is gebouwd, nog steeds zal bestaan.

Organisatorische continuïteit

Je wilt voor jouw app niet afhankelijk zijn van je app bouwer. Mocht je op een gegeven moment niet meer met hem of haar door één deur kunnen, dan wil je met de source code van de app naar een andere dienstaanbieder kunnen lopen.

Maar stel nu, dat jouw app builder de enige ontwikkelaar in Europa is die gebruik maakt van de (denkbeeldige) Monkey Face Multi Platform App Builder’.

Dan kan je hem of haar nog steeds geen ‘vaarwel’ zeggen, omdat er geen ander alternatief is.

Zorg dat je de tool ‘kent’

Natuurlijk. Je hoeft niets te weten over de ontwikkel tools die jouw app bouwer gebruikt, maar zorg wel, dat je weet welke tools hij of zij gebruikt en weet in ieder geval of het populaire tools zijn.

Durf ook te vragen waarom je ontwikkelaar die tools gebruikt.

De tools

PhoneGap / Cordova

Van de bekende multi platform tools is denk ik PhoneGap wel de meest bekende. PhoneGap werd later overigens ‘hernoemd’ naar ‘Cordova’.

Het trieste van PhoneGap is eigenlijk, dat het altijd een ‘stiefkind’ van grote bedrijven is geweest. Eén van de redenen dat op dit moment ‘PhoneGap/Cordova’ een zachte dood is gestorven, nadat Adobe het project bij Apache te vondeling heeft gelegd. Het idee achter Cordova was echter geniaal en talloze ‘online app builders’ zijn op dit idee gebaseerd. Dus het is zeker de moeite waard om hier enige aandacht aan te geven.

Het grote idee achter PhoneGap was, dat het platform van je app niet uitmaakt, maar ieder platform wel een ‘browser’ component heeft om HTML, CSS en JavaScript in te laten zien.

Waarom zou je dan geen apps bouwen die eigenlijk uit niet veel meer bestaan dan een schermvullend browser window, waarin een ‘webapp’ wordt afgespeeld?

Voorzie die ‘webapp’ van de nodige bibliotheken om een ‘Mobile App look and feel’ te garanderen, en je hebt een prima platform voor app development.

De voordelen van PhoneGap/Cordova

De voordelen van deze aanpak zijn evident. Met een drietal technologieën die de gemiddelde webdeveloper sowieso beheerst kan je apps maken die voor alle platforms geschikt zijn. En wanneer ik zeg ‘alle’, bedoel ik ook letterlijk ‘alle’.

Ik heb tot en met 2017 Cordova apps ontwikkeld. In 2012 -toen ik her mee begon- ondersteunde ik ook het Windows en het Blackberry platform… want dat was niet veel meer dan een extra ‘vinkje’ (of eigenlijk het woordje ’true’ in de output configuratie bestanden) bij het ontwikkelen van de app.

De nadelen van Phonegap/Cordova

De nadelen zijn even evident. Ten eerste, het is een behoorlijk avontuur om in een Cordova app toegang te krijgen tot de hardware van de telefoon. Sommige elementen (GPS, Camera) waren makkelijk toegankelijk, maar andere vormden een compleet avontuur

Een tweede nadeel is de performance. De schermopbouw van een Cordova app is duidelijk anders, dan die van een native app. Met name op telefoons met minder intern geheugen, was de ‘lag’ best merkbaar.

En als derde nadeel: Cordova maakte WEB apps, geen NATIVE apps. De userinterface van een gemiddelde Cordova app is consistent over alle platforms, maar wijkt af van wat een gebruiker van het platform gewend is.

Ionic

Ionic is een complete mobile app development platform gebouwd op Cordova en Angular JS, een web-app development platform oorspronkelijk ontwikkeld door Google, maar inmiddels 100% Open Source.

Ionic komt tegemoet aan veel van de hierboven genoemde nadelen van Phonegap/Cordova.

Het Ionic platform biedt veel tools om de productie te verbeteren. Maar daar heb jij als klant weinig aan, tenzij jouw ontwikkelaar dit ook in de prijs van de app laat zien. In de voor- en nadelen laat ik alleen de voor- en nadelen voor jou als klant zien.

De voordelen van Ionic

Het is makkelijker platform specifieke toegang tot hardware te implementeren. Als klant heb je dus meer mogelijkheden.

De nadelen van Ionic

Ionic is alles behalve snel. Voor een ontwikkelaar is Ionic een geweldige omgeving om apps te ontwikkelen, omdat het behoorlijk snel is om dit te doen. In PhoneGap/Cordova moest de ontwikkelaar in ieder geval nog zelf de source bestanden schrijven, wanneer hij gebruik maakt van Ionic Studio, is dit nu een drag- en drop kwestie geworden.

En dit is precies de grootste kritiek tegen Ionic. Je kan makkelijk apps maken die niet vooruit te branden zijn, maar wanneer ik een app in Ionic zou willen maken met een goede performance, dan moet ik de helft van de productivity tools negeren, en goed gebruik maken van de performance tools die Ionic biedt.

Voor jou als klant wil het eigenlijk zeggen, dat een Ionic app langzaam en voordelig, of snel en duur is.

Heb je geen problemen met langzaam, is Ionic een goed platform voor je. Maar als je met ‘duur’ OK zou zijn, dan is het volgende platform wellicht een betere optie.

React Native

React Native is een app ontwikkel platform gebaseerd op React.

React is een web front-end platform ontwikkeld door Facebook en ‘vrijgegeven’ als Open Source.

React Native is ook ontwikkeld door Facebook.

Toen Facebook besloot ook met apps te willen komen, ontdekten ze hetzelfde wat ik hierboven heb beschreven. Omdat Facebooks apps op meerdere platforms wilde hebben, moesten ze kiezen voor kosten-plus-complexiteit of weinig-kosten-en-traag

Maar wanneer je miljarden te besteden hebt, is een alternatief antwoord : ‘F*** you, we’ll do it better’.

En dat heeft Facebook eigenlijk prima gedaan met React Native.

Ik wil niet teveel ingaan op de voordelen van React, de relatie met React Native en dus de voordelen van React Native, maar een aantal belangrijke dingen wil ik toch aankaarten.

React Native heeft eigenlijk een evenwicht gevonden tussen ‘Platform specifiek’ en ‘Multi platform’

Op eigenlijk een heel simpele manier. Het grootste deel van de tijd waarmee een app bezig is, is met het ’tekenen’ (renderen) van de User Interface.

React Native gebruikt de ‘native’ API voor het tekenen van de user interface. Dus de snelst mogelijke manier voor de app.

Het meest complexe onderdeel van een app zijn de ‘business rules’. Die zijn lastig te vertalen naar ‘native instructies’.

React Native apps hebben een ‘JavaScript interpreter’ ingebouwd, om de ‘native instructies’ te vertalen.

Voor meer info, verwijs ik je graag naar WordXPression’s pagina over app ontwikkeling.

Deze formule sloeg aan. Niet alleen omdat het voordeliger was omdat je met één ‘source code’ meerdere platforms kon bereiken, maar ook omdat je met dezelfde technologie complete websites kan bouwen.

Om je een voorbeeld te geven van de mogelijkheden met React… bedrijven als ‘Netflix’, ‘LinkedIn’, ‘Coursera’, de meeste Nederlandse banken en natuurlijk -als uitvinder- Facebook hebben hun sites en apps gebouwd gebruikmakend van dezelfde technologie.

Voordelen React Native

Multi platform apps met een zeer goede performance. Bovendien is het mogelijk om met dezelfde technologie een ‘gewone interactieve website’ te laten bouwen.

Nadelen React Native

React Native is vooral geschikt voor het presenteren van informatie. Voor apps met een sterk grafische interface (zoals games) of voor apps waarin veel gerekend moet worden, is React Native minder geschikt.

Flutter

Wie wil er een app laten bouwen via een platform met een naam als ‘Flutter’? Alleen de naam al heeft mij twee jaar lang gestopt dit platform serieus te nemen. Flut… flutter… flutst… het kan niet goed zijn!

Het is duidelijk dat de marketing afdeling van Google geen Nederlands sprak. Want anders zouden ze zeker een andere naam hebben gekozen.

Eigenlijk is ‘Flutter’ absoluut niet de vergrotende trap van ‘Flut’, want wat Flutter ook is, het heeft niets met ‘Flut’ te maken!

Eigenlijk is ‘Flutter’ de overtreffende trap van ‘React Native’.

Een nadeel van React Native is, dat er geen ‘visuele ontwikkel omgeving’ is. Voor jou als afnemer niet zo belangrijk, maar bij grote apps kan React Native nogal tijdrovend zijn. En dat vertaalt zich meestal naar een hogere prijs voor het eindproduct.

Wil je een mobiele app laten ontwikkelen, dan speelt de ontwikkeltijd voor de app natuurlijk een grote rol.

Flutter is een ‘plugin’ voor Google’s Android Studio, een visuele ontwikkelomgeving voor apps (waarbij overigens ook het nodige hand-gecodeerd moet worden).

Dus een enorme productiviteitswinst.

Zelf ontwikkel ik tegenwoordig alleen nog maar in Kotlin (voor Android Native apps), React Native en Flutter (voor dual platform apps), waarbij voor kleinere apps ‘React Native’ en voor grotere projecten ‘Flutter’ mijn voorkeur heeft.

Voordelen Flutter

Snelle apps en een goed projectbeheer.

Nadelen Flutter

Behoorlijk wat overhead in the set up voor kleinere projecten.

Online app generators

Naast al het bovengenoemde is er ook een groot aantal sites waar je door enkele parameters in te geven zelf een online app kan genereren en downloaden. Vaak kan je voor enkele tientjes je ‘eigen app’ bouwen.

Wat hier feitelijk gebeurt is dat op de achtergrond een PhoneGap/Cordova app wordt gebouwd. Deze app zal ongetwijfeld werken op beide platforms, maar toch een waarschuwing hier.

De meeste van dit soort sites zal niet willen dat je na het ‘bouwen’ van je app verder onafhankelijk van het bent. Dus je zal meestal wel direct een binair bestand voor de app kunnen downloaden, maar de source code zelf is niet beschikbaar. Je bent dus voor de rest van het app-leven afhankelijk van dit platform. Bovendien heb ik in de loop der jaren dit soort platforms zien verschijnen en verdwijnen.

Voordelen app generators

Zonder veel complexiteit een app voor relatief lage kosten

Nadelen app generators

Relatief trage apps omdat in negen van de tien gevallen het hier om Cordova implementaties gaat.

Geen eigendom van de sourcecode, waardoor je een hoge mate van afhankelijkheid hebt.

Geen garantie met betrekking tot de continuïteit.

Beperkt mogelijke functionaliteiten.

5. De gegevenskoppeling

Niet iedere app hoeft te ‘koppelen’ met gegevens, maar alle apps die ik ontwikkel doen dat wel. En van de offertes die ik van nieuwe klanten voor apps te zien heb gekregen, heb ik wel gemerkt, dat de ‘gegevenskoppeling’ tussen een app en andere gegevens puur wild-west is.

Ik heb letterlijk offertes gezien waarbij de ‘gegevenskoppeling’ varieerde van 2 tot 5 maal de ontwikkeling van de rest van de app!

Is dat terecht?

Soms wel. Maar meestal niet. Met de huidige mogelijkheden tot het koppelen van gegevens hoeft een ‘gegevenskoppeling’ helemaal niet duur te zijn, maar dat is afhankelijk van de gekozen technologie. En het probleem is, dat de gemiddelde app ontwikkelaar geen idee schijnt te hebben met betrekking tot beschikbare technologieën.

WP REST

Niet de beste, maar wel een goede manier van gegevenskoppeling met WordPress is via WP REST. Het is letterlijk ‘ingebouwd’, dus als ontwikkelaar hoef je er weinig voor te doen. Wil ik bijvoorbeeld jouw blogposts zichtbaar maken in jouw app, dan kost mij hooguit een half uur.

GraphQL

Het nadeel van WP REST is echter, dat het niet super snel is, en behoorlijk wat geheugen kost. Een alternatief is een andere techniek, GraphQL genoemd. GraphQL is -op een WordPress site- ongeveer 10x zo snel om gegevens op te halen.

En het kost mij ca. 2-3 uur extra om te implementeren in een app.

Waarom dan zo duur?

Persoonlijk denk ik, dat het grootste probleem met veel app ontwikkelaars is, dat ze prima app ontwikkelaars zijn, maar geen kaas hebben gegeten van WordPress. En dus weten ze niet, op welke manieren ze WordPress met jouw app kunnen laten ‘praten’. En om dit probleem te omzeilen, gaan ze voorbij aan WordPress en ‘koppelen’ direct aan de database voor het ophalen van informatie.

En het ontwikkelen van een complete interface met de database is inderdaad heel tijdrovend.

Jouw app ontwikkelaar probeert opnieuw het wiel uit te vinden. Er van overtuigd, dat er betere alternatieven zijn dan een rond wiel.

Wanneer we het hebben over een standaard WordPress website of een standaard WooCommerce website, dan biedt de REST API eigenlijk al alle informatie aan, die nodig is om je app met gegevens te vullen. Afhankelijk van de drukte op je website misschien niet direct op de snelste manier, maar een directe databasekoppeling is hier niet de antwoord op je probleem. Wat een ‘redelijke tijd’ is, om heea te implementeren zie je in de kopjes hierboven.

6. Wat is app specifiek?

Iets eerder in dit artikel hebben we het gehad over een voorbeeld waar een klant een persoonlijke log bij kan houden over de resultaten voor bijvoorbeeld afvallen.

Dit zijn app specifieke gegevens. Dit wil je niet opnemen in je website.

Waar je serieus met je app ontwikkelaar over in gesprek zal moeten gaan is hoe en waar deze gegevens worden opgeslagen.

Je hebt hier in principe twee keuzes. En beide keuzes hebben hun voor- en nadelen.

App specifieke informatie opslaan in de WordPress backend.

Eén manier is natuurlijk om de informatie op te slaan in de WordPress backend. Gezien de eenvoudige manier om in WordPress extra ‘Custom Post Types’ aan te maken, is dat een voor de hand liggende optie. De app developer moet dan echter wel het één en ander van WordPress weten om dit te kunnen realiseren.

App specifieke informatie elders opslaan

Ook een geldige optie. Maar voor jou als gebruiker van de app betekent dit wel, dat je twee applicaties moet gebruiken om de informatie te beheren.

7. Performance

We hebben het eerder over performance gehad, toen we puur naar de app op zichzelf keken, de performance die jouw app ‘van nature vertoont’.

Er is echter ook een tweede performance factor, die een belangrijke rol speelt. De performance van het ‘binnen halen’ van gegevens.

Hier is je performance van een aantal verschillende factoren afhankelijk. Allereerst de performance van de app zelf, maar hier hebben we het uitgebreid over gehad. Door het kiezen van het juiste ontwikkelplatform kunnen we daar een grote invloed op uitoefenen.

De tweede factor is de netwerk performance. Heel simpel kan je eigenlijk stellen, dat je zo min mogelijk data ‘door de lucht’ wil laten gaan. Maar door slim gebruik te maken van WP REST of GraphQL kunnen we dat eigenlijk tot een minimum beperken.

De derde vorm van performance is echter je server performance. En hier kan mogelijk serieus aan gewerkt moeten worden.

Netwerk verkeer verminderen

Ik heb iets eerder WP REST en GraphSQL genoemd. In dit deel van het artikel wil ik je heel kort het verschil tussen deze twee oplossingen uit de doeken doen.

WP REST is een methode om posts in WordPress makkelijk via een ‘speciale interface’ op te kunnen vragen. Het probleem is hier echter, dat ik altijd alle informatie over dat specifieke object zal ontvangen.

Stel dus bijvoorbeeld, dat ik een webshop heb. En voor die webshop wil ik een pagina vol producten opvragen. Ik vraag dus -bijvoorbeeld- de 12 eerste producten in een categorie op. En WP REST zal mij netjes die eerste twaalf producten geven.

Van die producten wil ik mogelijk alleen de titel, prijs, foto en URL naar het product tonen. Daar heeft WP REST geen boodschap aan: Ik krijg alle producten. Dus heel wat data, die ik eigenlijk niet nodig heb.

GraphSQL doet het iets anders. Ik kan namelijk op voorhand opgeven, welke informatie ik wil zien. Bijvoorbeeld de titel, prijs, url naar de afbeelding en de url naar het product.

De informatie die ik dus krijg is dus veel compacter en zal ook sneller over het netwerk gaan en sneller worden geladen.

Eenzelfde verhaal hebben we eigenlijk met de foto’s. Dit probleem kan je echter een stuk makkelijker oplossen. WordPress maakt foto’s in een aantal verschillende afbeeldingen aan. De foto’s die je nodig hebt voor je shop app zullen waarschijnlijk afwijken van de formaten die sowieso al worden aangemaakt, maar zoals je in mijn artikel over afbeeldingen in WordPress kan lezen, deze extra formaten kunnen relatief makkelijk worden toegevoegd. En kleinere afbeeldingen is minder netwerkverkeer.

Server belasting verminderen

Heb je echt een heel druk bezochte webshop, dan is er nog een manier om je performance -althans voor de apps- behoorlijk op te waarderen.

Want laten we eerlijk zijn, de hele monolithische aanpak van WordPress is inmiddels toch een wat verouderde technologie. Iets meer ‘eigentijds’ is echter behoorlijk wat lastiger te implementeren. Het aardige van de monolithische aanpak met Linux/Apache/MySQL/PHP is namelijk dat er 1. veel Open Source software voorhanden is en 2. Het heel voordelig te hosten is.

Er zijn echter andere alternatieven. En één van die alternatieven is ‘Node.JS’.

Node.JS

Node.JS is een omgeving om JavaScript programma’s te schrijven. Maar dan wel helemaal buiten de browser om. En Node.JS is razend populair geworden, waardoor er heel wat aanvullende bibliotheken voor Node.JS zijn.

En één van die dingen, die je eigenlijk heel eenvoudig met Node.JS kan maken is een ‘lichtgewicht webserver’.

Laat ik je het verschil tussen ‘Apache’ -de meest gebruikte webserver voor het Internet- en een Node.JS server eens heel eenvoudig uitleggen.

Restaurant Chez Apache

Wanneer we de Apache webserver zouden willen vergelijken met een restaurant, dan is wellicht de beste vergelijking die met een zeer exclusief restaurant, waar iedere tafel zijn eigen kelner heeft. Op het moment dat jij je bestelling plaatst, loopt jouw persoonlijke kelner naar de keuken en wacht daar tot jouw eten klaar is, om het vervolgens naar jouw tafel te brengen.

Heb je een voorgerecht bestelt, maar besluit je voor dat dit voorgerecht klaar is, dat je toch nog iets vooraf wilt drinken, dan is dit niet mogelijk, omdat jouw persoonlijke kelner nog steeds in de keuken staat te wachten voor je maaltijd.

En hoewel een dergelijke persoonlijke bediening best behoorlijk exclusief is, heeft deze bediening toch ook een aantal nadelen.

Allereerst is het wel een heel dure manier van bedienen. Want je kelner staat wel heel veel van zijn tijd niets te doen. Bovendien zal het ook best heel druk zijn met al die kelners die over de vloer van het restaurant rondlopen om hun tafeltje te bedienen. En tenslotte… het is ook weinig efficient. Want zodra je een bestelling hebt geplaatst moet je wachten tot deze is uitgeleverd, voor je een volgende gang, of iets te drinken kan bestellen.

Grand Café au Node

In Grand Café au Node gaat het er wat anders aan toe. Er is slechts één kelner die van de éne klant van de andere klant loopt, bestellingen doorgeeft aan de keuken, terug gaat om de tafeltjes te bedienen en wanneer er iets klaar is in de keuken, dit naar de klant brengt.

Soms moet je als klant even wat langer wachten, omdat de kelner druk bezig is met iets anders, maar gemiddeld genomen wordt je snel geholpen.

Multi-proces vs. Single Thread

Het plaatje wat ik hierboven schets is eigenlijk ook hoe het werkt met een een Apache webserver vs. een Node webserver. Apache is een zogenaamde ‘Multi Proces’ webserver. Dat wil eigenlijk zeggen, dat voor iedereen die verbinding maakt met de server een aparte kopie van Apache wordt opgestart. Apache zal vervolgens de verzoeken van die ene bezoeker één voor één afhandelen, tot op het moment, dat de verbinding wordt verbroken, en het proces vrijkomt voor een volgende bezoeker.

Dit heeft een tweetal nadelen. Het eerste is dat de totale duur van een proces groter of gelijk is aan de som van de individuele taken. Vraagt Apache bijvoorbeeld om antwoord bij de database, dan zal hij wachten tot dit antwoord is gegeven.

Node.Js werkt anders. Allereerst is Node een heel ‘lichtgewicht server’, omdat Node eigenlijk alleen geprogrammeerd wordt voor de taken die er uitgevoerd moeten worden. Vragen er meerdere bezoekers wat aan Node, dan zal er geen kopie voor iedere bezoeker worden opgestart, maar Node zal de taken ‘asynchroon’ afhandelen.

Vraag ik bijvoorbeeld om gegevens uit een database, dan zal Node de vraag doorgeven aan de database, en gelijk daarna een andere taak -voor mij of een andere bezoeker- uitvoeren. Komt het antwoord beschikbaar, pakt Node het weer op en geeft het antwoord aan mij door.

Op deze manier kan er heel wat werk verzet worden door een proces wat eigenlijk nog niet eens zoveel vergt van een server.

Het verkeer regelen

Wanneer je een webwinkel hebt, dan is het niet echt noodzakelijk, dat iedere aanpassing van gegevens direct beschikbaar is. Kijk je bijvoorbeeld naar het productaanbod, dan hoeft dat meestal niet direct a la minute ververst te worden. Met één mogelijke uitzondering. Je voorraad. Tenzij je letterlijk een onuitputtelijke voorraad van een product hebt, wil je die natuurlijk wel bijwerken.

Omdat de webserver voor jouw WooCommerce webshop heel wat harder moet werken (zie het verhaal over de restaurants hierboven), kan het een goed idee zijn om het ‘inladen’ van je producten uit te besteden aan een aparte ‘Node’ server. Periodiek ververst de node server het productaanbod en alleen wanneer een klant daadwerkelijk wil gaan kopen, of wanneer de klant de detailgegevens opvraagt, wordt er even kortstondig contact met de WooCommerce server gelegd, om te kijken, wat de voorraad is. Jouw app communiceert exclusief via de Node server en op deze manier ervaart jouw app gebruiker een enorm goede performance.

De ‘nadelen’ van deze oplossing

Het grootste ‘nadeel’ van deze oplossing is, dat het een extra ‘laag’ complexiteit toevoegt aan de opzet. Bovendien is het niet mogelijk om ‘Node.JS’ op een shared hosting account te gebruiken. Je hebt dus minimaal een VPS nodig. Dit nadeel is slechts betrekkelijk, want op het moment dat een Node.JS server een goed idee begint te worden, had je eigenlijk voor je webshop toch al een VPS nodig.

8. App marketing

In het eerste punt heb ik al aangegeven, dat het een goed idee kan zijn om een app in te zetten om meer naamsbekendheid te krijgen, maar dan moet je app wel een duidelijke meerwaarde bieden. Een tweede belangrijk punt is natuurlijk ook, dat die meerwaarde ook duidelijk moet zijn.

De kans dat je app ‘spontaan gevonden’ wordt in een app store is dus betrekkelijk laag. Houd er dus rekening mee, dat je jouw app op de één of andere manier zal moeten adverteren.

Wanneer je app een uitbreiding is op je bestaande dienstverlening, dan kan het ook goed zijn een advertentiecampagne op te zetten. Het kan beslist geen kwaad om bij jouw doelgroep onder de aandacht te brengen dat naast de ‘gewone’ dienstverlening, je nu ook ondersteuning per app aanbiedt.

Ga er niet zomaar vanuit dat je app ‘vanzelf’ wel gevonden gaat worden puur omdat deze bestaat. Bedenk dat er letterlijk miljoenen apps zijn en zowel Google als Apple de ‘meest gedownloade’ apps ook het meest zullen promoten. Wanneer jij helemaal aan het begin van het proces staat, zal je de nodige energie in je vindbaarheid moeten steken.

Hoe kan WordXPression jou helpen?

Ik ontwikkel apps. En bij de ontwikkeling hiervan maak ik gebruik van React Native, Flutter of Kotlin. Wanneer je dus op zoek bent naar iemand die een native app voor het iOS platform kan ontwikkelen, moet je niet bij mij zijn. Wanneer je echter op zoek bent naar apps waarmee je je zowel op Android als iOS wilt richten, dan zouden we best eens verder kunnen praten.

Wanneer je bovendien vanuit je app een integratie wilt met je webshop, blog of online leeromgeving, dan ben je bij WordXPression waarschijnlijk op het juiste adres. Neem eens contact op.