Der er tre måder at vælge din smartphone-oplevelse: efter operatør, efter enhed og efter apps. Valg af operatør placerer kvaliteten af din mobiltjeneste først, mens det at tage en beslutning baseret på enheden betyder, at du er ude efter en specifik platformoplevelse og hardwarefunktioner. Men valg af apps kan være vanskeligere.
Den nuværende række mobile økosystemer er samtidigt fragmenteret og samlet på tværs af platforme. Nogle større apps er tilgængelige på mange platforme, ligesom apps fra mindre udviklere. Andre apps er eksklusive til en platform i kraft af funktioner, der er unikke for operativsystemet eller ressourcebegrænsningerne for udvikleren. Men hvis du virkelig har brug for den ene app, betyder transportøren eller enheden ikke så meget.
Men hvad hvis alle apps kunne være tilgængelige på alle platforme? Er udvikling på tværs af platforme noget, som udviklere bør være bekymrede for, og er der faldgruber at stå over for ved at gøre det? Er det bedre at oprette en app specifikt til hver platform, eller skal appen bygges med en tværbaseret webbaseret ramme?
Brugere og udviklere kan være enige om, at det er et godt ideal at have en app tilgængelig uanset platform. Men til hvilken pris?
Lad os få samtalen i gang!
I virkeligheden er spørgsmålet mere kompliceret. Oftere end ikke er "den næste store ting" skabt af en rigtig talentfuld udvikler eller et lille team, der simpelthen ikke har ressourcerne, færdighederne eller evnerne til at programmere på tværs af platforme. Vi så det tidligt med Instagram og Android - virksomheden bag appen havde berømt kun tretten ansatte. Sådanne begrænsninger forsinkede en Android Instagram-app i nogen tid, og selv nu efter at være blevet købt af Facebook for en milliard dollars har de stadig ikke frigivet en app, der er kompatibel med BlackBerry 10 eller Windows Telefon.
Platformen skal ofte ramme en usynlig og tvetydig måling, hvormed den betragtes som 'accepteret' af masserne.
De små firmaer er ikke alene her, da vi ofte ser massive medievirksomheder tøve med at oprette platforme-apps. Den pågældende platform skal ofte ramme en usynlig og tvetydig måling, hvormed den betragtes som 'accepteret' af masserne, og først derefter vil virksomheder overveje at lave en app til den. Lejlighedsvis vil udviklere, der er "fans" af et bestemt operativsystem, først bygge en app til den platform, selvom den gigantiske markedsandel ikke er der. Dette skete med den officielle Disqus-app til Windows Phone, som var den første (og hidtil eneste) mobile platform, der fik en officiel app fra kommenteringstjenesten.
Så ja, virksomheder skal altid stræbe efter at gå på tværs af platforme, når de kan, og hvis de ikke kan, skal de nå ud til udviklere i dette samfund for at arbejde på et partnerskab. Foursquare gjorde dette, da udvikleren Zhephree uafhængigt lavede en Foursquare-app til webOS tilbage i 2009, og appen blev de facto Foursquare-appen til platformen. Desværre er det en sjælden begivenhed, og for ofte sad forbrugerne med appvalg, der ikke inkluderer det nyeste eller bedste, simpelthen på grund af deres valg af mobilplatform.
Ville et programmeringssprog på tværs af platforme som HTML5 eller Unity til spil hjælpe? Standarder er bestemt bedre end kaos, men som vi hidtil har set med HTML5, har det for det meste været hype snarere end en succes.
WSelvom der er undtagelser fra enhver regel, vil jeg virkelig leve i en verden, hvor størstedelen af mobilapps er platformoverskridende og bare arbejder, når og hvor jeg vil have dem. Tag for eksempel internettet. Jeg kan komme til næsten ethvert websted fra næsten enhver enhed på markedet. Facebooks websted er ligeglad med, om jeg er på en Mac eller Windows-pc, på en smartphone eller en tablet, på Android eller BlackBerry 10.
Så længe platformen har en moderne webbrowser, kan jeg komme til stort set ethvert sted, jeg vil have. Jeg kan opbygge og implementere et websted til et komplet udvalg af enheder, og alle kan se det. For det meste, hvis webstedet holder sig til standarder, fungerer det virkelig "bare".
Tilstanden for mobilapps på tværs af platforme er helt anderledes.
Tag Android Central, CrackBerry, iMore og Windows Phone Central. Webstederne bruger meget lignende kode og fungerer på de fleste desktop- eller mobilbrowsere. Fire websteder, alle browsere. God handel.
Men at gøre det med apps ville betyde at bruge separate, væsentligt forskellige rammer til Android, BlackBerry 10, iOS og Windows Phone til hver af webstedsapperne. Fire apps gange fire platforme til i alt seksten apps. Ikke sådan en god aftale.
Det samme kan siges om tilbehør, der er afhængige af tilsluttede apps. Nike + FuelBand blev lanceret som kun iOS, men for den investering, Nike satte i deres hardware, ville de ideelt set understøtte alle platforme. Mange ikke-iOS-brugere kunne have købt en til helligdage i 2012, men at FuelBand ikke understøtter andre platforme og stadig ikke, begrænser dets potentielle marked. Brugere vil ikke bekymre sig om platforme på tværs - alt, hvad der betyder noget, er at det fungerer med deres enhed.
Jeg håber, at HTML5 vil være kraftig og fleksibel nok til, at du kan producere næsten native apps i den. Og hvis det er tilfældet, foretrækker jeg HTML5.
- Leo LaporteChief TWiT, TWiT.TV
Ingen ønsker en app på BlackBerry 10, der ser nøjagtigt ud som den gør på iOS og ikke inkluderer support til BlackBerry 10-bevægelser.
Spil er ofte længst fremme på dette takket være platforme-motorer som Unity og Titanium. Dog har spil en tendens til at have deres egne ikke-platform-kompatible grænseflader. Ikke-spil-apps er forskellige. Mens apps kan dele almindelige funktioner, tjenester og endda kode mellem platforme, har de brug for platformens udseende og kan drage fordel af platformsspecifikke funktioner. Ingen ønsker en app på BlackBerry 10, der ser nøjagtigt ud som den gør på iOS og ikke inkluderer support til BlackBerry 10-bevægelser.
I sidste ende, hvis du tager platformsejere, producenter og endda udviklere ud af ligningen, vil folk bare have de apps, de elsker på de enheder, de elsker. Det betyder, at enhver større app skal understøtte enhver større platform. Nu.
Tteoretisk set skal det være en no-brainer at have de samme apps på alle platforme, ikke? Flere apps flere steder. Men den skuffende sandhed er, at selv i dag er ikke alle apps skabt ens.
Forskellige platforme gør tingene forskelligt. Nogle gange er det et spørgsmål om hardware. BlackBerry 10 og Windows Phone har ikke den rene processorkraft fra Android. Apples iOS er uden tvivl lettere at udvikle sig til og kan gøre mere med mindre. Og så kan en app, der er tilgængelig til iPhone og iPad, have anden funktionalitet end den ville have på Android eller BlackBerry 10 eller Windows Phone. Faktisk har vi set forekomster af populære apps, der mister en betydelig del af deres funktionalitet, når de porteres fra en platform til en anden.
Den skuffende sandhed er, at selv i dag ikke alle apps er skabt ens.
Det er dog ikke altid så dybt. Nogle gange er det bare et spørgsmål om udseende. Måske ser en app bare ikke så godt ud på en platform som en anden. Overfladisk? Måske. Apps skal have en ensartet oplevelse på tværs af platforme. Eller i det mindste forsøge at få den samme oplevelse. Men de skal stadig have en platformoplevelse også. Det er hårdt hår at splitte.
Den gode nyhed er, at apps er flydende dyr. De ændrer og forbedrer konstant. Sandsynligvis ikke så hurtigt som vi alle gerne vil, men sjældent er det populære program, der aldrig bliver opdateret, aldrig forbedres og aldrig redesigner sig selv.
HTML5-apps er bygget ved hjælp af webstandardteknologier som HTML, CSS og JavaScript. Disse apps kører i browsere som Google Maps eller iCloud.com eller på lokale enheder som Chrome OS eller den sene, beklagede webOS. Fordi så mange udviklere allerede ved, hvordan man bygger rige weboplevelser, antages det generelt, at HTML5-apps er den nemmeste vej til at få disse udviklere til mobil. Derfor alt fra Apples originale "søde" løsning af apps i iPhone-browseren til Palm's Mojo og senere Enyo-rammer til BlackBerrys WebWorks.
Det er ført til formodningen, generelt fra ikke-udviklere, om at HTML5 er det sidste, bedste håb for en utopisk fremtid, hvor apps er skrevet en gang og implementeret overalt, på tværs af platforme, fra desktop til tablet til telefon og til alt og hvad der er i mellem.
Og det er en flok BS.
Apples originale "søde" løsning fungerede så dårligt, at de krypterede for at frigive den oprindelige App Store et år senere, kalenderappen på webOS 1.0 tog tyve sekunder at starte, og Google producerer langt bedre oplevelser med native-kodede apps på Android og iOS, end de er på web. Selv de bedste mobile webapps, som Gmail.com og forecast.io, er blegne i forhold til deres rigere, bedre udførte indfødte fætre.
Native apps vil drage fordel af ny hardware og nye rammer. Deres bly vil forblive, hvis ikke vokse.
Nogle siger, at når hardware bliver kraftigere, og JavaScript forbedres, vil webappens ydeevne og funktionalitet øges. Det er helt sandt. Men native apps vil også drage fordel af ny hardware og nye rammer. Deres bly vil forblive, hvis ikke vokse.
Derfor kaldes HTML5-apps fremtiden - den kommer altid, men ankommer aldrig helt.
At prøve at oprette en hel app i HTML5 er som at prøve at oprette en hel app, der findes helt offline i flytilstand. Det er ikke umuligt, men det er ikke ideelt, og det begrænser i høj grad omfanget og oplevelsen, der kan leveres.
Hvis HTML5 nogensinde bliver mere fremherskende end native apps, er det en verden, jeg ikke ønsker at leve i.
- Matt Bischoff og Brian Capps,iOS ingeniører, lickability
Det kommer ned på dette: Internettet er bedst til at levere dynamiske data, og native apps er bedst til interface og interaktivitet. Store apps bruger det bedste af begge. Ligesom iTunes. Ligesom Google Maps til Android og iOS. Ligesom den nye native version af Facebook til mobil (selv Facebook lærte den lektion på den hårde måde).
HTML5 er på ingen måde apps, der er alt-i-ende. Men det er en utrolig vigtig del af den fremtid.
Cross-platform applikationer er en vanskelig indsats. Udviklere skal navigere i SDK'er og API'er og UI- og UX-guider, mens de prøver at opretholde det unikke udseende, funktioner og oplevelse af deres egen app. Det er en balancegang mellem krav og ønsker, forventninger og begrænsninger.
Ideelt set ville apps, der giver mening at være på tværs af platforme, være, og det ville være let at gøre det. Men det er et markant marked, og de større platformsejere interesserer sig ikke meget for at gøre det lettere at opbygge apps der fungerer på konkurrenternes enheder, mens de mindre spillere ønsker at gøre det så let som muligt at porte dem helt ens apps.
Der findes tværgående platforme og værktøjer, men de er begrænsede i omfang og styrke. De gør det lettere at opbygge en ensartet oplevelse på tværs af hver platform, men ofrer det, der gør hver platform unik og kompromitterer med hensyn til kvalitet og ydeevne. Men at bygge en platform-tilpasset apps tager tid og penge, som ikke alle udviklere har.
Der er ikke noget godt svar - men hvad er det bedste?