Olette päättäneet tehdä mobiilisovelluksen, hienoa! Mutta kuinka se kannattaisi toteuttaa? Mobiilisovelluksen tekoa harkitessa tulee usein vastaan läjäpäin eri termejä. Avainsanojen lista on pitkä: iOS, Android, natiivi, cross-platform, hybridi, Swift, Kotlin, React Native, Cordova, Flutter ja niin edelleen. Eri toimittajien tarjonnassa nousevat esiin eri termit. Kuinka tietää, mitkä vaihtoehdoista sopisivat parhaiten juuri omiin tarpeisiin? 

Ensin lienee hyvä avata, mitä nämä sanat pääpiirteissään tarkoittavat. iOS ja Android ovat mobiililaitteiden käyttöjärjestelmiä. Ne kattavat niin globaalisti kuin Suomessakin yli 99 % koko markkinasta. Suomessa Androidin osuus on 72,5 % ja iOS:n 27,09 %. (Lähde: https://gs.statcounter.com) Hyvin harvoja poikkeuksia lukuun ottamatta muita käyttöjärjestelmiä ei kannata ottaa huomioon mobiilisovelluksia tehdessä. 

Loput mainituista sanoista liittyvät siihen, kuinka näille kahdelle alustalle voidaan sovelluksia tehdä. Natiivi, cross-platform ja hybridi kertovat siitä, kuinka monelle eri alustalle sama koodi taipuu. Natiivin osalta samalla koodilla voidaan tehdä vain yksi sovellus, eli alustana on ainoastaan iOS tai Android. Cross-platformin avulla saadaan sama koodi toimimaan kummallakin mobiilikäyttöjärjestelmällä. Hybridi taas mahdollistaa cross-platformin lisäksi myös tietokoneen verkkoselaimella käytettävän version julkaisun. 

Viimeiset termit kuvaavat eri ohjelmistokehyksiä (engl. software framework) ja ohjelmointikieliä, joiden avulla sovellus voidaan toteuttaa. Alussa mainituista termeistä natiivivaihtoehtoja ovat Swift (iOS) ja Kotlin (Android). Cross-platformia niistä ovat Flutter sekä React Native ja hybridiä Cordova. 

Todellisuudessa vaihtoehtoja on olemassa vielä rutkasti enemmän, ja niitä julkaistaan jatkuvasti lisää etenkin cross-platformin ja hybridin puolelle. Niiden tarkempi läpikäynti ei ole kuitenkaan nyt tärkeää. Tuotteen menestyksen kannalta käytettävä ohjelmointikieli on usein toissijainen valinta, sillä tärkeämpää on miettiä, mitä edellä mainituista toteutustavoista käytetään: natiivia, cross-platformia vai hybridiä.  

Eri vaihtoehtojen edut 

Mikä kutakin toteutustapaa sitten puoltaa? Yksinkertaistettuna natiiviteknologioilla saadaan tehtyä käytettävyydeltään parhaat, nopeimmat ja monipuolisimmat sovellukset. Lisäksi natiivin takana on aina suoraan käyttöjärjestelmän kehittäjä eli Androidin tapauksessa Google ja iOS:n kohdalla Apple. Näin natiivi kulkee aina rinta rinnan käyttöjärjestelmän päivitysten mukana. Varjopuolena ovat miltei kaksinkertaiset kehityskustannukset, kun sama sovellus täytyy tehdä kahteen kertaan. 

Cross-platformissa siirrytään askeleen verran poispäin natiivin eduista, mutta saadaan yhdellä koodilla sovellus kummallekin alustalle. Käytettävyyden ja nopeuden osalta ei jäädä useinkaan kovin kauaksi natiivista, mutta monimutkaisempien ominaisuuksien toteuttamisessa alkaa näkymään haasteita.  

Pitkälti samat asiat ovat mahdollisia toteutustavasta riippumatta.

Sama suunta jatkuu hybridin kanssa; jälleen saadaan yksi alusta lisää saman koodin tuettavaksi, mutta silloin kärsii usein jo käytettävyys ja nopeuskin. Isona etuna hybriditeknologioille on se, että niitä tehdään pääasiassa web-kehittämisen ohjelmointikielillä. Tällöin osaajia on huomattavasti helpompi löytää kuin esimerkiksi iOS-natiivin tekijöitä. Osaajien suurempi määrä saattaa tarkoittaa myös halvempia hintoja, mutta toisaalta heillä ei välttämättä ole kokemusta mobiilisovellusten kehityksestä. 

Yhteenvetona voidaan sanoa, että pitkälti samat asiat ovat mahdollisia toteutustavasta riippumatta. Korkeamman laadun saavuttaminen edellyttää kuitenkin tuettujen alustojen määrän karsimista. 

Pelkän kustannustehokkuuden tuijottaminen toteutustavan valinnassa ei vie suunnitelmia sovelluksen kehittämisestä oikeaan suuntaan. Valintaan vaikuttaa moni muukin asia, ja oikeasti edullisempi ratkaisu saadaan, kun ajatellaan tuotetta useammalta kulmalta ja koko elinkaaren ajalta. 

 Sovelluksen tarpeet ja tavoitteet 

Jotta valinta voidaan tehdä hyvin, täytyy perustelut sovelluksen kehittämiselle olla selkeät. Tämä tarkoittaa muun muassa käyttäjien, markkinatilanteen, ominaisuuksien ja tavoitteiden hyvää tuntemusta.  

Täysin suoraviivaista ohjeistusta teknologioiden valinnalle on haastava antaa, mutta seuraavien neljän kohdan avulla pääsee hieman hajulle siitä, minkä tyylinen ratkaisu voisi toimia omiin tarpeisiin. On kuitenkin syytä huomioida, että toteutustavan vaihtaminen julkaisun jälkeen on huomattavasti kalliimpaa kuin oikean valinnan tekeminen heti alussa. Sen vuoksi seuraavia kohtia tulee harkita sovelluksen koko elinkaarta eikä vain sen ensimmäistä versiota ajatellen.  

• Vaatimukset – Mikäli sovellukselta vaaditaan paljon erilaisia ominaisuuksia ja etenkin sellaisia, joita ei kilpailevista tuotteista löydy, niin natiivilla sen tekeminen on yleensä helpompaa. Yksinkertainen sovellus, joka koostuu ns. peruskomponenteista (tekstiä, kuvia, listoja, nappeja, jne.) onnistuu sen sijaan helposti millä tahansa toteutustavalla.

• Kilpailu – Jos vastaavia sovelluksia löytyy sovelluskaupoista useita ja kilpailu on kovaa, on natiivilla paremmat mahdollisuudet pärjätä kilpailussa. 

• Rooli liiketoiminnassa – Sovelluksen ollessa kriittisessä roolissa liiketoiminnalle, esimerkiksi yksi tärkeimmistä tuotteista, on natiivi usein kannattava investointi.

• Ennustettu ikä – Pitkäikäiseksi tarkoitettu sovellus on turvallisinta tehdä natiiviteknologioin, sillä niiden takana on aina käyttöjärjestelmän kehittäjän tuki. Lyhytikäisen sovelluksen kannalta tuen jatkuvuus ei ole niin merkittävä, jolloin kaikki toteutustavat kelpaavat siltä osin. 

 Jos mikään edellä mainituista neljästä kohdasta ei ole erityisen korostunut omissa tarpeissa, ovat cross-platform ja hybridi todennäköisesti kannattavampia vaihtoehtoja. Siinä vaiheessa jää vielä harkittavaksi, onko tärkeämpää saada sujuvampi käyttökokemus vai web-version julkaisu samasta koodista.  

 Liiketoiminnan näkökulmasta saattaa mielessä olla vielä viides tekijä, joka usein koetaan jopa tärkeimpänä: julkaisuaikataulu. Silloin luultavasti auttaa, jos sama koodi tuottaa kaikki tarvittavat versiot yhdellä kertaa. Julkaisuaikataulu on kuitenkin huono peruste; suuri osa sovelluksista pölyyntyy suunnittelupöydällä kuukausia, ellei vuosia, ja kiire syntyy usein vasta siitä, että aloitetaan liian myöhään.  

Julkaisuaikataulu on huono valintaperuste.

 Lisäksi julkaisun ajankohtaa painottaessa ajattelu keskittyy tyypillisesti vain ensimmäiseen versioon eikä tuotteen koko elinkaareen, kun toteutustavan valinta pitäisi tehdä nimenomaan koko elinkaarta ajatellen. Jos aikataulu on ainoa syy vaihtaa toiseen toteutustapaan, kannattaa vielä vakavasti harkita asiaa toiseen kertaan. 

 Sopivien toteutustapojen valinta ei ole täysin suoraviivaista, sillä jokainen sovellus on uniikki. Monipuolinen kokemus kehittämisestä eri teknologioin auttaa valintaa huomattavasti. Sen vuoksi on suositeltavaa käydä läpi eri vaihtoehtoja sovelluskehittäjän kanssa, jotta löytää omat tarpeet parhaiten täyttävän ratkaisun, jota ei tarvitse myöhemmin katua.