Katsaus mobiilikehityksen eri toteutusmalleihin

Vincitin Juha Riipin tuore katsaus mobiilikehityksessä käytettäviin ohjelmistokehyksiin (engl. software development frameworks) on suositeltavaa luettavaa etenkin asiakkaille, jotka ovat ostamassa mobiilisovelluskehitystä tai kehittämässä jo olemassa olevaa sovellusta.

>> Overview of Mobile Development Frameworks in 2019 – Juha Riippi, 4.3.2019*

Juttu tiivistää hyvin viime vuosien kehitystä mobiilisovellusten ohjelmistokehyksien saralla ja listaa keskeisiä syitä siihen miksi erilaisia toteutusmalleja hyödynnetään eri tilanteissa. Katsaus ei ole erityisesti kirjoitettu asiakkaiden näkökulmasta, vaan enemmän ohjelmistokehityksen tehokkuuden ja helppouden näkökulmasta, mutta sisältää hyvää asiaa myös asiakkaiden näkökulmista katsoen.

Jutun lopussa esimerkiksi nostetaan webbisovellukset (ja täsmällisemmin Googlen ajama Progressive Web Apps -malli) keskeisimmäksi mobiilisovelluskehityksen haastajaksi, mikä onkin helppo allekirjoittaa. Mobiilisovellusten käyttäjien näkökulmasta on varsin yhdentekevää, että onko kyseessä ”aito” mobiilisovellus vai mobiilisovelluksena esiintyvä webbisovellus, jos sovellus pystyy vastaamaan asiakkaan odotuksiin. Kännykässä hyvin toimivan sivuston, mobiilisovelluksen tai mobiilisovelluksen kaltaisen “kirjanmerkin” tekninen toteutusmalli on yhä enemmän tekninen valinta, jonka erityispiirteet eivät näy sovelluksen käyttäjälle kovin helposti.

Webbiappien tulevaisuus on kuitenkin edelleen hieman sumuinen, koska etenkin Apple on ollut kovin hidasliikkeinen näiden tuen laajentamisessa. Esimerkiksi notifikaatioiden tukea on tuskin tulossa lähiaikoina, mutta nykyisin sentään jo esimerkiksi jakaminen some-kanaviin onnistuu PWA-sovelluksissa. Vielä viime vuonna tämän puute oli merkittävä kummallisuus etenkin mediatalojen webbiappseissa.

Suomessakin on jo PWA-toteutuksia nähty, esimerkiksi Evermaden tuore julkaisu My M Room on PWA-mallin mukainen web-sovellus.

Myös ohjelmistokehyksien hype on osittain laantunut, koska moni isompi toimija on vaihtanut kehyksen päälle tehdyt mobiilisovellukset aitoihin käyttöjärjestelmäkohtaisiin sovelluksiin. Jutussa linkattu AirBnB:n tarina ei ehkä ole se tyypillisin, mutta havainnollistaa kehysten mukana tulevia kompromisseja ja haasteita. Onkin luontevaa, että ne tahot, joille mobiilisovellukset muodostavat keskeisen osan liiketoimintaa, eivät halua tehdä kompromisseja.

Ohjelmointityötä tehostavat ohjelmistokehykset ovat enemmänkin niille joiden mobiilisovellus on enemmänkin asiakkaille tarjottavaa lisäpalvelua, tai joilla on syystä tai toisesta rajalliset kehitysresurssit.

Ohjelmistokehyksien välisessä taistossa on myös viime aikoina tapahtunut pölyn laskeutumista. React Native tuntuu tällä hetkellä olevan kukkulan kuningas silloin kun halutaan tehdä mobiilisovellus, mutta ei olla valmiita miljoonaluokan investointiin. React Native tarjoaa tehokkaan, yhden koodaamisen reitin kahteen sovellukseen, toinen Androidille, toinen iOS:lle.

Tällaisia tilanteita on kuitenkin vielä kohtuullisen paljon, joissa oikeasta mobiilisovelluksesta olisi asiakkaille todellista hyötyä verrattuna (hyvinkin tehtyyn) webbisovellukseen. Esimerkiksi erilaiset tilaus- ja lippusovellukset voivat tarjota merkittävästi paremman käyttökokemuksen asiakkaille, jotka käyttävät sovellusta viikottain, tai useammin. React Native tarjoaa tällaiseen tilanteeseen kustannustehokkaan toteutusmallin, etenkin verrattuna siihen että koodattaisiin erilliset sovellukset Androidille ja iOS:lle.

Jutussa käydään läpi React Nativen kanssa kilpailevia ohjelmistokehyksiäkin, esimerkiksi Googlen uusi Flutter, mutta jää varsin epäselväksi miksi nämä mallit olisivat esimerkiksi tyypillisiin bisnessovelluksiin käytännössä järkevämpiä toteutusmalleja kuin esimerkiksi React Native, etenkään mobiilisovelluksen omistavan tahon näkökulmasta. Uudella teknologialla on toki aina uutuusarvoa, mutta jos uusi teknologia ei tarjoa merkittäviä konkreettisia etuja, vaan ainoastaan ”modernimman ohjelmointikielen”, niin tämä perustelu tuskin kelpaa mobiilisovelluksen kehityksen maksavalle taholle.

Asiakkaiden näkökulmasta katsoen juttu nostaa esiin ansiokkaasti myös riskejä ohjelmointikehyksien käytölle. Kuten vaikkapa AirBbB:n tarina havainnollistaa, niin vaikka hyödyt alkuvaiheessa olisivat merkittäviäkin, niin elinkaaren näkökulmasta ohjelmistokehykseen nojaaminen on yleensä aina riskialttiimpaa kuin natiivien erillissovellusten toteutus. Facebookin ydinliiketoimintaa ei ole React Nativen kehitys, ja sama riski pätee Googlen Flutteriin.

Uskoako webbisovelluksiin?

Asiakkaiden kannalta isoin päätös tuntuukin tällä hetkellä olevan siinä, että lähteekö toteuttamaan oikeita mobiilisovelluksia ja jakelemaan näitä sovelluskauppojen kautta käyttäjille, vai uskooko webbiappien tulevaisuuteen, ja investoi laadukkaaseen webbisovellukseen joka saadaan käyttäytymään kuten aito appi, tietyin rajoituksin.

Tämä harkinta kannattaa tehdä tarkkaan, vaikka oikean, ladattavan mobiilisovelluksen tekemiselle olisikin vahvat syyt.

On vaikea kuvitella, että esimerkiksi kymmenen vuoden päästä netin sovellusjakelu perustuisi enää App Storen ja Google Playn kaltaisiin suljettuihin sovelluskauppoihin. Onhan tietokoneidenkin maailmassa siirrytty tasaisesti pois asennettavista ohjelmistoista täysin palveluna tarjottaviin web-sovelluksiin (kaikkein raskaimpia sovelluksia ja työkaluja lukuunottamatta).

Lue lisää: Web-sovellukset – kaikki artikkelit Vierityspalkissa

—

PS. Jos kaipaat riippumatonta asiantuntijan näkemystä mobiilipalvelun jatkokehitykseen, uudistukseen tai teknologian vaihtamiseen, kannattaa tutustua North Patrolin konsultointipalveluihin. North Patrol tuntee web- ja mobiilikehityksen teknologiat ja auttaa lukuisia asiakkaitaan uudistuksissa ja erilaisten digipalveluiden jatkokehityksen suunnittelussa.