Near native vs webview-based vs native apps

  • vrijdag 19 januari 2018, geschreven door Terence Punt

Near native app is een opkomende term in de wereld van app ontwikkelaars. Het is de uitkomst voor ondernemers die een native ogende app op meer dan één OS willen hebben, maar wel rekening moeten houden met budgetoverwegingen. In dit blog gaan we dieper in op de voor- en nadelen tussen near native, webview-based en native apps. 

Wat is een near native app precies? 

Near native apps zijn apps die de gebruiker een native gevoel geven, ondanks dat de codebase tussen 2 of meer platformen voor een gedeelte gedeeld is. De basis van de app wordt ontwikkeld in één framework, waaruit 2 verschillende projecten ontstaan (Objective-C/Swift voor iOS en Java voor Android). Vanaf dit moment wordt de code van de app per platform gefinetuned.

Near-native-apps-UI

De meest gebruikte frameworks voor het ontwikkelen van near native apps zijn op dit moment Titanium, Nativescript en Reactnative. In deze containers kan de ontwikkelaar Javascript en een JavaScript syntax extensie (JSX) gebruiken om een applicatie uit native componenten op te bouwen.  Deze componenten worden opgeroepen uit de native componenten van zowel iOS als Android. Zo kan de ontwikkelaar de codebase van een iOS app hergebruiken voor de Android app met minimale moeite. 

Het grote voordeel is dat de ontwikkelaar niet langer last heeft van een 'lelijk' webview-component. Front-end ontwikkelaars die niet bekend zijn met de componenten van React Native, kunnen bestaande boilerplate-kits zoals NativeBase gebruiken om eenvoudig platformonafhankelijke applicaties te bouwen die aansluiten bij het native uiterlijk van het betreffende platform. De tijd zal leren of native component-based hybride apps zullen resulteren in een community die even actief is als de webview-based hybride app ontwikkelaars.

Xamarin

Xamarin is een near native ontwikkeltool die vooral goed gebruikt kan worden voor het delen van business logica. Het wordt geschreven in C#, een van de .NET (Windows) framework talen. 

Xamarin.iOS en Xamarin.Android stellen je in staat om gedeelde code (rond 75%) te gebruiken en platformspecifieke tweaks aan te brengen. Ze werken het beste met: 

  • Apps die native gedrag moeten vertonen tijdens interacties
  • Apps die veel platform-specifieke API's gebruiken 
  • Apps waar de UI belangrijker is dan het delen van code.

Ook is er Xamarin.Forms (100% code delen), wat je het best kunt gebruiken voor:

  • Apps die weinig platform specifieke functionaliteiten nodig hebben 
  • Apps waar het delen van code belangrijker is dan een goede UI 
  • Ontwikkelaars die thuis zijn XAML.

Overweging near-native #1: Support vanuit de industrie 

React Native heeft een groot voordeel ten opzichte van webview-based apps. Het is ontwikkeld door Facebook en wordt actief gebruikt door een paar van de grootste namen in de industrie zoals Airbnb en Discord. De keuze van deze bedrijven voor near native apps duidt op de kracht en stabiliteit van deze technologie in een snel veranderende markt. 

Overweging near-native #2: Ontwikkeltijd 

Een gedeelte van de codebase is gedeeld en hoeft dus maar één keer ontwikkeld te worden. Voor de platform specifieke vertaling zijn meestal (helaas kan dit niet altijd) plug-ins beschikbaar, die hierbij helpen. De app komt zo dus sneller op de markt. Sommige ontwikkelaars beweren tot 30% sneller te werken via deze methode.

Hybride (HTML) webview apps 

Webview-based hybride applicaties stellen ontwikkelaars in staat om apps te maken met behulp van web-technologieën zoals HTML, CSS en JavaScript. Veelgebruikte frameworks voor dit soort apps zijn Phonegap, Cordova en Ionic.  De code is hier zo generiek dat hij gedeeld kan worden tussen 2 platformen en wordt geladen in een platform specifieke container (veelal Chrome of Safari). Dit is het grote verschil met near native, waar per taal nog getweakt kan worden.

De ontwikkelaars achter dit idee vonden dat de smartphone designers (Apple, Samsung etc.) slechts half werk hadden geleverd toen zij mobile web-SDK's voor hun devices ontwikkelden. Ze negeerden namelijk de mogelijkheid om bepaalde interfaces te integreren voor ontwikkelaars, waardoor geen gebruik meer gemaakt kan worden van native features zoals GPS en accelerometers. 

PhoneGap (nu Apache Cordova) is hierop ingesprongen en stelt ontwikkelaars in staat om deze native componenten toch te laten communiceren vanuit het native mobiele webcomponent. Aan het einde van de rit kan de app gedistribueerd worden vanuit de appstores, zodat het lijkt alsof hij native ontwikkeld is. Omdat alle grote platforms een soort webview-component bieden, kan de code van de applicatie eenmaal worden geschreven en op meerdere platforms worden gedistribueerd.

Om nog een stap verder te gaan: het Ionic framework, dat gebruik maakt van Cordova en Angular, creëert een ecosysteem waarin voorgemaakte, native ogende webcomponenten kunnen worden samengevoegd om visueel moderne mobiele interfaces te creëren. Hier beginnen wel wat belletjes te rinkelen, maar het is zeker de moeite waard om te overwegen. Angular is inmiddels aan zijn tweede versie toe, die nog veel toegankelijker is dan de eerste. 

2 apps ontwikkelen in de tijd van 1, dat klinkt geweldig toch? In theorie klopt dat, in werkelijkheid ligt het iets gecompliceerder en zul je nog wat afwegingen moeten maken.

Overweging webview #1: Performance 

Toen Cordova voor het eerst populair werd, was het meest gebruikte webview-component UIWebView, die door Cordova standaard werd gebruikt. Sindsdien is het nieuwe en verbeterde webview-component, WKWebView, als plug-in geïntegreerd in het Cordova-ecosysteem. Hoewel dit de ontwikkelaar in staat stelt om de snelheid en UI van hun webview-gebaseerde applicatie te verhogen, zal deze niet overeenkomen met de prestaties van native componenten.

Om de overweging nog ingewikkelder te maken: elk Android-apparaat heeft zijn eigen standaardwebview. Dit betekent dat je er niet zeker van kunt zijn dat je toegang zult hebben tot bepaalde JavaScript-API's, bepaalde CSS-eigenschappen of zelfs dat de applicatie op alle apparaten hetzelfde zal weergeven. Gelukkig is daar Crosswalk, gemaakt om ervoor te zorgen dat de webweergave die de app gebruikt, gebaseerd is op de nieuwste webkit-engine van Google Chrome.

Overweging webview #2: Updates  

Mobiele apps zijn in feite levende wezens en hebben net als jij behoefte aan ontwikkeling en groei. Dit betekent dat apps regelmatig geüpdatet moeten worden om ze in leven te houden. 

Het grootse nadeel van webview hybride apps is dat deze iedere keer moeten worden bijgewerkt als een producent weer eens een nieuw toestel of besturingssysteem uitgeeft, omdat ze anders stoppen met werken. 

We nemen even als voorbeeld: het versturen van een e-mail. Als het native component voor het versturen van e-mail veranderd, moeten de ontwikkelaars van bijvoorbeeld Cordova  een nieuwe plug-in ontwikkelen om het mailverkeer weer te laten werken op het laatste OS. Derhalve kunnen sommige applicatie-functies enkele weken of maanden niet beschikbaar zijn voordat dit probleem opgelost kan worden. 

Native apps

Native apps zijn apps 'zoals we ze kennen'. Deze apps zijn volledig geschreven in een platform specifieke taal (veelal Java voor Android en Objective-C/Swift voor iOS) en zullen dan ook per platform ontwikkeld moeten worden. 

Voordelen native apps

  • Je kunt gebruik maken van alle features op de smartphone van de gebruiker
  • De gebruiker is door de controles van de appstores beschermd en kan uitgaan van complete veiligheid en beveiliging van de app
  • Binnen de appstores is het mogelijk om de app te laten ontdekken door partijen die hem anders waarschijnlijk niet gevonden hadden
  • Optimale UX en UI-design en performance. 

Nadelen native apps

  • Wil je meerdere devices (iOS, Android, Windows Phone) ondersteunen, moet je per platform een app laten bouwen
  • Er kan geen code gedeeld worden tussen de ontwikkelde apps
  • Langste ontwikkeltijd (bij 2 of meer platformen) en dus ook de duurste optie
  • Updates moeten per platform doorgevoerd worden, dit kan een paar dagen duren.

Wat is het verschil tussen near native, webview-based en native apps?

Om de verschillen tussen alle verschillende vormen van ontwikkelen nog eens duidelijk voor je te krijgen, kun je gebruik maken van onderstaande afbeelding: 

Native vs hybrid vs near native

Welke oplossing past bij mijn onderneming?

Creëer eerst een helder beeld welk doel de applicatie heeft en welke functionaliteiten de app moet hebben. Ga vervolgens na van welke toestel-specifieke features (zoals GPS en accelerometer) je gebruik wilt maken. Gezien de verscherpte wetgeving omtrent privacy, mag je alleen nog gebruik maken van features waarvan je kunt aantonen dat je ze écht nodig hebt om de app goed te laten werken. 

Je kunt near native apps proberen als... je op zoek bent naar meer controle over je programma design en dataflows, met een performance boost als extra voordeeltje.

Je kunt webview-based apps proberen als... je op zoek bent naar een framework dat het organiseren van je code een minimale moeite maakt en de vrijheid wilt hebben om bestaande webtechnologieën te gebruiken. 

Je kunt native apps proberen als... je op zoek bent naar een app voor 1 platform, of als het doel van de app hierom vraagt (het delen van logica is nou eenmaal niet in iedere situatie gewenst). 

Tot slot zul je rekening moeten houden met het platform waarvoor je wilt ontwikkelen. React Native en Nativescript ondersteunen bijvoorbeeld nog geen Windows Phone, waar Xamarin dit wel doet.

Wil je meer weten over de mogelijkheden en toepassingen van near-native, webview-based of native app ontwikkeling voor jouw onderneming? Neem gerust contact met ons op voor meer informatie.

Ook interessant om te lezen

webuildapps blog 2017 10 roi ipad

3 stappen om de ROI van een app vooraf in te schatten

  • donderdag 12 oktober 2017

Return on investment , oftewel  ROI , is een van de belangrijkste cijfers voor een onderneming. Het (vooraf) berekenen van de ROI kan lastig zijn, zeker als je niet weet welke  return  je kunt …

webuildapps blog 2018 01 1515165629 app marketing guide webuildapps

Hoe promoot ik een een app: een app marketing guide

  • donderdag 7 april 2016

De mobiele app markt is een uitdagende omgeving. Jaar na jaar wordt het moeilijker voor app developers om eruit te springen tussen de tienduizenden nieuwe apps iedere maand in de  Apple App Store …

webuildapps blog 2016 03 kosten app laten maken header webuildapps

Wat kost een app laten maken?

  • dinsdag 8 maart 2016

Bijna letterlijk 'The one million dollar question', ' Wat kost het laten maken van een app ?'. In dit blog leggen wij verder uit welke zaken onderdeel uitmaken van de kosten bij het maken van een …

ZOEK JE EEN PROFESSIONELE APP BOUWER MET VERSTAND VAN TECHNIEK ÉN BUSINESS?

Wij luisteren naar jouw verhaal en samen gaan we aan de slag om waarde te creëeren voor jouw business. Vanaf de eerste gedachte tot ver voorbij de realisatie. Neem contact op voor een kennismaking of vraag direct een offerte aan!