Native app of web app?

, # Mobile

Smartphones zijn hot. Volgens onderzoeksbureau IHS iSuppli zal in 2013 de helft van de verkochte mobiele systemen een smartphone zijn. Ons eigen onderzoek wijst bovendien uit dat het afgelopen jaar mobiel gebruik op websites grofweg verdrievoudigd is. Wie “smartphone” zegt, zegt in éen adem “apps”. We kunnen apps indelen in twee grote groepen. Native apps en web applicaties. Maar wat is het verschil tussen die twee? En hoe kies je wat voor jouw toepassing het meest geschikt is?

Native versus web

Een native app is een applicatie die geschreven is om te werken op een specifiek besturingssysteem zoals bijvoorbeeld iOS voor iPhone, Android, of Windows Phone. Zo’n app kan een game zijn, een agenda, of een foto applicatie. Een web applicatie daarentegen is een applicatie die werkt vanuit de browser. De app haalt zijn data van het internet en het gebruik hiervan hangt grotendeels af van het feit of je op je toestel beschikt over een internetverbinding of niet. Het belangrijkste verschil met een native app is dat een web applicatie los staat van het besturingssysteem op je apparaat. One app to rule them all! Handig! Of bestaan er toch beperkingen?

Show me the money!

Apple’s App Store is een voorbeeld van een digitale winkel waar je native apps kan downloaden. Dankzij de App Store is de consument zeker dat hij een veilig product aankoopt en heeft de ontwikkelaar een stuk minder administratieve last. Daarnaast is het een mooi uitstalraam naar een grote groep potentiële klanten. Dat is meteen een grote troef in de vergelijking met web applicaties: bij het ontwikkelen van een betalende webapplicatie sta je zelf in voor het implementeren van een betaalmodel en het onderhouden van de administratie. Een intensieve taak die de instapdrempel voor zowel ontwikkelaars als gebruikers gevoelig kan verhogen.

Functionaliteit

Op vlak van hardware-integratie is een native app vandaag in het voordeel. In tegenstelling tot een web applicatie, kan een native app veel functies van je apparaat aanspreken. Onder andere de ingebouwde camera, accelerometer en data van je adresboek zijn beschikbaar voor een native app. Dat is op dit moment nog niet mogelijk wanneer je zou kiezen om een web applicatie te ontwikkelen. Binnenkort komt daar echter verandering in dankzij onder andere Mozilla (welbekend van de browser Firefox) die op dit moment erg hard het voortouw nemen met hun WebAPI.

Offline gaan

Native apps hoeven niet steeds in verbinding te staan met het internet. Eens gedownload kan je bijvoorbeeld makkelijk een notitie maken zonder dat je verbonden moet zijn met het internet. Gelukkig is er met HTML5 verandering op komst en is het voor ontwikkelaars ondertussen mogelijk om data op te slaan in het cachegeheugen van de browser–zo wordt de web app ook offline beschikbaar. Die appcache is veelbelovende technologie, die zwaar in het voordeel van web applicaties zal spelen!

Up to date houden van je app

Als gebruiker ben je zelf verantwoordelijk voor het up to date houden van je native app. Gewoonlijk moet je verbinding maken met de App Store, je wachtwoord ingeven en ten slotte op de update knop duwen. Geen gebruiksvriendelijk proces denken wij dan. Bij het ontwikkelen van een web applicatie heeft de ontwikkelaar het updateproces volledig in de hand en kan hij de gebruikers de updatefrustratie besparen. Als ontwikkelaar push je zelf de update naar je gebruikers wanneer dat nodig is. Geen verplichte goedkeuring van een derde partij zoals de App Store en alleen maar happy faces dus!

De huisregels van de fabrikant.

Een native app maken vergt van een ontwikkelaar goede technische kennis van het platform en de ontwikkeltaal die daarbij hoort. Een hele opdracht als je graag je native app beschikbaar maakt op bijvoorbeeld iOS, Android én Windows Phone. Je bent gebonden aan bepaalde huisregels die vooropgesteld worden door de fabrikant van het besturingssysteem.

Op vlak van gebruikersinterface ben je bijvoorbeeld voor Windows Phone verplicht om te voldoen aan de regels van Microsoft’s vooropgestelde design language “Modern UI (eerder Metro)”. Ben je fan van Helvetica Light in het gebruik van je pagina titels? Heeft je merk een lettertype gedefinieerd in de huisstijl? Dat is jammer, want de design language wijst je aan dat het verstandiger is om Segoe WP op gedefinieerde groottes te gebruiken. Ten minste als je wil dat je app wordt goedgekeurd voor de Marketplace (Microsoft’s App Store).

Nadeel of voordeel? In elk geval een interessant discussiepunt. Het is een uitdaging voor designers om grafisch unieke native apps te maken. Tegelijkertijd biedt het minder ervaren ontwikkelaars een ruggengraat om gebruiksvriendelijke apps te creëren die een reële slaagkans hebben op goedkeuring.

Het is bijgevolg duidelijk dat, wanneer je een web applicatie zou ontwikkelen, je op vlak van UI design en development alles volledig zelf in de hand hebt. Jouw geliefde technologie gecombineerd met jouw eigen ontworpen interface en branding.

Conclusie…

Het grootste voordeel van een web app is dat ze beschikbaar is op alle mogelijke toestellen met een browser–dat gaat verder dan enkel smartphones. Je bent als ontwikkelaar vrij zeker dat je app op verschillende toestellen blijft werken, ook de toestellen die in de toekomst verschijnen. Een native app moet altijd specifiek voor een platform ontwikkeld worden, wat een aanzienlijk grotere ontwikkelkost met zich meebrengt.

Uiteindelijk moet per project bepaald worden welke van de twee de beste optie is. Heb je nood aan de functionaliteit van de hardware van je apparaat? Dan is de keuze voor een native app op dit moment een betere keuze. Vind je schaalbaarheid en flexibiliteit een belangrijke factor? Dan is het maken van een web app een goeie zet.

Hieronder vind je nog eens de voor- en nadelen van beide opgelijst:

Native app

Nadelen

  • Moet per platform ontwikkeld worden
  • Meer werk om te onderhouden en aan te passen

Voordelen

  • Je kan rechtstreeks gebruikmaken van de functionaliteiten van de smarthphone (zoals camera en gyroscoop)
  • Je kan makkelijk geld vragen voor de app
  • De inhoud is ook offline beschikbaar

Web App

Voordelen

  • Is platform onafhankelijk
  • Makkelijker om te onderhouden en aan te passen

Nadelen

  • Je kan niet van elke functionaliteit van de smartphone gebruikmaken
  • Moeilijker om geld te vragen voor het gebruik
  • Je hebt een internetverbinding nodig om website te bekijken

Meer weten? Advies nodig?

Kom gerust langs voor een kop koffie en een goed gesprek. Wijs geeft strategisch advies, en helpt bij het uitwerken en verbeteren van all things digital.

Gerelateerde diensten

Gerelateerde cases

  • Contentrijke website voor Newtec

  • Webshop voor Babiche

 

Al 10 reacties

Laat hier een reactie achter of contacteer ons via e-mail


schreef

Hi guys,

Graag zou ik bij voordelen van 'Native Apps' willen toevoegen dat de performantie en gebruikerservaring een pak beter is. Dit is natuurlijk afhankelijk van het project en de klant zijn/haar filosofie... maar de beste kwaliteit/ervaring aanbieden naar gebruikers toe is toch vaak een belangrijk item, ondanks de hogere kost.


schreef

Vergeet zeker ook niet de mogelijkheden van een Hybrid app, waarbij je eigenlijk de body gebruikt van een Native App (Offline functionaliteiten, aanspreken van toestelfuncties, push notifications, ...) en de content laat inladen van een Webapp. Op deze manier heb je de beide, wat natuurlijk de kost meebrengt van beide ontwikkelingen. Echter is de content flexibel beheerbaar vanuit het CMS en is de body heel solide.


schreef

Facebook heeft onlangs zijn HTML5 web app vervangen door een native app voor iOS. Hetzelfde is men nu ook van plan voor Android.


schreef

Het punt dat Mathieu aanhaalt is denk ik heel belangrijk. In de toekomst gaat het volgens mij niet gaan om native of web, maar eerder: welk deel doen we met native en welk met web technologie.

Eén van de belangrijkste punten waarom Facebook eerst voor HTML5 heeft gekozen is omdat ze dan op een snelle manier een app konden maken, maar even belangrijk is omdat ze op deze manier gemakkelijk verschillende UI's konden testen en optimalizeren on the fly.

Ik denk dat het een kwestie is van afwegen. Ik ben volledig akkoord dat je de heavy lifting moet overlaten aan native, maar HTML5 verdiend zeker zijn plaats in de mobile app space.

Wouter

Wouter
schreef

Ik vraag me af, krijgen jullie als webbedrijf ook veel vraag naar ontwikkelen van al dan niet native bedrijfsapps in combinatie met backend systemen zoals SAP?

SAP heeft onlangs partnerships aangegaan met Titanium, Phonegap en Senscha voor inderdaad makkelijker Hybrid apps te gaan ontwikkelen. Zo kunnen we de key functionaliteit eenmalig ontwikkelen en via de 'bridge api' gebruik maken van native functionaliteit/native UI mogelijkheden.

Zijn Hybrid apps momenteel gewoon 'fancy en new' of zijn jullie ook voorstander hiervan?


schreef

@Thomas het is wel wat genuanceerder dan dat denk ik. Het is een feit dat native apps op sommige vlakken *snel* zijn–al is het maar omdat ze geen externe assets moeten inladen. Maar tout court zeggen dat de gebruikservaring beter is, lijkt me wat kort door de bocht.

@Mathieu/Wim/Wouter hybrid apps en frameworks zijn een boeiend gegeven, maar ik zie er weinig toekomst in omdat ze een typische tussenlaag zijn in de overgang naar een meer volgroeid systeem. Met Mozilla’s WebAPI/Boot to Gecko die eraan komt (en er al voor een groot stuk is), AppCache die stilaan volwassen wordt en Microsoft die op een redelijk sterke manier met hun nieuwe user interface uitpakt denk ik dat de toon gezet is voor diepe integratie van Web Apps in het operating system. Enkel Apple sputtert nog tegen door geen Nitro te voorzien, of door developers te dwingen om met UIWebView te werken–wat een serieuze handicap is ten opzichte van native apps, maar wat ook begrijpelijk is vanuit het standpunt van een bedrijf dat de best verkopende App Store ter wereld heeft.

Wat momenteel dus nog door Cordova/Phonegap/Sencha en consorten afgehandeld wordt zal hopelijk binnenkort op OS-niveau beschikbaar zijn. Je kan heel ver gaan in die denkwijze: hoort iets als navigatie nog thuis in een web(site/app)? Soms wel, soms niet. Ik denk persoonlijk dat dat soort beslissingen in de toekomst gaan bepalen met welke technologie je werkt. Éen ding is zeker: we staan nog maar aan het begin van wat mogelijk is, want het paradigma is nog niet veranderd.


schreef

Ik zie hier jammer genoeg zeer veel inhoudelijke fouten staan.

<blockquote>De app haalt zijn data van het internet en het gebruik hiervan hangt grotendeels af van het feit of je op je toestel beschikt over een internetverbinding of niet.</blockquote>

De <em>data</em> moet quasi altijd via het internet opgehaald worden, tenzij het om statische apps gaat. Het is de <em>application logic</em> die bij native apps geen internetverbinding nodig heeft, en bij web apps wel, maar ook daar weer in beperkte mate: d.m.v. AppCache kan een web app — eenmaal gedownload — ook zonder internetverbinding verder functioneren.

De inherente of alleszins de gemiddelde waargenomen latency zal bij web apps onvermijdelijk hoger liggen (zelfs wanneer een web app volledig uit AppCache kan geladen worden), en het is veel moeilijker om deze te verlagen dan bij native apps.

<blockquote>Dat is meteen een grote troef in de vergelijking met web applicaties: bij het ontwikkelen van een betalende webapplicatie sta je zelf in voor het implementeren van een betaalmodel en het onderhouden van de administratie.</blockquote>

Er zijn ook kant-en-klare stores voor web apps. Er is Mozilla's Marketplace, en er zijn vast nog wel meer dergelijke winkels.

<blockquote>Gelukkig is er met HTML5 verandering op komst en is het voor ontwikkelaars ondertussen mogelijk om data op te slaan in het cachegeheugen van de browser–zo wordt de web app ook offline beschikbaar. Die appcache is veelbelovende technologie, die zwaar in het voordeel van web applicaties zal spelen!</blockquote>

Eh … serieus? HTML5 is er ondertussen al ettelijke jaren. AppCache — de techniek waar je het over hebt — is overigens allesbehalve de deux ex machina waarop de "web app wereld" zit te wachten. Het is er al lang, en het heeft <a href="http://www.stevesouders.com/blog/2011/10/03/improving-app-cache/">serieuze beperkingen</a>. De tekst die ik citeer impliceert dat dé <em>enabler tech</em> er zit aan te komen, maar die specificatie is al jaren oud, zit al jaren in browsers en is allesbehalve veelbelovend.<br />

Sterker nog, het is <em>omgekeerd</em>: de spec is er al, en zal jammer genoeg niet erg snel evolueren in de noodzakelijke richtingen (toch niet bij mijn weten, ik hóóp dat ik heuglijk nieuws op dat vlak gemist heb).

Onbegrijpelijk vind ik het, dat AppCache hier als een verlossende, toekomstige techniek wordt voorgesteld. Ik hoop dat het duidelijk is dat dit amper verder van de waarheid kan liggen.

<blockquote>Het grootste voordeel van een web app is dat ze beschikbaar is op alle mogelijke toestellen met een browser–dat gaat verder dan enkel smartphones.</blockquote>

Maar dan verbind je de maximale kwaliteit van de UX aan de kleinste gemene deler: voor een fantastische UX moet je gebruik kunnen maken van de nieuwste functionaliteit, maar niet alle browsers ondersteunen dit. Deze stelling is zeker waar, maar gaat jammer genoeg enkel op voor de meest simplistische web apps.

Bij de voor- en nadelen zie ik ook een aantal fouten.

<blockquote>De inhoud is ook offline beschikbaar.</blockquote>

Niet noodzakelijk: de logica wel altijd, de inhoud niet. Bovendien kan dit ook in web apps, dankzij AppCache.

<blockquote>Makkelijker om te onderhouden en aan te passen</blockquote>

Wegens verschillen in browserondersteuning, alsook het onderhouden van meer infrastructuur en de sterkere correlatie tussen infrastructuur en app interaction latency, vind ik ook deze stelling te kort door de bocht.

<blockquote>Moeilijker om geld te vragen voor het gebruik</blockquote>

De drempel is misschien groter, maar voor sommige gevallen kan dit net mákkelijker: voor subscription-based apps kan het net handiger zijn om niet van de native app stores gebruik te maken.

<blockquote>Je hebt een internetverbinding nodig om website te bekijken</blockquote>

Absoluut fóut: AppCache.

<blockquote>Enkel Apple sputtert nog tegen door geen Nitro te voorzien, of door developers te dwingen om met UIWebView te werken–wat een serieuze handicap is ten opzichte van native apps, maar wat ook begrijpelijk is vanuit het standpunt van een bedrijf dat de best verkopende App Store ter wereld heeft.</blockquote>

Ik hoop dat je weet dat dit komt o.w.v. <a href="http://daringfireball.net/2011/03/nitro_ios_43">security implicaties</a>?

Het lijken misschien details, maar het zijn belangrijke nuances. In een technisch artikel horen deze correct te zijn.

P.S.: Typo: "smarthphone".

P.P.S.: en waarom krijg ik niet te zien of het input formaat hier Markdown, beperkte HTML of iets anders is? Eleganter, maar ook frustrerend. Een preview optie zou tot op zekere hoogte al helpen: dan kan je tenminste terugvallen op trial & error. (Wow, wat een mooie ampersand!)


schreef

In mijn ogen is het grootste probleem voor web apps dat ze geen (of maar heel beperkt) gebruik kunnen maken van lokale resources. In het artikel zijn hier enkele voorbeelden van gegeven zoals de camera & accelerometer, maar de belangrijkste zijn niet vermeld: de processor en het intern geheugen van het apparaat.

Web apps kunnen geen (of, weeral, heel beperkt) gebruik maken van de rekenkracht van de processor. Voor de inhoud van de meeste app's is dit ook niet nodig maar het wordt wel belangrijk wanneer we gaan kijken naar animatie en navigatie binnen een app. Animaties helpen de gebruiker om de structuur van de app beter te snappen (denk maar aan het schuiven van het ene scherm naar het andere op iOS). Maar het geeft de app ook tijd om andere dingen in de achtergrond te doen (bv. content laden). En als we dan nog moeten wachten kunnen we gewoon een spinner tonen. En hier zien we een groot verschil tussen web en native: een native spinner zal altijd vlotter en mooier draaien dan op het web gewoon omdat lokale rekenkracht kan gebruikt worden. Het speel natuurlijk ook een rol dat de flow van het applicatie flexibeler is bij native door bijvoorbeeld multithreading. Al deze kleine dingen leiden tot hetgeen Thomas aanhaalde: een betere performantie en gebruikerservaring.

Daarnaast kunnen native app's ook hun content opslaan en deze al tonen aan de gebruiker wanneer de nieuwe content opgehaald wordt van het web. Weer een voorbeeld van betere gebruikservaring. Alhoewel dit al weer achterhaald is door nieuwe technologieën zoals AppCache. Maar dit is toch een stuk beperkter dan naar lokaal geheugen kunnen schrijven (en natuurlijk lezen).

Naar mijn inziens heeft een web app niet genoeg basis-resources beschikbaar om met een native app te kunnen concurreren (op vlak van performance), zelf niet met behulp van third-party libraries en frameworks. Indien in de toekomst nieuwe technologieën doorbreken en meer API's voor web apps in het OS ingebouwd worden zoals Xavier vermeldt zie ik het potentieel voor web apps wel enorm vergroten. Dan is er het voordeel van een "universele" web app met de krachtige resources van een native app. Alhoewel het afwachten zal zijn hoe universeel de API's zullen zijn die de OS'en zullen aanbieden.


schreef

@Wim ik denk dat het artikel meer bedoeld is als introductie en overzicht, dan als in-depth technisch artikel. Dat betekent dat er wellicht bewust heel wat nuance is uitgehaald for the sake of simplicity.

Dat wil natuurlijk niet zeggen dat sommige kritiek niet terecht is, maar er zijn toch een paar dingen die je moet kunnen nuanceren denk ik. Je maakt een onderscheid tussen data en application logic: dat is heel erg correct vanuit technisch standpunt, maar een gebruiker zal het worst wezen: de app werkt, of ze werkt niet. En vooralsnog zijn er in praktijk meer native apps die perfect zonder internetverbinding functioneren, dan web apps–denk aan games of to do lists bijvoorbeeld.

Dat er ook stores zijn voor web apps klopt natuurlijk. Maar ze zitten niet in een groter geheel, zoals bij Apple wel het geval is–waar het volledige betaalmodel al aan je account gelinkt is en je account aan de app store en de app store aan je hardware. Mozilla verricht schitterend werk, maar het is vooralsnog niet voor “the masses”. Dat is perfect oké, maar het maakt de situatie wel zo dat je qua eenvoud van betalen/potentiële markt–maar dan ook alléen dat–beter af bent in Apple’s App Store.

In verband met AppCache heb je vanuit technisch standpunt op dit moment 100% gelijk. In de woorden van Jake Archibald: AppCache is een douchebag. Dat betekent echter niet dat er niet aan gewerkt wordt. Granted: de “fixing application cache” W3C Community WG lijkt een beetje stil te liggen, maar mensen bij onder andere Google, Facebook, Lanyrd en de Financial Times zijn er blijkbaar toch mee bezig–wat mij sterkt in de overtuiging dat er in AppCache weldegelijk meer toekomst ligt dan op dit moment het geval lijkt te zijn.

Wat Nitro en UIWebView betreft: jep. Natuurlijk is dat genuanceerd. Maar het komt Apple toch wel goed uit dat Web Apps gevoelig minder performant zijn/niet dezelfde mogelijkheden hebben als Native Apps op dit moment–Boot To Gecko bewijst op zich dat het blijkbaar wel kàn.

Mijn conclusie? Vanuit technisch standpunt snijdt het artikel inderdaad wat bochten af, die je heel goed en veelal correct nuanceert, maar de conclusies in praktijk en zelfs toekomstgezien vind ik wel correct–al zal alleen de toekomst ons gelijk of ongelijk kunnen geven natuurlijk.

PS & PPS: we proberen het te fixen, want dat klopt helemaal ;)

@Yasser helemaal mee eens, maar ook daar denk ik dat we op een punt gaan komen dat rekenkracht en geheugen als technische barrière irrelevant worden. Wat animaties en web graphics betreft is WebGL dan weer promising denk ik. Maar de echte toekomst ligt volgens mij–zoals je zelf ook al zei–nog steeds in het op OS-niveau brengen van die technologieën. Afwachten en ondertussen de juiste keuze maken per project natuurlijk! ;)

Comcommer

Comcommer
schreef

Ik moet voor school de app van het platform Yammer bespreken. Toevallig iemand die weet of dit nu een web app of native app is?

Plaats een nieuwe reactie