JacobFresco.nl

Web of Native: waar zet je op in?

Met de introductie van de iPhone in 2007 kwam de term ‘app’ in zwang. Vandaag de dag weet iedereen wat een app is en Apple-CEO Steve Jobs introduceerde het gezegde ‘There is an app for that‘. Het moet gezegd: de app is niet nieuw. Het is een afkorting van ‘application’, iets wat al veel langer kan op allerhande mobiele apparaten. Mensen die, zoals ik, vroeger een of meerdere PalmOS- of Windows Mobile-devices hebben gehad weten wat ik bedoel.

Met de huidige iPhone is het heel simpel om waar dan ook apps te downloaden en te installeren via de AppStore. De AppStore bestaat echter pas sinds de introductie van iOS 2.0 (toen nog iPhone OS 2.0). Voor die tijd bestonden enkel de zgn. webapps, speciaal voor dit doel geschreven websites. Op de iPhone is het mogelijk om een bookmark vanuit Safari (de browser op de iPhone) op het Springboard (Homescreen) te plaatsen. Indien de website hier rekening mee houdt ziet de website er bij het starten vanaf het Springboard uit als een app.

AppStore / Eigen distributie
Het gebruik van webapps is sinds de introductie van de AppStore drastisch gedaald. Maar toch kan het bepaalde voordelen hebben om gebruik te maken van een webapp in plaats van een native app. Mijns inziens het grootste voordeel van een webapp is het feit dat je als ontwikkelaar niet meer afhankelijk bent van de AppStore en de daaraan voorafgaande keuring van je app door Apple. Het is bekend dat Apple af en toe een nogal vreemd toelatingsbeleid hanteert als het gaat om applicaties in de AppStore. Door het gebruik van een webapp ‘omzeil’ je deze keuring omdat de webapps niet opgenomen worden in de AppStore. Het feit dat webapps niet worden opgenomen in de AppStore is dan gelijk weer een nadeel van het gebruik hiervan. De naamsbekendheid van je webapp valt en staat daardoor met de de mogelijkheden die je hebt voor marketing en PR.

Aan opname in de AppStore (native app) zijn echter kosten verbonden. Om de app in te dienen heb je een iOS Developper Enrollment nodig. Ook claimt Apple 30% van de omzet van betaalde apps. Hiervoor neemt Apple wel alle rompslomp voor z’n rekening (betaling, verrekening, facturatie, etc). Als je een betaalde webapp wilt uitbrengen zal je dit allemaal zelf moeten opzetten.

Programmeren
Een voordeel van webapps is dat er gebruik gemaakt kan worden van standaarden als HTML(5), CSS en Javascript. Hierdoor kan een web-ontwikkelaar vrij snel omschakelen naar het schrijven van een webapp. Nadeel van het gebruik van deze standaarden is dat er maar beperkt gebruik gemaakt kan worden van de functies van de iPhone (telefoon, GPS, versnellingsmeter). Ook multitouch is niet standaard beschikbaar. Er zijn frameworks beschikbaar die deze functionaliteit wel toestaan, maar die hebben gelijk een hele steile leercurve. Een native app wordt ontwikkeld in XCode, een IDE die ondersteuning biedt voor o.a. C, C++, Objective-C, Objective-C++, Java, AppleScript, Python en Ruby. Het zal duidelijk zijn dat deze talen een andere leercurve hebben. Er zijn wat alternatieven geweest voor XCode. Zo heeft Adobe in Flash Professional CS5 de mogelijkheid opgenomen om voor de iPhone te ontwikkelen. Apple heeft vrij snel daarop besloten om applicaties die niet in XCode ontwikkeld zijn niet meer toe te laten in de AppStore. Dit leverde een storm van protest op, waarna Apple zijn toelatingsbeleid opnieuw versoepelde. Overigens heb je voor het ontwikkelen in Adobe Flash Professional CS5 nog steeds het Apple Developper Enrollment nodig. Ook is het op dit moment onzeker of apps die niet ontwikkeld zijn in XCode worden toegelaten in de AppStore.

Onderhoud
Het ontwikkelen van een app is één ding, het onderhoud is iets anders. Op zich heb ik het niet eens over de content, maar over de mogelijkheden. Met nieuwe toestellen komen ook nieuwe mogelijkheden, en het invoegen van nieuwe mogelijkheden in je (web)app vereist onderhoud. Bij een native app betekend dit herprogrammeren, testen, opnieuw indienen en afwachten of de nieuwe versie wordt toegelaten. Daarna is het afwachten of gebruikers ook daadwerkelijk updaten. Met een webapp is het een kwestie van opnieuw ontwikkelen, testen en online brengen. Op het moment dat de gebruiker de webapp start maakt hij/zij gelijk gebruik van de nieuwe versie. Ook is het bij een webapp makkelijker om een rollback te doen in geval van een bug. Om een voorbeeld te noemen: gebruikers van de Osfoora-twitterclient (native app) konden na een update geen gebruik meer maken van de app als zij nog werkten op iOS 3.1.3. Dit kwam door een bug in de nieuwe versie. Een rollback was niet mogelijk en gedupeerde gebruikers moesten wachten op een nieuwe update. Met een webapp is het een kwestie van de oude versie terugzetten en alles is weer zoals het was (dit is uiteraard gechargeerd, maar wel de basis).

Multimedia
Een van de sterke punten van de iPhone is natuurlijk de multi-mediamogelijkheden (iTunes/iPod/Youtube/etc.). Vanaf iOS4 is het ook mogelijk om vanuit apps bv. de iTunes-bibliotheek te benaderen. Deze mogelijkheden zijn alleen beschikbaar met een native app. Ook het in-app streamen van media (bv. een audio- of videostream) is uitsluitend mogelijk met een native app. Het lijkt erop alsof multimedia nog niet is doorgedrongen tot de webapps.

Snelheid
De bruikbaarheid van je app valt of staat met de snelheid ervan. Logischerwijs is een native app sneller dan een webapp, omdat die laatste afhankelijk is van de gebruikte dataverbinding. Bij gebruik van Wifi zal een webapp normaliter sneller functioneren dan bij gebruik van 3G. Toch is het verschil kleiner dan je in eerste instantie zou denken. Uiteraard start de native app sneller op, omdat de basis ervan al aanwezig is op de telefoon, maar 99% van de native apps heeft op enig moment toch een verbinding met het internet nodig. En op dat moment vallen de verschillen vrijwel weg. Neem als voorbeeld de native app van Nu.nl. Zonder internetverbinding start de app op, maar is vervolgens nutteloos. En dus is het verschil met de webapp op dat moment miniem. Recent kwam naar buiten dat webapps die ‘buiten Safari om’ worden gestart (dus vanaf het Springboard) trager zijn dan als de app wordt geopend vanuit Safari. Dit heeft te maken met Nitro, de gebruikte Javascript-engine. Er gaan geruchten dat Apple dit bewust heeft gedaan om het gebruik van Safari te stimuleren (bron: Webapps iOS ‘buiten’ Safari stuk langzamer / Nu.nl). Of dit echt zo is kan ik niet beoordelen, maar het lijkt erop alsof dit pas speelt vanaf iOS4. Op 19 maart 2011 werd bevestigd dat de optimalisaties van Nitro inderdaad alleen werken binnen Safari. Webapps die worden gestart vanaf het springboard missen deze. Ook mogelijkheden tot tijdelijke opslag en nieuwe renderingsmogelijkheden zijn alleen toegankelijk vanuit Safari. Deze optimalisaties zijn beschikbaar vanaf iOS 4.3

Wanneer native, wanneer web?
Wanneer kies je voor een native app en wanneer kies je voor een webapp? Een ding is zeker; als je gebruik wilt maken van fysieke iPhone-functies zoals de versnellingsmeter en de camera, dan zit je vast aan een native app. Maar als je bv. een app wil als mobiel alternatief voor een website, dan zou je kunnen volstaan met een webapp. Er zijn een aantal frameworks beschikbaar, van heel simpel (iWebKit) tot zeer geavanceerd (WebApp.Net) die het mogelijk maken om redelijk snel een webapp te schrijven. Een native app is aan te raden als er een commercieel model aanhangt aangezien webapps moeilijker commercieel te maken zijn. Ook is het zo dat Apple de gehele financiele afhandeling voor z’n rekening neemt als je gebruik maakt van een betaalde native app.

Conclusie
Er is veel te zeggen voor zowel native apps als webapps. Laten we het eens onder elkaar zetten:

Gezien de tabel lijkt het erop alsof het beter is om native apps te ontwikkelen. Dat ligt echter volledig aan het doel van je app. Een simpele RSS-reader bijvoorbeeld kan prima als webapp gecreëerd worden, terwijl een foto-bewerkingsapp (die toegang nodig heeft tot de camera) toch echt als native app ontwikkeld zal moeten worden. Iedere vorm heeft z’n voor- en nadelen en het is aan de ontwikkelaar om te beoordelen welke voordelen er nodig zijn en of hij/zij de daarbij behorende nadelen voor lief genomen worden.