Da iPhone 3G blev præsenteret, benyttede Apple lejligheden til at invitere mobilbrugere indenfor i App Store, hvor de kunne downloade ”mere end 500 native applikationer”, som det hedder i Apples pressemeddelelse fra dengang.
Ordet ”native” anvendes flere gange i pressemeddelelsen for at understrege, at der er tale om en ny måde at anvende sin mobil til at tilgå og anvende information på.
I 2008, da iPhone 3G kom frem, var det allerede muligt at gå på nettet med forskellige mobilbrowsere og - med mere eller mindre held - at få websider, som oprindeligt var tiltænkt computerskærme med masser af plads, skaleret ned til eksempelvis en 3,5-tommers mobilskærm, som var iPhone 3G's skærmstørrelse. Men i modsætning til de HTML-baserede websider var Apples ”native” apps skrevet i Objective-C og tilpasset mobilens skærmstørrelse. De var kompileret til iOS-platformen og havde direkte adgang til iPhonens indbyggede features som accelerometer, hardwareaccelereret 3D-grafik og stedbestemmelse.
Flere platforme, flere teknologier
Der er sket en voldsom udvikling i app-universet i løbet de seneste fem år. Smartphone-brugere har ud over en eksplosion i udvalget af iPhone-apps - antallet af apps i App Store nærmer sig en million – også fået en reel alternativ mobil app-platform i form af Googles Android og den tilhørende app-markedsplads Google Play, hvor antallet af apps også nærmer sig millionen. Microsoft forsøger at etablere Windows Mobile som en tredje app-platformsmulighed, dog er udbuddet af apps i Windows Store markant mindre.
Det øgede platformsudbud betyder flere muligheder for, at app-udviklere kan tilbyde deres apps til forskellige mobilbrugere, men platformsvariationen giver også en række udfordringer.
C-varianter, Java og HTML5
Mens programmeringssproget til iOS-apps er Objective-C, er det Java, der anvendes på Android-platformen og C#, der anvendes på den mobile Windows-platform. Hvis udviklere ønsker, at deres apps skal være tilgængelige på alle tre platforme, kræver det, at de vedligeholder tre forskellige kodebaser for den samme app. Et alternativ til den ressource- og tidsmæssige tunge opgave, det er at vedligeholde tre kodebaser, er at vælge en teknologi, som kan anvendes på alle tre platforme. Her kommer en kombination af webteknologier - som HTML5, CSS og Javascript - til undsætning, da de understøttes af alle browsere. Dog varierer browser-understøttelsen af de forskellige HTML5-features, ligesom det er vigtigt at huske, at HTML5 ikke er en endeligt vedtaget webstandard.
Et andet alternativ er at kombinere HTML5 og native apps i en hybrid app. Det kan gøres ved at benytte sig af udviklingsframework som eksempelvis Phonegap, hvor udviklere kan konstruere en mobilløsning i HTML5, CSS og Javascript, hvorefter frameworket sørger for at kombinere HTML5 og native kode til en hybrid app, der har adgang til features som accelerometer, kamera og andre mobilspecifikke features.
Har native apps vundet?
Selvom de to alternativer umiddelbart lyder besnærende, er det ikke udviklingsstrategier, som Ole Gammelgaard Poulsen har valgt. Han er partner og senior developer i app-udviklingshuset Shape og har arbejdet med app-udvikling i de seneste fire år. Han mener nemlig, at der er en række problemer med den slags cross-platformsudvikling.
– Vores erfaring er, at selvom HTML5 understøtter alle platforme, så kan man bruge meget tid på at optimere til platformene, siger Ole Gammelgaard Poulsen.
Samtidig fremhæver han, at brugeroplevelsen og performance i de HTML5-baserede apps ofte er ringere end i de rene native apps.
Shape har prøvet at anvende HTML5 til at lave prototyper for apps, men når det kom til at udvikle en produktionsmoden app, er valget altid faldet på native kode. Shape har også overtaget HTML5-baserede app-projekter fra andre udviklingshuse for selv at færdiggøre dem som native apps.
Den slags oplevelser fik Ole Gammelgaard Poulsen til at skrive en blog i Computerworld i september i år med titlen ”Native app-udvikling har vundet”. Det holder han fast i, selvom han medgiver, at det i enkelte tilfælde vil give mening at erstatte en app med HTML5.
– Hvis man udvikler et website, der skal kunne tilgås fra mobile enheder, er det ikke nødvendigvis noget, der skal ligne en app, mener Ole Gammelgaard Poulsen.
Værktøjsvalg efter opgave
Kristian Langborg-Hansen, der er partner hos App Academy, er ikke enig i Ole Gammelgaard Poulsens betragtning, at native app-udvikling har vundet. App Academy rådgiver og underviser i app-udvikling, ligesom firmaet er involveret i udvikling af apps, som ofte trækker på information fra eksisterende systemer. Til det formål anvender App Academy cross-platform-udviklingsværktøjet PhoneGap.
– Eksisterende logik kan rammes med en webservice. Det betyder, at vi lander i en app-kategori med masser af brugergrænseflade, men næsten ingen logik. Det er hurtigere at lave i HTML5 end i native kode, siger Kristian Langborg-Hansen.
Især hvis flere platforme skal understøttes på samme tid, lyder vurderingen. Kristian Langborg-Hansen er dog enig med Ole Gammelgaard Poulsen i, at HTML5 og hybride apps generelt er langsommere end native apps.
– Hvis performance er meget vigtig, og der er meget forretningslogik, som skal køre på mobilen, kommer HTML5 til kort, siger han.
Kristian Langborg-Hansen anbefaler derfor, at man vælger udviklingsværktøj efter, hvilken type app der skal udvikles.
Forretningslogik på serveren eller i skyen
App Academy har da også selv udviklet en app i ren native kode, da en app skulle udveksle data med et backend-system via en ikke-standardiseret kommunikationsprotokol. Da kunden allerede havde besluttet, at app'en skulle køre på Android, valgte App Academy at udvikle app'en i Java.
I langt de fleste tilfælde er det dog muligt at anvende, eller eventuelt udvikle, et Rest-API, så data kan hentes via Javascript-teknologier som eksempelvis Jquery.
Ole Gammelgaard Poulsen bifalder ideen om at have så meget af forretningslogikken på serversiden som muligt, og Shape gør også en dyd ud af at etablere service-API'er, som kan anvendes af forskellige klienter.
– Hvis arkitekturen er fornuftig, bør det være enkelt at etablere et API til forretningslogikken, som de mobile enheder kan benytte, siger han.
En række virksomheder og standardsystemer har allerede API'er, som kan kaldes fra apps. Eksempelvis har Shape udviklet en iPad-app, der anvender det cloud-baserede Salesforces API til at udveksle data mellem salgssystemet og tablet-app'en, ligesom der udveksles data med et Rails-baseret Content Management System.
Platformsvalg
Hos Shape foregår det meste af app-udviklingen på iOS-platformen. Med 11 Objective-C udviklere til iOS-platformen og blot to Java-udviklere, der fokuserer på Android-platformen, er det klart Apple-platformen, som Shape satser på udviklingsmæssigt, men det kan ændre sig alt efter, hvad kunderne ønsker.
Eksempelvis udvikler Shape ikke til Windows-platformen, men Ole Gammelgaard Poulsen følger interesseret med i, hvad der sker på Microsofts udviklingsplatform.
– Vi sværger til Mac, men skal vi være ærlige, så er Visual Studio et meget fint værktøj, lyder vurderingen fra Ole Gammelgaard Poulsen.
Set fra en kommerciel synsvinkel er det dog ikke nok, at en platform har et fint og teknisk interessant udviklingsmiljø. Antallet af Windows Phone-mobilbrugere er stadig lille, så der er tale om en relativt høj udviklingspris pr. potentiel app-bruger.
Hos App Academy anvendes den kommercielle udgave af PhoneGap, hvilket giver adgang til et online build-miljø.
– Vi behøver ikke at have alting kørende selv. Vi uploader vores kode og kan få bygget til alle platforme i et go, forklarer Kristian Langborg-Hansen.
