Native vs. webbased mobile apps

[PaulEm]

Vandaag vroeg ik me af waarom er nog steeds zoveel native apps ontwikkeld worden.
Tegenwoordig is het genoeg ondersteuning (met HTML5) om web-based apps te maken.

Dit geeft verder ook veel voordelen, zo hoef je (als je het goed doet) maar één keer je app te ontwikkelen. Hebben mensen gelijk de meest nieuwe versie, etc.

Wat is jullie mening hier eigenlijk over?

----

Geen idee of dit het goeie forum is, indien niet mag deze verplaatst worden

[koli-man]

Met een native app, kun je het dataverbruik reduceren. Want je kunt je beperken tot puur data.
En je kunt gebruik maken van de mogelijkheden van je mobile os, bijvoorbeeld de hardware peripherals.

[PaulEm]

koli-man schreef op woensdag 29 februari 2012 @ 08:48:
Met een native app, kun je het dataverbruik reduceren. Want je kunt je beperken tot puur data.
En je kunt gebruik maken van de mogelijkheden van je mobile os, bijvoorbeeld de hardware peripherals.

De app moet alsnog gedownload worden. HTML5 heeft ondersteuning voor dataopslag, waardoor je je web-based app ook gewoon in offline modus zou kunnen gebruiken.

[farlane]

"Webbased" is nog altijd een samenraapsel van technieken die niet voldoende op elkaar aansluiten, en niet de performance hebben van een vergelijkbare native applicatie.

Misschien komt Web 5.0 in de buurt van wat het moet zijn, wie weet.

[Styxxy]

Op Google I/O 2011 was er wel een goede presentatie over. Deze was gericht op HTML5 Webapps versus Android Native Apps, maar uiteindelijk kan dat ook doortrekken naar de andere platformen. Het filmpje kan je hieronder vinden.

[ Voor 5% gewijzigd door Styxxy op 29-02-2012 09:03 ]

[PaulEm]

farlane schreef op woensdag 29 februari 2012 @ 08:50:
"Webbased" is nog altijd een samenraapsel van technieken die niet voldoende op elkaar aansluiten, en niet de performance hebben van een vergelijkbare native applicatie.

Misschien komt Web 5.0 in de buurt van wat het moet zijn, wie weet.

Met de nieuwe devices die op de markt gebracht worden wordt de performance van web-based apps al flink opgekrikt. Pak bijvoorbeeld http://www.cuttherope.ie, deze valt best te spelen op een iPad 2.

Ook steeds meer mobile-browsers bieden ondersteuning voor HTML5 en Touch events.

[NMe]

Zolang web based apps niet in dezelfde app store/market staan zullen ze altijd het onderspit delven ten opzichte van native apps. Mensen willen voornamelijk gebruiksgemak.

[TheNephilim]

Bedoel je met apps, applicaties voor de mobiele markt?

Verder denk ik dat native apps altijd blijven. Ze zijn gewoon vaak net even sneller dan de webbased apps op de mobiele telefoons. Behalve dat heb je met native apps de mogelijkheid om lokaal wat te doen, dit gaat met een webbased app niet lukken.

Zelf vind ik Adobe Air best grappig, hierin kun je gewoon met HTML/JS/CSS aan de slag en toch kun je het geheel verpakken als een applicatie. Deze draait in een hele boel systemen, al weet ik niet wat hij doet op Android/iOS/etc.

[kwaakvaak_v2]

NMe schreef op woensdag 29 februari 2012 @ 09:55:
Zolang web based apps niet in dezelfde app store/market staan zullen ze altijd het onderspit delven ten opzichte van native apps. Mensen willen voornamelijk gebruiksgemak.

vooral dat... Alhoewel je wel een bepaalde vermoeidheid ziet bij consumenten rondom niets toevoegende 'wrapper/reclame' apps.

Ik denk dat het één het andere niet uitsluit. Een goede HTML5 variant van je webapplicatie, aangevuld met een aantal specifieke apps. En die kunnen ook best in html/js gemaakt worden en met behulp van phonegap (apache-callback/cordova) gemaakt worden, maar dat hangt sterk af van de doelgroep..

[ Voor 0% gewijzigd door kwaakvaak_v2 op 29-02-2012 10:26 . Reden: callback heet nu cordova ]

[Misha]

Ik heb nog geen enkele webbased app gezien die net zo snappy werkt als een native app (erg brakke native apps natuurlijk niet meegenomen).

Een gebruiker wil uiteindelijk toch dat alles goed, snel en gebruiksvriendelijk verloopt. Als je een app maakt, dan moet dat imho ook altijd je uitgangspunt zijn. Je krijgt inderdaad een stukje meer kosten, maar gebruiksgemak boven alles. En als het management het wil betalen; prima!

De Facebookapp is voor zover ik weet zo'n hybride oplossing. Ik erger me altijd enorm aan de traagheid en het weerhoud mij er van om vaker de app te starten

[kwaakvaak_v2]

Dat klopt, het hangt idd erg sterk af van wat er moet gebeuren. Voor phonegap zijn er intussen wat meer plugins beschikbaar gekomen die dingen afhandelen in native code ipv parsed JS.

Ik denk ook dat een developer goed moet bedenken wat een app moet doen, en dan bedenken of dit in native of js code opgelost moet worden. Maar voor het ontwikkelen van single UI -> multi OS is het best bruikbaar vind ik.

[NMe]

Misha schreef op woensdag 29 februari 2012 @ 10:26:
Ik heb nog geen enkele webbased app gezien die net zo snappy werkt als een native app (erg brakke native apps natuurlijk niet meegenomen).

Ik wel, het bedrijf waar ik werk heeft er zo eentje gemaakt. Dat zal niet geheel onpartijdig klinken maar ik merkte het verschil niet tussen een native app en deze webapp. Afhankelijk van de constraints van het project kan het prima.

Voor geïnteresseerden: http://eindhovenairportapp.nl/
Let wel, dit was niet meer dan een proof of concept en daarom is hij alleen uitgewerkt voor iOS. Op Android en andere OS'en loopt hij niet zo lekker, en op de desktop doet 'ie het alleen in webkit goed.

[farlane]

PaulEm schreef op woensdag 29 februari 2012 @ 09:03:
[...]
Met de nieuwe devices die op de markt gebracht worden wordt de performance van web-based apps al flink opgekrikt. Pak bijvoorbeeld http://www.cuttherope.ie, deze valt best te spelen op een iPad 2.

Ook steeds meer mobile-browsers bieden ondersteuning voor HTML5 en Touch events.

Cut the rope runs best in the newest version of Internet Explorer on Windows 7

'nuff said.


[edit]
Overigens hoort HTTP/HTML( whatever version )/Javascript/ServerSide scripting bij die verzameling technieken waarover ik het heb : het is en blijft een zooi technieken bij elkaar die het niet voor elkaar krijgen om een native app te evenaren qua snelheid / features. En dat blijft net zolang men blijft vasthouden aan dat stateless gedoe met HTTP.

[ Voor 25% gewijzigd door farlane op 29-02-2012 13:48 ]

[NMe]

farlane schreef op woensdag 29 februari 2012 @ 13:43:
[...]

[...]

'nuff said.

Beetje flauw gezien het feit dat die webapp nooit als mobile app bedoeld is en juist op desktops moet werken. Het feit dat hij ondanks dat toch prima werkt op tablets spreekt boekdelen over de voordelen van HTML5-webapps, lijkt me.

Daarnaast lijkt het me vrij duidelijk dat MS hier voor sponsor heeft gespeeld gezien de prominente IE-reclame rechtsonder.

[farlane]

NMe schreef op woensdag 29 februari 2012 @ 13:48:
Beetje flauw gezien het feit dat die webapp nooit als mobile app bedoeld is en juist op desktops moet werken. Het feit dat hij ondanks dat toch prima werkt op tablets spreekt boekdelen over de voordelen van HTML5-webapps, lijkt me.

Ik werk op een desktop, still doesnt work.

Als een applicatie in een browser het niet voor elkaar krijgt om cross-platform te werken dan sterkt dat imho mij in mijn standpunt dat 'de webapp' een zooitje is.

[NMe]

Dit is natuurlijk wel iets meer dan "een webapp". Het is een game, en dat is net even iets ingewikkelder dan de gemiddelde nieuwsreader of andere statische app. Ik denk niet dat het oneerlijk is om dat onderscheid te maken.

[biglia]

PaulEm schreef op woensdag 29 februari 2012 @ 08:44:
Vandaag vroeg ik me af waarom er nog steeds zoveel native apps ontwikkeld worden.

Is dat zo? Als ik de vacatures bekijk is het toch allemaal webbased wat de klok slaat.

[Verwijderd]

Nu WebRTC en WebGL zich een weg banen naar de mobiele browsers, komt web wel heel erg dicht in de buurt van wat native performance.

Edit:
- WebRTC staat voor Webbased Real Time Communication, ofwel video chat via het web met html5.

[ Voor 28% gewijzigd door Verwijderd op 29-02-2012 14:15 ]

[ajakkes]

farlane schreef op woensdag 29 februari 2012 @ 13:55:
[...]

Ik werk op een desktop, still doesnt work.

Als een applicatie in een browser het niet voor elkaar krijgt om cross-platform te werken dan sterkt dat imho mij in mijn standpunt dat 'de webapp' een zooitje is.

Toch benieuwd naar je problemen want hij draait prima in Firefox en Chrome onder XP.

[PaulEm]

biglia schreef op woensdag 29 februari 2012 @ 14:07:
[...]


Is dat zo? Als ik de vacatures bekijk is het toch allemaal webbased wat de klok slaat.

Eerst stond er nog in de topic titel dat 't om mobiele platforms ging. Dit heeft een mod veranderd waardoor mijn bericht misschien een beetje verwarrend over komt

[ZpAz]

NMe schreef op woensdag 29 februari 2012 @ 13:48:
[...]

Beetje flauw gezien het feit dat die webapp nooit als mobile app bedoeld is en juist op desktops moet werken. Het feit dat hij ondanks dat toch prima werkt op tablets spreekt boekdelen over de voordelen van HTML5-webapps, lijkt me.

Daarnaast lijkt het me vrij duidelijk dat MS hier voor sponsor heeft gespeeld gezien de prominente IE-reclame rechtsonder.

Een team van Microsoft heeft samengewerkt met de makers van Cut the Rope. Op mijn iPhone 4S loopt hij trouwens niet helemaal soepel, wat boekdelen schreeft, hoezeer ik de techniek erachter waardeer, is het bij lange na niet op het niveau van een native programma.

In termen van snelheid loopt het flink achter (Cut the Rope draait "native" soepel op een 3G) daar hoef je de webversie niet op proberen te draaien. En dat is dan nog een "redelijk" simpel spel. (De physics zijn nog het zwaarste denk ik).

Maar ook in termen van ontwikkelen, het is momenteel veel meer werk om dat spel te maken met web technieken dan in een "native" omgeving.

---

Zo en zo ben ik niet een groot voorstander van cross-platformheid. Oei, wat zal ik hier veel tweakers mee tegen de schenen aan trappen als ik dit op de FP gooide . Puur om het simpele feit dat je bij multiplatformheid altijd rekening houd met de zwakste schakel en dus voor geen enkel systeem de beste oplossing zal hebben.

En dan kan je wel mooi rekening houden met "gracefull degration" (ik doe het ook voor mijn websites) maar dan ben je meer tijd bezig om je applicatie te maken op een manier die je oorspronkelijk niet voor ogen had en je levert dan voor andere systemen concessies in om het maar te laten draaien, het draait dan niet "in de volledige glorie" welke je oorspronkelijk voor ogen had.

Dat zijn drie redenen waarom web applicaties van mij nog wel op zich mogen laten wachten, verticale integratie ftw.

[_David_]

NMe schreef op woensdag 29 februari 2012 @ 11:38:
[...]

Ik wel, het bedrijf waar ik werk heeft er zo eentje gemaakt. Dat zal niet geheel onpartijdig klinken maar ik merkte het verschil niet tussen een native app en deze webapp. Afhankelijk van de constraints van het project kan het prima.

Voor geïnteresseerden: http://eindhovenairportapp.nl/
Let wel, dit was niet meer dan een proof of concept en daarom is hij alleen uitgewerkt voor iOS. Op Android en andere OS'en loopt hij niet zo lekker, en op de desktop doet 'ie het alleen in webkit goed.

Die app werkt gewoon goed op Android honeycomb hoor

[l1dert]

Veel native apps hebben veel webviews met html pagina's die je crossplatform kunt gebruiken (de facebook app bijvoorbeeld). Het navigeren gebeurt vaak dan nog wel weer native omdat webframeworks dat nog niet zo soepel voor elkaar weten te krijgen. Maar de belangrijkste reden is dat gebruikers er niet bekend mee zijn en de app store wel snappen.

[Onbekend]

Er zijn een aantal grote verschillen waardoor je juist een keuze voor een app ontwikkelen maakt.
Het belangrijkste is dat een app ook een database kan gebruiken. HTML5/Javascript ondersteunt ook wel databases, maar op de mobiele browsers werkt dat nog niet.
Als je zonder internet zit, midden op zee bijvoorbeeld, werkt een app nog steeds. Je kunt wel een webpagina misschien off-line bewaren, maar gegevens opslaan e.d. gaat niet .

[ZpAz]

Onbekend schreef op woensdag 29 februari 2012 @ 20:12:
Er zijn een aantal grote verschillen waardoor je juist een keuze voor een app ontwikkelen maakt.
Het belangrijkste is dat een app ook een database kan gebruiken. HTML5/Javascript ondersteunt ook wel databases, maar op de mobiele browsers werkt dat nog niet.
Als je zonder internet zit, midden op zee bijvoorbeeld, werkt een app nog steeds. Je kunt wel een webpagina misschien off-line bewaren, maar gegevens opslaan e.d. gaat niet .

Jawel, met HTML5 heb je juist wel "localstorage" (wat vaak gebasseerd is op een SQLite database systeem).

[Onbekend]

ZpAz schreef op woensdag 29 februari 2012 @ 20:17:
Jawel, met HTML5 heb je juist wel "localstorage" (wat vaak gebasseerd is op een SQLite database systeem).

Klopt. Op een aantal webbrowsers werkt dat redelijk goed, maar er zijn ook een aantal webbrowsers waaronder IE die dat niet goed ondersteunen.

Op de mobiele apparaten wordt het ook nog niet overal ondersteunt, en dat is erg jammer.

[ZpAz]

Dat is inderdaad ook precies van de redenen dat web-apps nog niet zo "goed werken" als zou moeten, je hebt alsnog de verschillen tussen browsers, terwijl het idee is dat er één centraal systeem is.

[R4gnax]

Onbekend schreef op woensdag 29 februari 2012 @ 20:29:
[...]

Klopt. Op een aantal webbrowsers werkt dat redelijk goed, maar er zijn ook een aantal webbrowsers waaronder IE die dat niet goed ondersteunen.

Op de mobiele apparaten wordt het ook nog niet overal ondersteunt, en dat is erg jammer.

localStorage en sessionStorage, tezamen bekend als Web Storage, worden anders vanaf IE8 volledig ondersteund. Alle andere grote browsers, ook op mobile devices, ondersteunen localStorage en sessionStorage al een aantal versies en vrijwel allemaal (bijna) probleemloos.

Waar jij aan zit te denken is Web SQL databases en IndexedDB, maar met beiden gecombineerd (i.c.m. een universele abstractie laag) kun je toch een redelijke hoeveelheid browsers afdekken.

Overigens was Microsoft zelfs één van de eersten die een degelijker vorm van persistent storage beschikbaar heeft gesteld dan cookies. Sinds Internet Explorer 5 (!!) bestaat al het userData behavior, waarmee IE pagina-gebonden XML documenten kan opslaan en later terug inladen. Onder standaard instellingen kan hiermee 128 KB aan data per document weggeschreven worden en 1 MB totaal per domein. Niet eens zo'n schril contrast met de gangbaar beschikbare 4 à 5 MB van localStorage en een serieuze verbetering ten opzichte van de capaciteit van cookies. (Nog daargelaten dat cookies met elk server request meegestuurd worden en dus by design ongeschikt zijn voor persistent storage van meer dan een paar simpele strings.)

[farlane]

Ik beweer dat een, ik noem maar wat, SQLite db op een 32gb partitie die ik manipuleer met mijn native C applicatie jouw localstorage overtroeft in snelheid en mogelijkheden.

[R4gnax]

farlane schreef op woensdag 29 februari 2012 @ 23:01:
Ik beweer dat een, ik noem maar wat, SQLite db op een 32gb partitie die ik manipuleer met mijn native C applicatie jouw localstorage overtroeft in snelheid en mogelijkheden.

Je bent appels met peren aan het vergelijken. De localStorage is geen relational database, maar een simpele key-value dictionary (waar je met behulp van (de)serialisatie met bijvoorbeeld JSON ook object graphs in kwijt kunt).

Vergelijk eens met IndexedDB of voorganger WebSQL en het verschil in snelheid en mogelijkheden zal een stuk kleiner zijn.

[kwaakvaak_v2]

farlane schreef op woensdag 29 februari 2012 @ 23:01:
Ik beweer dat een, ik noem maar wat, SQLite db op een 32gb partitie die ik manipuleer met mijn native C applicatie jouw localstorage overtroeft in snelheid en mogelijkheden.

En mijn telefoon laat niet eens een localstorage van 32Gb toe bij een webapp. Volgens mij ligt de limiet bij 5Mb. Het is dus niet geschikt om een volledige multiuser site van te runnen, hooguit wat gegevens bij te houden voor 1 gebruiker in offline mode.

[ZpAz]

kwaakvaak_v2 schreef op donderdag 01 maart 2012 @ 09:03:
[...]


En mijn telefoon laat niet eens een localstorage van 32Gb toe bij een webapp. Volgens mij ligt de limiet bij 5Mb. Het is dus niet geschikt om een volledige multiuser site van te runnen, hooguit wat gegevens bij te houden voor 1 gebruiker in offline mode.

Dat lijkt me ook de bedoeling aangezien je alleen zelf bij die data kan.

[ThinkPad]

Ik gebruik op m'n HTC Desire meestal Facebook via m'n browser, in plaats van de native app. Via de browser werkt het namelijk een stuk sneller dan de app, die soms eindeloos staat te laden.

[NMe]

farlane schreef op woensdag 29 februari 2012 @ 23:01:
Ik beweer dat een, ik noem maar wat, SQLite db op een 32gb partitie die ik manipuleer met mijn native C applicatie jouw localstorage overtroeft in snelheid en mogelijkheden.

Water is nat.

Het gaat er niet om dat een native app beter performt. Dat is altijd zo geweest en zal ook altijd wel zo blijven. Waar het om gaat is dat we langzaam aan op het punt aankomen waar het verschil voor het gros van de apps verwaarloosbaar is.

davidaap123 schreef op woensdag 29 februari 2012 @ 19:08:
[...]

Die app werkt gewoon goed op Android honeycomb hoor

Ja, maar minder lekker dan op iOS.

[ Voor 16% gewijzigd door NMe op 01-03-2012 11:27 ]

[YopY]

farlane schreef op woensdag 29 februari 2012 @ 13:43: En dat blijft net zolang men blijft vasthouden aan dat stateless gedoe met HTTP.

Met websockets kom je anders een heel eind. Ook zou je in een hybride app een socket / persistente verbinding kunnen opzetten in native code die events naar je HTML front-end stuurt. Let overigens wel dat de meeste native apps voor hun data ook gebruik maken van een 'gewone' HTTP webservice - ook stateless. De snelheid van een webapp versus een native app heeft dan ook weinig te maken met het al dan niet stateless zijn van HTTP, maar meer met de uitvoeringssnelheid en responsiviteit van HTML / JS.

iig: veel bedrijven kijken toch naar een HTML of hybride oplossing, simpelweg omdat ze 2 keer dezelfde app ontwikkelen niet zien zitten. De tweede lichting ontwikkelt native apps alleen voor de grootste platforms (de nr 1 en 2, op het moment dus Android en iOS), waarbij ze de website geschikt maken voor de andere platforms.

Ik zeg het maar zo: Voor het grootste bereik en een enkele codebase kies je voor HTML of hybride, voor een goeie user experience kies je native. Zelf blijf ik de voorkeur geven aan native - ik geloof zo dat een team van twee even snel twee native apps kan bouwen dan een team van twee een HTML / hybrid app kan bouwen, zeker als bekend is wat er precies gebouwd moet worden en de twee developers weten wat ze doen. Bij HTML en hybride blijf je toch veel overhead houden; UIs bouwen is veel werk (html, css, testen testen testen, klooien met pixels en positionering, crossbrowser testen, etc), je zult vaak toch stukjes native moeten bouwen, en uiteindelijk heb je developers nodig die moeiteloos 3, 4 of 5 talen en technieken door elkaar heen kunnen (html, css, javascript, java, objective-c, evt. een aparte taal voor een back-end, phonegap, android, iOS, etc).

[farlane]

NMe schreef op donderdag 01 maart 2012 @ 10:28:
Water is nat.

Het gaat om native vs webbased, ik vind dat ik webbased op performance en mogelijkheden mag afrekenen.

Overigens ben ik het ook niet (geheel) eens met je bewering dat het verschil in performance niet uitmaakt : een groep toepassingen is inderdaad werkbaar als de performance slechter is dan wat redelijkerwijs zou kunnen. Aan de andere kant vind ik dat statements die de performance van een applicatie als niet belangrijk categoriseren niet correct : als je moet kiezen uit 2 versies die qua functionaliteit hetzelfde zijn maar de ene is 30% sneller op belangrijke punten dan weet ik wel welke de voorkeur krijgt.

Verder is mijn punt (nogmaals) dat de technieken die er allemaal verzonnen zijn om webbased apps mogelijk te maken voor een groot gedeelte gebouwd zijn op een basis die inherent ongeschikt is voor die toepassing, en ik vind de hoeveelheid van talen/technieken die je uit de stal moet halen om ueberhaubt de beleving van een native app te benaderen gewoon van de zotte.

Having said that, ik heb het grootste respect voor de developers die ondanks die 'chaos' toch iets weten neer te zetten wat goed werkt

[NMe]

Ik zei dan ook niet dat het performanceverschil per definitie niet uitmaakt, ik zei dat we op een punt zijn gekomen waar dat voor veel apps niet zo is. Het is kan nog steeds zinnig zijn om een native app te maken of desnoods een hybrid app, maar tegelijkertijd wordt het performanceverschil zo klein dat het over een jaar of misschien twee jaar veel minder verschil zal maken. Het zou me niks verbazen als er over een paar jaar ook webapps in de diverse markets en stores staan.

[Hooiopdevork]

Wat te denken van tools als Phonegap. 1 keer een app ontwikkelen in html5 + javascript en vervolgens naar verschillende mobile besturingssystemen deployen als native app.

[MSalters]

Sinds we een web-based UI hebben, hebben we onze processoren moeten upgraden van 266 Mhz ARM9 naar 500 Mhz+ ARM11. En aangezien we miljoenen aan CPU's uitgeven, hebben we behoorlijk lopen optimizen. Nee, als je naar de feiten kijkt zijn webapps nog lang niet op het nivo van native apps.

[NMe]

De huidige generatie smartphones is uitgerust met veel krachtigere CPU's dan dat en heeft ook een goeie GPU. Dat betekent uiteraard niet dat ze gemeengoed zijn, maar meer dan een kwestie van tijd is het niet.

[MSalters]

Inderdaad geldt dat voor de huidige smartphones; het is geen toeval dat die binnen een uur of twee gebruik leeg zijn. Zo'n mobiele GPU is niet serieus belangrijk voor web apps, die kunnen er vrijwel niets mee.

[NMe]

Daar moet ik je ongelijk in geven. Hardware rendering van hippe nieuwe CSS3-transformaties maakt een wereld van verschil. Die dikke GPU maakt meer verschil dan je denkt zodra je je app grafisch leuk gaat aankleden.

[YopY]

NMe schreef op vrijdag 02 maart 2012 @ 13:18:
Daar moet ik je ongelijk in geven. Hardware rendering van hippe nieuwe CSS3-transformaties maakt een wereld van verschil. Die dikke GPU maakt meer verschil dan je denkt zodra je je app grafisch leuk gaat aankleden.

Dan komen we natuurlijk bij het volgende punt: zijn HTML5 / CSS3 / Javascript animaties even energie-efficient als native geprogrammeerde animaties?

[ZpAz]

Een javascript animatie, nee, dat is gewoon dom manipulatie en aan de hand daarvan posities e.d wijzigen en opnieuw laten renderen. CSS animaties worden hardwarematig afgehandeld zonder JS e.d. die zijn veel perfomanter, ik denk dat die nog best energie efficient is.

Maar je GPU gebruik in een 2D applicatie, dat is te verwaarlozen in vergelijking met andere dingen (scherm, verbindingen e.d.)

[defiant]

Naar mijn mening zullen echte webapplicaties die geen eigen lokale componenten hebben nog wel even achterblijven, omdat de betrouwbaarheid van mobiele verbindingen in combinatie met oprukkende datalimieten zulke applicaties zullen beperken.

En bovenstaande restricties, in combinatie met het in het (zeker in het begin) beperkte beschikbare resources, is ook het gene wat de hele apps ecosysteem mogelijk gemaakt. Waar gebruikers op hun pc de browser (al niet met flash) voor gebruiken, downloaden/kopen ze voor hun mobiel vaker een app.

Hoewel intuïtief mijn voorkeur uitgaat naar native apps, hebben we zakelijk toch vrij veel succes met een phonegap applicatie. Dit komt voornamelijk omdat de libraries/componenten die nodig hebben wel beschikbaar zijn in javascript en niet op de native platformen.

Aangezien in mijn vakgebied veel (open source) libraries worden ontwikkelt in managed talen, is dit op mobiele platforms zeker een issue. Zeker in combinatie met de diversiteit van het mobiele ecosysteem. Met een redelijk klein development team heb je simpelweg de resources niet om zoiets te porten naar ander platforms.

Zeker zakelijk zie ik hierdoor dan wel een hoop obstakels voor mobiele/tablet apps, zeker als er sprake is van maatwerk. Ik heb al een aantal klanten gezien die ondersteuning van iOS als Android als eis hebben neergelegd, omdat ze intern een support-any-device policy hebben aangenomen. Afhankelijk van de ontwikkelingen komt daar natuurlijk ook Windows Phone bij.