fbpx
-

Mobiili­sovellusten kehittäminen vuonna 2023: natiivi­sovellukset, Flutter vai React Native?

Miltä näyttää mobiilisovellusten kehittäminen vuonna 2023? Kentässä on tapahtunut lähivuosina paljon, ja jos olet aloittamassa uuden kehittämisen tai nykyisen sovelluksen uudistamisen, kannattaa lukaista tämä katsaus tavoista tehdä Googlen Play-kaupassa ja Applen AppStoressa julkaistavia sovelluksia. Nopeana yhteenvetona voidaan sanoa, ettei ole olemassa mitään selkeästi ylivoimaista tapaa toimia joka tilanteessa.

Päävaihtoehdot sovelluksen tekemiseen ovat natiivisovellus kummallekin alustalle erikseen tai käyttäen työkaluja, jotka mahdollistavat alustariippumattoman sovelluksen kirjoittamisen. On myös muita tapoja tehdä sovellus, mutta tässä kirjoituksessa keskitytään edellä mainittuihin tapoihin, jotka ovat tällä hetkellä eniten pinnalla.

Jos ohjelmistokehittäjiä on ns. reilusti käytettävissä kehitysvaiheessa ja tulevaisuudessa ylläpitoon, voi helposti sanoa, että kannattaa tehdä omat natiivit sovellukset. Usein tämä ei kuitenkaan ole realistista, kehitys- ja ylläpitokustannuksista halutaan säästää. Tähän avuksi tulevat työkalut, jotka mahdollistavat yksinkertaistettuna yhden koodin ajamisen kummallakin alustalla. Tällä hetkellä kaksi suosituinta vaihtoehtoa ovat Googlen tukema Flutter ja Facebookin/Metan React Native.

Kummatkin näistä käyttävät samantapaista komponentti-ajattelutapaa, jonka React toi suosituksi web-sovelluksiin. Näkymät rakennetaan komponenteista (Widget/Component) ja komponentin renderöinti tehdään yhdessä funktiossa (build/render), joka palauttaa halutun näkymän. Vaikka sovelluksen ohjelmistokehittäjälle lähestymistapa näyttää samankaltaiselta, työkalujen arkkitehtuuri ja toteutus poikkeavat toisistaan huomattavasti. Flutterin tapa tehdä on huomattavasti yksinkertaisempi, sillä se ottaa natiivialustasta vain ruudun haltuunsa ja piirtää siihen omat komponenttinsa. React Native puolestaan muodostaa sillan React Native -komponenttien ja natiivikomponenttien välille. Ylläpitoa ajatellen React Nativen lähestymistapa vaatii enemmän, koska alustojen natiivikomponenteissa tapahtuvat päivitykset vaikuttavat React Nativeen. Tosin alustojen natiivikomponentteja toki kehitetään sillä ajatuksella, ettei taaksepäin yhteensopivuutta rikota herkästi, joten tämä voi olla enemmänkin teoreettinen huoli.

React Native -sovellukset kirjoitetaan JavaScriptillä tai TypeScriptillä, jotka molemmat ovat tuttuja ohjelmointikieliä etenkin web-sovelluskehittäjille. Flutter-sovellukset puolestaan kirjoitetaan Dart-ohjelmointikielellä, joka on huomattavasti tuntemattomampi. Tämä hiukan puoltaa valintaa React Native puolelle, mutta Dart ei ole vaikea kieli. Jos sovelluskehittäjällä on kokemusta vahvasti tyypitetyistä kielistä (esim. Java/C#/Swift), hän pystyy tekemään Dart:lla tuottavaa työtä muutamassa päivässä.

Nykypäivänä suuri osa ohjelmistokehityksestä on erilaisten (kolmansien osapuolten) ohjelmistokirjastojen hyödyntämistä. React Native hyödyntää web-maailman käyttämää npm-palvelua, josta löytynee lähes kaikki mahdolliset kuviteltavat kirjastot. Flutter käyttää puolestaan omaa pub.dev palvelua, jossa on paljon kirjastoja, mutta ei lähellekään samoja määriä kuin npm:ssä. Tämä onkin ehkä yksi ratkaisevimpia asioita: jos mobiilisovelluksen paljon kehitystyötä vaativa toiminnallisuus löytyy valmiina kirjastona npm:stä, voi olla järkevää valita React Native. Tietenkään se, että jokin kirjasto löytyy toiminnallisuuden tekemiseen, ei automaattisesti tarkoita, että sitä voidaan lopulta hyödyntää, vaikka päällisin puolin siltä näyttääkin.

Ennen Flutteria ja React Nativea oli myös työkaluja, jotka teoriassa mahdollistivat mobiilisovelluksen kehittämisen yhdestä koodikannasta kahteen alustaan. Yleensä nämä perustuivat yksinkertaistettuna siihen, että ne käärivät web-sivun mobiiliapplikaation pakettiin. Suurin ongelma näissä oli suorituskyky, käyttäjäkokemus oli tökkivää ja johti nopeasti yhden tähden arvosteluihin sovelluskaupoissa. Flutterin ja React Nativen kanssa tilanne on muuttunut huomattavasti paremmaksi (myös mobiililaitteiden suorituskyvyn parantuminen auttaa). Arkkitehtuurinen ero antaa pienen suorituskykyeron Flutterille, mutta sillä tuskin on merkitystä nykypäivänä. Kummallakin voi tehdä vähintäänkin riittävällä suorituskyvyllä toimivia sovelluksia, eikä nykyään voi suoraan sovellusta käyttämällä päätellä, millä teknologialla sovellus on tehty.

Käyttökokemus on ollut jo pitkään tärkeä osa ohjelmistoprojekteja, mutta nykyään myös kehittäjäkokemus on tärkeä osa ohjelmistoprojektia. Työkalujen toimivuudella on paljon merkitystä ohjelmistokehittäjän tuottavuuteen ja tyytyväisyyteen. Tässä Flutter vetää selvästi pidemmän korren. Googlen tukemana Flutter toki toimii oletetun nätisti Android-ekosysteemissä, mutta Flutter toimi todella mutkattomasti myös iOS-ympäristössä. Kokenutkin ohjelmistokehittäjä turhautuu, kun React Nativen kanssa ensikokeilu alkaa mystisillä virheilmoituksilla ja vaatii erinäköisiä säätöjä, jotka edellyttävät vahvaa Android- ja iOS-kehitysalustojen tuntemista.

Kuten muutenkaan ohjelmistokehityksessä, tässäkään ei ole hopealuotia. Varsinkin uutta sovellusta kehitettäessä kannattaa Flutteria ja React Nativea harkita vakavasti. Kummassakin onnistuu myös kirjoittaa osa sovelluksesta kuin alustojen natiivisovellukset, joten sekään ei rajoita valintaa. Se, valitseeko Flutterin vai React Nativen, onkin vielä vaikeampi kysymys. Pelkästään business-näkökulmasta tätä valintaa on erittäin vaikea perustella suuntaan tai toiseen. Kummankin työkalun takana on iso yritys, joka tuskin lopettaa työkalun kehittämistä kovin helposti. Loppujen lopuksi tämäkin on vain yksi tiimin tehtäviin kuuluva teknologiavalinta muiden joukossa, vaikka tämä onkin valinta, jota tuskin vaihdetaan ikinä projektin aikana.

Kirjoittaja on sovelluskehittäjä, jolla on enemmän kokemusta vahvasti tyypitetyistä ohjelmointikielistä kuin Reactista. Hänellä on kokemusta monenlaisesta mobiilisovellusten kehittämisestä ja kehitysympäristöistä. Hänet Flutter yllätti positiivisesti sekä toimivuuden että työkalun kypsyyden suhteen kun taas React Nativen käyttöönotto oli se tavallinen tarina säätämiseen.