YipYip is een

Native app ontwikkelaar

.

Als app ontwikkelaar krijgen we vaak de vraag voor een Native app. Voor iOS ontwikkelen we dan ook in Swift en voor Android in Kotlin.

Hybride app vs. Native app laten ontwikkelen

Wat zijn de verschillen tussen een Hybride en Native app?

Hybride apps zijn apps die geschreven zijn in een andere taal dan de taal van het platform. Voor iOS app ontwikkeling kiezen wij voor Swift en voor Android app ontwikkeling voor Java of Kotlin. Hybride apps kunnen geschreven worden in HTML, Javascript, .NET of C#. Een framework (Xamarin, React Native, PhoneGap / Ionic, et cetera) verzorgt vervolgens de vertaling naar de Native app. Deze tussenlaag is waar naar ons idee een groot deel van de "problemen" ontstaan.

Flutter apps

De enige uitzondering die wij in de afgelopen 10+ jaar zijn tegengekomen is Flutter, deze tussenlaag is specifiek ontwikkeld door Google en zij hebben er dan ook belang bij dat er steeds meer Flutter app ontwikkelaars bij komen.

Waarom een Native app ontwikkelen?

Het is vaak de juiste keuze om voor een Native app te gaan.

Als het ogenschijnlijk goedkoper kan, waarom zou je dan niet een framework app laten maken? Het antwoord op deze vraag is eigenlijk heel eenvoudig. De eerder genoemde frameworks zijn altijd een "black box", zoals app ontwikkelaars dat noemen. Je schrijft de code in de taal van het framework en vervolgens wordt er een vertaalslag gemaakt.

Je weet als app developer dan ook niet zo goed wat er mis gaat áls het resultaat niet is wat je er van had verwacht – omdat er dus niet transparante vertalingen worden gedaan. Dat kan veel tijd kosten aan research, testing en vervolgens nieuwe uren aan app development. Daarnaast zijn dergelijke frameworks vaak overgeleverd aan de grillen van de maker (meestal start-ups uit Silicon Valley, soms zelfs zonder enige vorm van financiering) en worden ook nog wel eens massaal gedumpt of aan hun spreekwoordelijke lot over gelaten.

Anekdotes

Een voorbeeld: Xamarin bood bijvoorbeeld een aantal jaar geleden geen ondersteuning voor 64-bit apps en duurde het maanden voor ze deze ondersteuning wél boden, in de tussentijd konden er geen nieuwe iOS apps ingestuurd worden.

Een ander voorbeeld: SpriteBuilder (een framework om eenvoudig en snel animaties te kunnen ontwikkelen voor Cocos2D games), de medewerkers liepen weg omdat het bedrijf geen financiële middelen meer had. Gevolg is dat de founder gedwongen werd om een andere baan te zoeken en in zijn vrije tijd het framework verder te ontwikkelen en te ondersteunen. Dit leverde veel problemen op met onreleasebare apps tot gevolg.

Hoewel we er toe in staat zijn dergelijke frameworks zonder problemen in te zetten en uit te breiden, zijn we er door onze ervaringen veel voorzichtiger mee geworden. De enige manier waarop we een framework app verkopen is als we zeker weten dat dergelijke scenario's niet kunnen optreden en we een degelijke software oplossingen verkopen.

De stelregel is voor ons wel geworden: hoe belangrijker de app voor de (kerntaken van de) organisatie, hoe meer redenen om de app native te ontwikkelen.

Zijn hybride apps sneller te ontwikkelen dan native apps?

Ontwikkeltijd van beide opties vergeleken

Een veelgenoemd argument dat een hybride app veel sneller te ontwikkelen zou zijn dan een native app, omdat je het slechts één keer hoeft te schrijven en er veel libraries beschikbaar zijn zou dat tot wel 50% tijdwinst opleveren.

Dit argument gaat in onze ervaring niet op. Voor native apps zijn er óók talloze libraries beschikbaar – die zeker niet onderdoen voor de hybride versies – en onze ervaring is dat het testproces (inclusief debugging & fixen) aanzienlijk groter is dan als we de app native ontwikkelen. De native libraries worden ook vaak beschikbaar gesteld door Apple en Google en zijn dan ook van hoge kwaliteit. Zij hebben er tevens commercieel veel baat bij om deze libraries zo lang mogelijk in stand te houden en tijdig te communiceren zodra ze hier rigoreuze wijzigingen in doorvoeren. Sommige van de libraries gaan al tientallen jaren mee.

Dan hebben we het ook nog niet over het grootste risico gehad; dat de ontwikkelaar van het betreffende framework ermee stopt. Dat is in de afgelopen jaren talloze keren gebeurd en vormt een groot risico voor de continuïteit van een app. De meeste apps worden niet voor een éénmalige marketingcampagne ontwikkeld en moeten voor meerdere jaren worden onderhouden. Een partij die geen verdienmodel heeft leunt veelal op een community van ontwikkelaars, een community die kan krimpen of zelfs verdwijnen.

Een native app kan dus ook optimaal gebruikmaken van de mogelijkheden die het iOS en Android platform biedt, zal altijd te updaten blijven en beschikt dus ook over vele libraries en mogelijkheden om frameworks van derden in te laden. Dit laatste doen we regelmatig voor hele specifieke functionaliteit.

Conclusie

De conclusie met betrekking tot de tijdwinst is: het is zeker mogelijk maar het argument weegt niet zo zwaar als vaak wordt gedacht. Er is, mits een app goed wordt ontwikkeld, tijdwinst te behalen met bijvoorbeeld Flutter, maar je moet er als app maker enorm voor waken dat je deze tijd niet in een later stadium ineens weer moet inhalen. De tijdwinst bedraagt dan ook zeker geen 50% maar eerder 30-40%.

Achtergrond van de app ontwikkelaar

De achtergrond van een app bouwer is belangrijker dan het lijkt

Veel webbureaus die apps zijn gaan maken gebruiken hybride technieken, omdat het simpelweg "bekend terrein" is en ze het gewend zijn. YipYip is niet ontstaan vanuit de ontwikkeling van websites en we hebben in de afgelopen jaren altijd maatwerk software ontwikkeld. Omdat we platform agnostisch denken zijn we altijd zeer bewust van de keuzes die we maken en kunnen we goed omgaan met veranderingen.

Momenteel werken we veel aan native apps vanwege de grote voordelen. We hebben veel ervaring en als we merken dat we onze apps sneller kunnen ontwikkelen met dezelfde hoge kwaliteit zullen we dat zeker niet nalaten. Daarom werken we intussen ook vaak met Flutter — een open-source, cross-platform mobile development framework van Google. We hebben de ontwikkelen hiervan nauwkeurig in de gaten gehouden en het framework heeft (voor bepaalde type apps) zeker een plek verovert in de markt.

Flutter biedt namelijk veel mogelijkheden om het view gedeelte sneller op te kunnen zetten en is op dit moment steeds volwassener aan het worden. We zetten inmiddels Flutter steeds vaker in voor productieomgevingen waar de budgetten niet toereikend zijn om een Native app te laten maken of waar de app “interface-heavy” is en er weinig complexe algoritmes of views bevat.

De opkomst van Progressive Web Apps (PWA)

Een andere interessante stroming is de recente opkomst van Progressive Web Apps (PWA). Een Progressive Web App is in feite een website die zich voordoet als een echte mobiele app. Een groot verschil met Hybride vormen is dat je uiteindelijke app (het gecompileerde eindproduct) niet compileert naar Native code maar ook echt in Front-end technieken (HTML, CSS & JavaScript) houdt. Een PWA draait dan ook altijd in een webview component.

Een PWA kun je het beste zien als een offline website. Omdat het echter nog steeds een website is zul je wel eerder internet nodig hebben (om data te kunnen updaten) dan in een "echte" app, maar in theorie kun je een PWA volledig offline laten werken.

Voordelen van een Progressive Web App

  • Sneller te ontwikkelen omdat je voor 3 platformen (iOS, Android & web) slechts één keer hoeft te ontwikkelen met zeer weinig platform specifieke instructies.
  • Worden geïndexeerd door zoekmachines. Google geeft hier zelfs extra punten voor.
  • Onderdeel van je bestaande website of platform, gebruikers hoeven dus geen app te downloaden en slechts de app op hun homescherm te plaatsen.
  • App hoeft niet in de App Store en Google Play te worden gezet, dat scheelt in kosten aan deze platformen maar ook het proces van insturen is niet nodig.

Nadelen van een Progressive Web App

  • Op iOS loopt de ondersteuning voor PWA's flink achter. Er is minder mogelijk (de ontwikkelaar heeft weinig controle over offline opslag, deze is slechts tijdelijk en beperkt).
  • Push-notificaties zijn complexer om in te bouwen dan in een native app, op iOS is het überhaupt (nog) niet mogelijk in een PWA.
  • Omdat het een web-app is kun je vooral wat je in een website ook zou kunnen, veel verwerkingskracht en mogelijkheden van het mobiele device zijn dus niet beschikbaar.
  • Support in de background is uitermate beperkt.
  • Je moet ook een goede website hebben, anders is het nut weg.
  • Een PWA wordt in de regel niet ingestuurd in de App Store. Het is mogelijk maar de kans op afwijzing is aanwezig en het is de vraag of het wel noodzakelijk is. Het hele idee van een PWA is immers dat ze eenvoudig benaderbaar zijn.

We houden deze ontwikkelingen nauwlettend in de gaten en nemen de overweging voor een PWA ten alle tijden mee, niet alleen als een Native iOS en/of Android app budgetair niet mogelijk blijkt.

Waarom een Native app ontwikkelaar?

  • Native app ontwikkeling biedt net als bij hybride apps de mogelijkheid om frameworks en libraries te gebruiken.
  • Een native app geeft altijd de hoogst mogelijke performance en meeste flexibiliteit in de toekomst.
  • Native apps zullen altijd blijven worden ondersteund door het platform, Apple en Google hebben daar veel belang bij.
  • Binnen een native app heb je eenvoudigere mogelijkheden om platform-specifieke designs of functionaliteit te ontwikkelen.
  • Je hoeft niet beide apps te updaten en testen als je een update uitvoert voor een nieuwe versie van Android of iOS.
  • Een native app is de snelste manier om nieuwe features van iOS en Android te kunnen ondersteunen. Denk bijvoorbeeld aan nieuwe mogelijkheden die Bluetooth kan bieden of de ondersteuning van App Clips.

Meer weten over het laten maken van een native app?

Wilt u meer weten over het laten maken van een native app? Neem gerust contact met ons op voor een vrijblijvende kennismaking. We delen graag onze kennis over dit onderwerp.