Det er tre måter å velge smarttelefonopplevelse på: av operatør, av enhet og av apper. Valg av operatør plasserer kvaliteten på mobiltjenesten din først, mens det å ta en beslutning basert på enheten betyr at du er ute etter en spesifikk plattformopplevelse og maskinvarefunksjoner. Men å velge etter apper kan være vanskeligere.
Det nåværende utvalget av mobile økosystemer er samtidig fragmentert og enhetlig på tvers av plattformer. Noen store apper er tilgjengelige på mange plattformer, det samme er apper fra mindre utviklere. Andre apper er eksklusive for en plattform i kraft av funksjoner som er unike for operativsystemet eller ressursbegrensningene til utvikleren. Men hvis du virkelig trenger den ene appen, betyr ikke transportøren eller enheten så mye.
Men hva om alle apper kan være tilgjengelige på alle plattformer? Er utvikling på tvers av plattformer noe utviklere bør være opptatt av, og er det fallgruver å møte? Er det bedre å bygge en app spesifikt for hver plattform, eller skal appen bygges med et plattformbasert nettbasert rammeverk?
Brukere og utviklere kan være enige om at det å ha en app tilgjengelig uavhengig av plattform er et flott ideal. Men til hvilken pris?
La oss få samtalen i gang!
I virkeligheten er spørsmålet mer komplisert. Oftere enn ikke har "den neste store tingen" blitt opprettet av en virkelig talentfull utvikler eller et lite team som rett og slett ikke har ressurser, ferdigheter eller evner til å programmere plattform. Vi så dette tidlig på Instagram og Android - selskapet bak appen hadde bare tretten ansatte. Slike begrensninger forsinket en Android Instagram-app i noen tid, og selv nå etter å ha blitt kjøpt av Facebook for en milliard dollar, de har fremdeles ikke gitt ut en app som er kompatibel med BlackBerry 10 eller Windows Telefon.
Plattformen må ofte treffe en usynlig og tvetydig beregning som den betraktes som 'akseptert' av massene.
De små firmaene er ikke alene her, da vi ofte ser massive medieselskaper nøl med å bygge apper på tvers av plattformer. Plattformen i spørsmålet må ofte treffe en usynlig og tvetydig beregning som den betraktes som 'akseptert' av massene, og først da vil selskaper vurdere å lage en app for den. Noen ganger vil utviklere som er "fans" av et bestemt operativsystem først bygge en app for den plattformen, selv om den gigantiske markedsandelen ikke er der. Dette skjedde med den offisielle Disqus-appen for Windows Phone, som var den første (og hittil eneste) mobile plattformen som fikk en offisiell app fra kommenteringstjenesten.
Så ja, selskaper bør alltid streve for å gå på tvers av plattformer når de kan, og hvis de ikke kan det, bør de nå ut til utviklere i det samfunnet for å jobbe med et partnerskap. Foursquare gjorde dette da utvikleren Zhephree uavhengig laget en Foursquare-app for webOS tilbake i 2009, og appen ble de facto Foursquare-appen for plattformen. Dessverre er det en sjelden forekomst, og for ofte saddes forbrukerne med appvalg som ikke inkluderer det nyeste eller beste bare på grunn av deres valg av mobilplattform.
Ville et programmeringsspråk på tvers av plattformer som HTML5 eller Unity for spill hjelpe? Standarder er absolutt bedre enn kaos, men som vi har sett med HTML5 så langt, har det vært mest hype i stedet for en suksess.
WSelv om det er unntak fra hver regel, vil jeg virkelig leve i en verden der de fleste mobilappene er plattform og bare jobber når og hvor jeg vil at de skal. Ta nettet for eksempel. Jeg kan komme til nesten hvilket som helst nettsted fra nesten hvilken som helst enhet på markedet. Facebooks nettsted bryr seg ikke om jeg er på en Mac eller Windows PC, på en smarttelefon eller et nettbrett, på Android eller BlackBerry 10.
Så lenge plattformen har en moderne nettleser, kan jeg komme til stort sett alle nettsteder jeg vil ha. Jeg kan bygge og distribuere et nettsted til et komplett utvalg av enheter, og alle kan se det. For det meste, hvis nettstedet holder seg til standarder, fungerer det virkelig "bare".
Tilstanden for plattformapper for mobilapper er ganske annerledes.
Ta Android Central, CrackBerry, iMore og Windows Phone Central. Nettstedene bruker veldig lignende kode og fungerer på de fleste stasjonære eller mobile nettlesere. Fire nettsteder, alle nettlesere. God avtale.
Men å gjøre det med apper vil bety at du bruker separate, vesentlig forskjellige rammer for Android, BlackBerry 10, iOS og Windows Phone for hver av nettstedens apper. Fire apper ganger fire plattformer for totalt seksten apper. Ikke så bra.
Det samme kan sies om tilbehør som er avhengige av tilkoblede apper. Nike + FuelBand ble lansert som bare iOS, men for den investeringen Nike legger i maskinvaren, støtter de ideelt sett alle plattformer. Mange ikke-iOS-brukere kunne ha kjøpt en for helligdager i 2012, men at FuelBand ikke støttet og fortsatt ikke støtter andre plattformer, begrenser det potensielle markedet. Brukerne bryr seg ikke om plattform - alt som betyr noe er at det fungerer med enheten deres.
Jeg er håpefull om at HTML5 vil være kraftig og fleksibel nok til at du kan produsere nesten innfødte apper i den. Og hvis det er tilfelle, foretrekker jeg HTML5.
- Leo LaporteSjef TWiT, TWiT.TV
Ingen vil ha en app på BlackBerry 10 som ser ut akkurat som den gjør på iOS, og som ikke inkluderer støtte for BlackBerry 10-bevegelser.
Spill er ofte lengst fremme på dette takket være plattformmotorer som Unity og Titanium. Imidlertid har spill en tendens til å ha sine egne grensesnitt som ikke samsvarer med plattformen. Ikke-spillapper er forskjellige. Mens apper kan dele vanlige funksjoner, tjenester og til og med kode mellom plattformer, trenger de plattformens utseende og følelse, og kan dra nytte av plattformsspesifikke funksjoner. Ingen vil ha en app på BlackBerry 10 som ser ut akkurat som den gjør på iOS, og som ikke inkluderer støtte for BlackBerry 10-bevegelser.
Til slutt, hvis du tar plattformeiere, produsenter og til og med utviklere ut av ligningen, vil folk bare ha appene de elsker på enhetene de elsker. Det betyr at hver større app trenger å støtte hver større plattform. Nå.
Tteoretisk sett, å ha de samme appene på alle plattformene, burde det ikke være bra, ikke sant? Flere apper flere steder. Men den skuffende sannheten er at selv i dag er ikke alle appene skapt like.
Ulike plattformer gjør ting annerledes. Noen ganger er det et spørsmål om maskinvare. BlackBerry 10 og Windows Phone har ikke den rene prosessorkraften til Android. Apples iOS er uten tvil lettere å utvikle for og kan gjøre mer med mindre. Og så kan en app som er tilgjengelig for iPhone og iPad ha annen funksjonalitet enn den ville ha på Android eller BlackBerry 10 eller Windows Phone. Vi har faktisk sett forekomster av populære apper som mister en betydelig del av funksjonaliteten når de blir portet fra en plattform til en annen.
Den skuffende sannheten er at selv i dag er ikke alle appene skapt like.
Det er imidlertid ikke alltid så dypt. Noen ganger er det bare et spørsmål om utseende. Kanskje en app bare ikke ser like bra ut på en plattform som en annen. Overfladisk? Kanskje. Apper skal ha en jevn opplevelse på tvers av plattformer. Eller i det minste prøve å få den samme opplevelsen. Men de trenger fortsatt å ha en plattformerfaring også. Det er et tøft hår å dele.
Den gode nyheten er at apper er flytende dyr. De endrer seg og forbedrer seg kontinuerlig. Sannsynligvis ikke så raskt som vi alle vil, men sjelden er det populære programmet som aldri blir oppdatert, aldri forbedrer seg og aldri redesigner seg selv.
HTML5-apper er bygget ved hjelp av nettstandardteknologier som HTML, CSS og JavaScript. Disse appene kjører i nettlesere, som Google Maps eller iCloud.com, eller på lokale enheter som Chrome OS eller den sene, beklagede webOS. Fordi så mange utviklere allerede vet hvordan de skal bygge rike nettopplevelser, antas det generelt at HTML5-apper vil være den enkleste veien for å få utviklerne på mobil. Derav alt fra Apples originale "søte" løsning av apper i iPhone-nettleseren til Palm's Mojo og senere Enyo-rammer til BlackBerrys WebWorks.
Det har ført til antagelsen, generelt fra ikke-utviklere, at HTML5 er det siste, beste håp for en utopisk fremtid der apper blir skrevet en gang og distribuert overalt, plattform, fra skrivebord til nettbrett til telefon og til alt og alt i mellom.
Og det er en haug med BS.
Apples originale "søte" løsning fungerte så dårlig at de klatret for å slippe den opprinnelige App Store et år senere, kalenderappen på webOS 1.0 tok tjue sekunder å starte, og Google produserer langt bedre opplevelser med native-kodede apper på Android og iOS enn de er på nett. Selv de beste mobilnettappene, som Gmail.com og forecast.io, blekner i forhold til deres rikere, bedre ytende innfødte fettere.
Innfødte apper vil ha nytte av ny maskinvare og nye rammer. Ledelsen deres vil forbli, hvis ikke vokse.
Noen sier at når maskinvaren blir kraftigere og JavaScript forbedres, vil ytelsen og funksjonaliteten til webappene øke. Det er helt sant. Men innfødte apper vil også ha nytte av ny maskinvare og nye rammer. Ledelsen deres vil forbli, hvis ikke vokse.
Derfor kalles HTML5-apper fremtiden - den kommer alltid, men kommer aldri helt.
Å prøve å lage en hel app i HTML5 er som å prøve å lage en hel app som eksisterer helt offline, i flymodus. Det er ikke umulig, men det er ikke ideelt, og det begrenser omfanget og opplevelsen i stor grad.
Hvis HTML5 noen gang blir mer utbredt enn innfødte apper, er det en verden jeg ikke vil leve i.
- Matt Bischoff og Brian Capps,iOS-ingeniører, Lickability
Det kommer ned til dette: Internett er best til å gi dynamiske data, og innfødte apper er best for grensesnitt og interaktivitet. Flotte apper vil bruke det beste av begge. Som iTunes. Som Google Maps for Android og iOS. Som den nye native versjonen av Facebook for mobil (til og med Facebook lærte den leksjonen på den harde måten).
HTML5 er på ingen måte apper som er den aller slutt. Men det er en utrolig viktig del av fremtiden.
Cross-plattform applikasjoner er en vanskelig innsats. Utviklere må navigere i SDKer og API-er og UI- og UX-guider, mens de prøver å opprettholde det unike utseendet, funksjonene og opplevelsen til sin egen app. Det er en balansegang mellom krav og ønsker, forventninger og begrensninger.
Ideelt sett vil apper som gir mening å være plattform være, og det ville være enkelt å gjøre det. Men det er et markant marked, og det er liten interesse fra de større plattformeierne for å gjøre det lettere å bygge apper som vil fungere på konkurrentenes enheter, mens de mindre spillerne vil gjøre det så enkelt som mulig å portere de samme apper.
Rammeverk og verktøy på tvers av plattformer eksisterer, men de har begrenset omfang og styrke. De gjør det lettere å bygge en jevn opplevelse på tvers av alle plattformer, men ofrer det som gjør hver plattform unik og kompromitterer med kvalitet og ytelse. Men å bygge en plattformtilpasset app tar tid og penger som ikke alle utviklere har.
Det er ikke noe godt svar - men hva er det beste?