Mobiilisovelluksen suunnittelun ensimmäinen askel on oikean teknologian valinta
Sovellusten suosio jatkaa kasvuaan ja usein mobiili on asiakkaan käyttöympäristön ensisijainen kanava. Mobiilisovellusten parissa viihdytään ja niitä käytetään niin tiedon etsimiseen, töiden tekemiseen, tuotteiden varaamiseen ja maksamiseen kuin yhteydenpitoon läheisiin ihmisiin ja kiinnostaviin yrityksiin. Ei ihme, että myös uusia mobiilisovellusteknologioita putkahtelee esille ja valinnan vaikeus voi olla suuri.
Käytännössä useilla eri toteutustavoilla pääsee vastaaviin lopputuloksiin, joten onko teknologialla oikeasti isoa merkitystä? Lyhyt vastaus: on. Jos valinta on väärä, voivat hallinnointikustannukset nousta pilviin tai pahimmassa tapauksessa asiakaskokemus kärsiä niin paljon, että sovellus jää käyttämättä ja investointi menee hukkaan.
Teknologiavalinta riippuu useista eri tekijöistä, mm. ylläpito- ja kehityskustannuksista, markkinassa saatavilla olevasta osaamisesta ja sovelluksessa tarvittavista erityisominaisuuksista. Perinteinen “nopeus, laatu ja hinta” -kolmio hieman eri kärjillä pätee siis tässäkin. Teknologioiden kirjo millä mobiilisovelluksia voidaan toteuttaa on laaja. Sovellusteknologioita voidaan hahmottaa ja luokitella esimerkiksi sen mukaan, kuinka paljon ne hyödyntävät web-tekniikkaa tai natiivikoodia.
Natiivit sovellukset
Natiivilla mobiilisovelluksella tarkoitetaan sovellusta, joka käyttää mobiilikäyttöjärjestelmien tarjoamia rajapintoja suoraan niiden kanssa yhteensopivilla kielillä, kuten Objective-C ja Swift (iOS) tai Java ja Kotlin (Android). Tällaisella sovelluksella on pääsy kaikkiin käyttöjärjestelmän tarjoamiin palveluihin. Sovelluksen jakelu tapahtuu pääosin Applen ja Googlen sovelluskauppojen kautta. Nykyään sovelluksen toteuttamista puhtaasti natiivitekniikalla on kuitenkin hankala perustella joitakin poikkeustapauksia lukuun ottamatta, koska saatavilla on parempiakin vaihtoehtoja.
- Lue lisää
-
Koska kehitys tapahtuu suoraan käyttöjärjestelmän rajapintoja vasten, sovelluskoodia ei voida jakaa iOS- ja Android-sovellusten kesken. Tämä tarkoittaa yksinkertaistettuna kaksinkertaisia kehitys- ja ylläpitokustannuksia sekä vaatii kehittäjiltä kahden eri teknologian hallitsemista. Toki todellisuudessa tilanne ei ole aina näin yksioikoinen, koska useita suunnitteluratkaisuja voidaan jakaa alustojen välillä, vaikka toteutukset tehtäisiinkin kahdella eri kielellä. Natiivitekniikkaan voidaan tukeutua, kun:
- Kyseessä on sovellus, jonka käyttöliittymä on minimaalinen ja se käyttää jotakin alustakohtaista APIa, jolle ei ole olemassa liityntää kuin suoraan natiivirajapinnan kautta.
- Halutaan käyttää jotakin useampaa alustaa tukevaa sovelluskehystä, mutta sillä ei ole pääsyä johonkin käyttöjärjestelmän tarjoamaan toimintoon, johon natiivilla koodilla olisi pääsy. Tällöin toiminto voidaan toteuttaa natiivilla laajennuksella ja tarjota mahdollinen uusi rajapinta sovellukselle sovellusalustan tarjoamilla mekanismeilla. Näin voidaan tehdä myös muistinkäytön optimoimiseksi. Tällainen ominaisuus voi olla esimerkiksi iOS-laitteilla ilmoituskeskukseen lisättävä minisovellus eli widget (Today app extension), jolla on tiukkoja rajoituksia muistin käytölle. Tai halutaan kytkeytyä esimerkiksi käyttöjärjestelmän geoaita-toimintoihin, mikäli saatavilla olevat sovellusalustan kirjastot eivät tarjoa riittäviä toimintoja.
- Kyseessä on sovellus, jonka käyttöliittymä on minimaalinen ja se käyttää jotakin alustakohtaista APIa, jolle ei ole olemassa liityntää kuin suoraan natiivirajapinnan kautta.
Web-sovellukset
Web-sovellukset on toteutettu web-standardeihin pohjautuvilla teknologioilla, kuten HTML5, CSS, Javascript, Service Workers ja Web Storage. Niitä toteutetaan yleensä sovelluskehyksillä kuten React, Angular ja Vue. Web-sovelluksia ajetaan web-selaimessa ja ne ovat rajoittuneet selaimen tarjoamiin palveluihin (esim. kamera ja sijainti). Pääsyä muihin käyttöjärjestelmän päälle rakennettuihin palveluihin kuten osoitekirjaan ei ole saatavilla. Puuttuville palveluille saattaa silti löytyä joissakin tapauksissa toinen toteutustapa web-standardien kautta.
- Lue lisää
-
Esimerkiksi biometrinen tunnistus (kasvontunnistus, sormenjälki) ei ole web-sovelluksille suoraan mahdollista, mutta ne voivat käyttää Web Authentication -standardia, joka delegoi tunnistautumisen selaimelle julkisen avaimen kryptografian avulla. Selaimet voivat hyödyntää tällöin biometristä tunnistautumista standardissa käytettävien kryptografisten operaatioiden apuna. Varsinainen biometriadata ei siirry tässä tekniikassa verkossa, vaan sen avulla avataan pääsy laitteelle tallennettua yksityistä avainta (private key) käyttäviin kryptografiarajapintoihin. Standardin avulla voidaan toteuttaa sovelluksiin salasanaton kirjautuminen.
Mobiilisovelluksia ajatellen puhtaan web-tekniikan merkittävä puute on ollut iOS-laitteiden puuttuva tuki web push-viesteille, jotka toimisivat samoin kuin natiivien sovellusten push-viestit. Tilanne on muuttumassa, koska Apple on julkistanut iOS web push-tuen tulevan vuonna 2023 (W3C Push API).
PWA-sovellukset ovat mobiilisovelluksen kaltaisia web-sivuja
Jos web-sovellus toteutetaan PWA-tyyppisenä (Progressive Web App), se voidaan asentaa laitteen kotinäkymään ja saada toimimaan mobiilisovelluksen kaltaisesti. Sitä ajetaan kuitenkin samoilla rajoituksilla kuin muitakin selainsovelluksia, joten sillä ei ole pääsyä muihin käyttöjärjestelmän palveluihin kuin mitä selain sille tarjoaa.
- Lue lisää
-
Apple ei ole mahdollistanut PWA-tyyppisten sovellusten jakelua sovelluskauppansa kautta toisin kuin Google. Tämä heikentää toisaalta sovellusten löydettävyyttä ja jakelua, mutta toisaalta ne eivät ole riippuvaisia sovelluskauppojen käyttöehdoista esimerkiksi pakollisten sovelluskatselmointien tai sovellusten sisäisten maksujen provisioiden suhteen. Käyttäjät eivät ole ehkä kuitenkaan vielä tottuneet asentamaan web-sivuilta löytyviä sovelluksia tietoturvauhkien pelossa ja luottavat enemmän sovelluskauppoihin. PWA-sovellusten kannalta tämä on sinänsä ehkä turha pelko, koska niitä ajetaan samoilla rajoitetuilla oikeuksilla kuin muitakin web-sovelluksia.
PWA-sovellusten riippumattomuus sovelluskaupoista mahdollistaa joitakin skenaarioita, jotka eivät ole mahdollisia muiden mobiilisovellustyyppien kanssa. Niitä voidaan generoida ohjelmallisesti, jolloin voidaan toteuttaa esimerkiksi yksilöllisiä yritysten tuotekatalogeja, joita luodaan dynaamisesti tarpeen mukaan ja jaellaan web-sivujen kautta. Silti ne näyttävät ja toimivat kuten tavanomaiset mobiilisovellukset. Toinen esimerkki on vaikkapa valokuvausyritys, joka jakelee kuvat asiakkaalle asiakaskohtaisina mobiilisovelluksina.
Hybridisovellukset
Pelkästään natiivitekniikalla tai pelkästään web-tekniikalla toteutettujen sovelluksien välissä on kategoria teknologioita, joita kutsutaan hybrideiksi. Tässä kategoriassa käyttöliittymää ja sovelluslogiikkaa ajetaan yleensä sovelluksen sisäisessä web-selainkomponentissa, joka on upotettu sovelluskehyksen tarjoamaan natiivitekniikalla toteutettuun sovelluskuoreen. Selaimesta on piilotettu siitä tavanomaisesti löytyvät toiminnot, kuten osoiterivi. Sovelluskuori tarjoaa selaimessa ajettavalle sovellukselle Javascript-rajapintojen kautta joitakin käyttöjärjestelmän tarjoamia palveluita, joita web-sovelluksille ei muuten olisi tarjolla. Hybridisovellusten jakelu tapahtuu natiivisovellusten tapaan sovelluskaupan kautta.
- Lue lisää
-
Esimerkki tällaisesta hybridisovellusalustasta on vuonna 2013 julkaistu Ionic. Ionic tarjoaa UI-komponenttikirjaston, joka jäljittelee Androidin ja iOSin omia käyttöliittymäkomponentteja. Ionicilla toteutetun web-sovelluksen voi paketoida sovelluskuoreen Capacitor tai Cordova-kehysten avulla. Kehitys tapahtuu muiden web-sovellusten tapaan esim. Reactilla, Angularilla tai Vuella. Ionicilla toteutetun sovelluksen voi paketoida myös PWA-tyyppiseksi. Ionicin suosio on kuitenkin laskenut useita vuosia tarjolle tulleiden muiden vaihtoehtojen myötä.
Esimerkkejä suosituimmista teknologioista vuonna 2023
Edellä mainittujen hybriditekniikoiden rinnalle on viime vuosina noussut myös sovellusalustoja, joihin ei voida käyttää aivan samaa jaottelua natiivi- ja hybriditekniikan välillä kuin yllä. Jos tavoitteena on vähentää kustannuksia projektin ja ylläpidon aikana sekä aikaa suunnittelupöydältä tuotantoon suorituskyvystä tinkimättä, valinta kohdistuu tällä hetkellä yleisimmin React Nativeen tai Flutteriin. React Native on Facebookin (nyk. Meta) vuonna 2015 kehittämä ja Flutter on Googlen vuonna 2017 kehittämä sovellusalusta.
Molemmat alustat ovat kypsiä tuotantoon ja toteuttavat saman perusidean: yksi ja sama koodipohja toimii sekä iOS- että Android-laitteissa (cross-platform). Kummallakin alustalla voidaan toteuttaa moderneja mobiilisovelluksia kustannustehokkaammin kuin perinteisellä natiiviteknologialla, joka vaatii oman erillisen koodipohjan sekä iOS- että Android-laitteille.
- Flutter
-
Flutter on tuoreempana nopeasti noussut React Nativen rinnalle suosituimpien mobiilikehitysalustojen joukkoon (Stack Overflow Survey 2022, Stack Overflow Trends). Flutter on monen valinta, koska:
- Se koetaan helposti lähestyttäväksi teknologiaksi, jolla on kattava dokumentaatio. Flutterin erityispiirteenä on se, että se piirtää käyttöliittymäkomponentit itse. Tästä on se etu, että sovellus ei ole riippuvainen alla olevan käyttöjärjestelmän tarjoamista matalan tason käyttöliittymäkomponenteista. Flutter ei käytä web-selainta UI-komponenttien piirtämiseen kuten esim. Ionic, joten UI- ja OS-kerrosten välinen kommunikaatio ei muodostu suorituskyvyn pullonkaulaksi.
- iOS- ja Android käyttöjärjestelmien päivittyessä tarvitaan joskus jonkinlainen migraatio, mikäli käyttöliittymätekniikat muuttuvat eri versioiden mukana. Flutteria käyttämällä voidaan vähentää tätä ylläpitotyötä, koska se ei käytä käyttöjärjestelmän tarjoamia käyttöliittymäkomponentteja.
- Flutterilla toteutettu sovellus näyttää samalta riippumatta alustasta, jolloin brändäys voi olla hieman helpompaa. Tämä Flutterin vahvuus voi olla kuitenkin myös sen herkkä kohta, sillä UI/UX-suunnittelussa on otettava erityisesti huomioon käyttäjien tottuminen tietynlaisiin käyttöliittymäratkaisuihin omalla laitteellaan. Käyttäjät voivat kokea käytettävyyden epäintuitiiviseksi, mikäli käyttöliittymäsuunnittelussa poiketaan näistä alustakohtaisista käytännöistä merkittävästi (Google: Material Design, Apple: Human Interface Guidelines).
- Flutterilla on pääsy alustakohtaisiinkin rajapintoihin, mikäli tarvetta ilmenee. Kattava valmiiden liitännäiskirjastojen kokoelma vähentää kuitenkin tarvetta toteuttaa tällaisia matalan tason kytköksiä alla olevaan käyttöjärjestelmään.
Flutteria koodataan staattisesti tyypitetyllä Dart-ohjelmointikielellä, joka kuuluu samaan ALGOL-kieliperheeseen kuin esim. C, Java, C# ja Javascript. Se on siis nopea oppia näiden kielten tuntijoille. Flutterin muita ominaisuuksia ovat mm. hot reload (sovelluksen ajonaikainen muokkaaminen), add-to-app (Flutterin lisääminen olemassa olevaan natiivimobiilisovellukseen) sekä tuki web- ja desktop-alustoille (Windows, Mac, Linux). Web ja desktop-alustojen tuki tosin on vielä hyvin kevyttä eikä sovellu välttämättä kuin rajattuihin käyttötapauksiin.
- Se koetaan helposti lähestyttäväksi teknologiaksi, jolla on kattava dokumentaatio. Flutterin erityispiirteenä on se, että se piirtää käyttöliittymäkomponentit itse. Tästä on se etu, että sovellus ei ole riippuvainen alla olevan käyttöjärjestelmän tarjoamista matalan tason käyttöliittymäkomponenteista. Flutter ei käytä web-selainta UI-komponenttien piirtämiseen kuten esim. Ionic, joten UI- ja OS-kerrosten välinen kommunikaatio ei muodostu suorituskyvyn pullonkaulaksi.
- React Native
-
React Nativen suosion syyt ovat osin samoja kuin Flutterin, vaikka alustoissa on myös selkeitä eroja.
- React Native on hyvin samankaltainen Web-sovellusten toteutukseen käytettävän Reactin kanssa, joten React-taustainen kehittäjä omaksuu nopeasti React Native -kehittämisen erityispiirteet.
- Toteutukseen käytetään Javascriptiä tai Typescriptiä, joka transpiloidaan Javascriptiksi. React Nativella toteutetussa sovelluksessa ajetaan Javascript-moottoria sovelluksen sisäisessä taustaprosessissa ja UI-komponentit on mäpätty suoraan käyttöjärjestelmäkohtaisiin UI-komponentteihin.
- Käyttöliittymä tuntuu ja näyttää samalta kuin natiivilla koodilla tehdyssä sovelluksessa, koska UI-komponentit ovat samoja. Javascript-moottori kommunikoi natiivialustan kanssa asynkronisesti serialisoidun viestinvälityksen avulla.
- React Native on luonnollinen valinta Javascript-taustaiselle kehittäjälle. Sen etuna on myös pidempi historia ja sitä myötä laajempi kehittäjäyhteisö sekä kolmannen osapuolen komponenttikirjasto.
- React Native on hyvin samankaltainen Web-sovellusten toteutukseen käytettävän Reactin kanssa, joten React-taustainen kehittäjä omaksuu nopeasti React Native -kehittämisen erityispiirteet.
Muutaman tässä mainitun teknologian lisäksi markkinoilla on useita muitakin paljon käytettyjä ratkaisuja. Ei siis ihme, jos valinnan tekeminen voi tuntua haastavalta ja väärän valinnan tekeminen mietityttää. Tiimimme asiantuntijat auttavat asiakkaitamme vastaavien kysymysten kanssa päivittäin, joten ota yhteyttä ja keskustellaan lisää!