Hvilke app-løsninger findes der?
Når du skal have udviklet en mobilapp, findes der 3 løsninger, du kan vælge imellem: Native app, hybrid app og web-løsning. Bliv klogere på de forskellige app-løsninger her. Se også vores visuelle overblik over forskellen mellem native app og hybrid app længere nede.
Hvad er en native app?
Native-løsninger er apps, der er udviklet til én bestemt type platform – f.eks. iOS eller Android. Skal app’en udkomme på iOS og Android skal der udvikles to kodebaser: Én kodebase til iOS (i programmeringssproget Swift) og én kodebase til Android (i programmeringssproget Kotlin). Der er altid fuld adgang til enhedernes hardware samt de nyeste funktioner i iOS/Android.
Hvad er en hybrid app?
Hybrid-løsninger er apps, der benytter en kombination af app og webteknologi. Fx. gennem frameworks og platforme som React Native, Xamarin, Flutter eller Cordova. Hybrid apps kaldes også cross-platform apps. I en hybrid app udvikles app’ens kildekode i ét sprog, som dernæst bliver “maskinoversat” til en iOS- og/eller Android app. Udviklingen af app’en sker gennem webteknologi uden hensyntagen til de enkelte platforme (iOS og Android).
Hvad er en web-løsning?
En web-løsning er den mest simple løsning, da det i princippet “bare” er et responsivt website, der er udviklet, så det fremstår mere brugervenligt, når det vises på en tablet og smartphone. En web-løsning fungerer på alle platforme, men er ikke en rigtig app, og vil derfor ikke være at finde i Apple App Store og Google Play Store. Datamæssigt er der også nogle lagringsmæssige begrænsninger.
Hvorfor anbefaler vi native app udvikling?
Det er ingen hemmelighed, at vi hos Makeable foretrækker native løsninger. Dette skyldes, at vi i bund og grund synes, at det er et bedre “stykke værktøj”. Det er simpelthen en bedre løsning både teknisk, forretningsmæssigt og for brugeren. Derudover er denne tilgang mere holdbar på den lange bane.
Nedenfor kan du blive meget klogere på forskellen på native apps og hybrid apps og læse mere om, hvorfor vi anbefaler native app udvikling.
Er tid og budget ikke en udfordring, så gå altid native. Der kan ikke argumenteres for, at native nogensinde vil være et dårligere valg end hybrid.
- Mads Erichsen, CEO & partner MakeableFordele ved native apps
Med native udvikling er performance i top og udnyttelsen af enhedens hardware optimal. Det giver altid det bedste resultat og er det sikreste valg, da der er fuld adgang til enhedernes hardware og altid adgang til de nyeste funktioner i enhedernes software/operativsystem (iOS/Android).
Hvis en app benytter hardware eller kommunikation med ekstern hardware som omdrejningspunkt, vil en native app give muligheden for at udnytte 100% af dennes potentiale. I modsætning hertil vil en hybrid app ikke uden uhensigtsmæssige tilpasninger kunne interagere med ekstern hardware.
Ulemper ved native apps
Eneste ulempe der i vores optik er ved native-løsninger er tid og budget. Native kan tage lidt længere tid at udvikle. Omvendt slipper du for, at der senere hen skal udvikles yderligere (native) elementer, hvilket ofte er tilfældet ved en hybrid app.
Derudover er det som regel nemmere at finde én person til at udvikle det hele ved en hybrid app, mens du ved native som regel har én person der er specialiseret i Android, og én der er specialiseret i iOS. Der skal altså flere udviklere med i processen. Her kan der så argumenteres for værdien i ikke at placere det hele ved et enkelt individ i forhold til det faglige niveau af den færdige app løsning.
Ved at bruge specialiserede udviklere får du desuden en app, der i højere grad overholder platformens standarder, fordi udviklerne kender disse. Der er på mange områder stor forskel på hvordan en app bør opføre sig på hhv. Android og iOS.
Fordele ved hybrid apps
Hybrid løsninger er som regel billigere end native løsninger. I hvert fald på den korte bane. Derudover kan du sætte et mindre team/en enkeltperson på opgaven, da samme ressource(r) varetager opgaven til begge platforme – så længe der ikke skal udvikles native elementer ind i den hybride app, hvilket er tilfældet for de fleste hybrid løsninger før eller siden. Her kan det selvfølgelig ses som en fordel, at muligheden for at tilknytte native moduler overhovedet er der.
Hybride løsninger er oplagte til mindre projekter og prototyper, der stiller mindre krav til app’ens ydelse.
Ulemper ved hybrid apps
Når en hybrid app er udviklet, kan den afvikles på både Android og iPhone. For at kunne håndtere begge systemer, gør den brug af et ekstra ‘oversættelses-lag’ der dikterer over for de to apps, hvad de må og skal. Der vil derfor blive inkluderet en ekstra, unødvendig afhængighed i app’en, som både på kort og på lang sigt kan give udfordringer for den forestående udvikling, fremtidige drift og vedligeholdelse af app’en.
Af denne grund performer en hybrid app ikke så godt som en native app, og der vil være begrænsninger i forhold til adgang til enhedens hardware. Eftersom en hybrid app indeholder et oversætterlag, som er leveret af 3. part (f.eks. Microsoft, Facebook eller Adobe), så vil der være en uhensigtsmæssig afhængighed af leverandøren af det software, der laver denne oversætter. Det kan give ulemper, når app’en skal driftes, og når Apple og Android opdaterer deres operativsystemer.
Derudover er de hybride udviklingssprog udviklet i store virksomheder, som primært har haft til formål at få udviklet apps til at drifte egne produkter. Af samme grund er interessen for at udvikle funktionalitet, der ikke er til fordel for egen platform, begrænset. Som eksempler kan nævnes:
- React Native udviklet af Facebook til egen platform
- Xamarin er udviklet af Microsoft til egen platform
- Flutter er udviklet af Google til egen platform
Desuden baserer hybrid værktøjer, til trods for at React har “native” i sit navn, sig på webteknologi og ikke app-teknologi. Hvis app’en får behov for at bruge en funktion, der endnu ikke er support for i den hybride platform, så skal der udvikles native iOS og Android kode, og her kommer hybrid-udvikleren hurtigt til kort.
Det samme gælder, når der skal integreres med tredjepartsservices. Langt de fleste tredjepartsservices udvikler kun SDK (udviklingskits/værktøjer) til native iOS og Android. Du kan derfor ikke bruge deres udstillede SDK’er, før der er udviklet en oversætter til det valgte hybrid-sprog.
Ofte skal en nativeudvikler alligevel inddrages
Som udgangspunkt bør du altid se en ren hybridløsning som muligheden for at kunne benytte laveste fællesnævner på de to platforme, forstået på den måde, at hvis noget kun er tilgængeligt på den ene platform, eksempelvis NFC-læsning eller lignende, så vil du ikke kunne benytte dette i en hybridløsning, da det skal være tilgængeligt på begge platforme.
Du kan dog vælge at inddrage noget native udvikling som “overbygning” på din hybridløsning for at åbne op for specifikke platforms-muligheder. Ved at gøre dette, vil en nativeudvikler skulle inddrages og herved mindskes den besparelse, som hybrid udviklingen har givet. Ligeledes øges kompleksiteten, hvilket påvirker driftsikkerheden.
Forskellen på native apps og hybrid apps
3 løsninger som Makeable har leveret som native apps:
dol-sensors
App til kommunikation med verdens største leverandør af sensorer i landbrugssektoren via NFC.
I denne løsning var det vigtigheden i at kunne kommunikere med ekstern hardware samt muligheden for at kunne supportere alle fremtidige typer hardware, der understøttede beslutningen om at vælge native udvikling.
Se hele casen her
FTZ
App til optimering af processer på mere end 1.000 autoværksteder i hele Norden.
Vigtigheden af at have en app, der reagerer hurtigt, har intuitiv navigation og har bred support på ældre enheder gjorde, at valget faldt på en native løsning.
Se hele casen her
MetriCorr
App til konfiguration af ekstern hardware via Bluetooth.
Kunden ønskede mulighed for at kunne udvikle nye typer hardware og kommunikationsformer og stadig sikre, at samme app og kodebase kunne anvendes og videreudvikles.
Kundens brugere spænder desuden bredt i IT-erfaring og alder. Derfor er det vigtigt at have en app, som er nem og intuitiv at anvende – også på de mere specielle, ældre enheder. Derfor faldt valget på en native løsning.
Se hele casen her
