Sotkuinen tai epäselvä käyttöliittymä? Ei kiitos. Löydät etsimäsi tiedon, mutta sen etsimiseen meni kolme kertaa odotettua aikaa kauemmin? Ei kiitos. Tämän päivän mobiilisovellusten odotetaan olevan helppokäyttöisiä, nopeita ja luotettavia – ja tarjoavan sitä mitä lupaavat. Jos sovelluksesi ei täytä näitä odotuksia, saatat hyvin todennäköisesti jäädä kilpailijoidesi jalkoihin. Laadukkaiden sovellusten kehittäminen ei kuitenkaan tapahdu käden käänteessä eikä useimmiten myöskään pienin kustannuksin. Mikä siis avuksi? Yksi vaihtoehdoistasi on hyödyntää työkalua, joilla voit kehittää sovelluksen nopeasti toimimaan sekä Android- että iOS-laitteilla, parhaimmillaan myös verkossa. Tällaisia ovat esimerkiksi tässä blogissa kuvaillut React Native ja Flutter. Suoraan suomennettuna ne ovat alustariippumattomia mobiilikehyksiä, joista yleisimmin käytetään niiden englanninkielistä nimitystä cross-platform mobile framework.
Mobiilisovelluksen kehityksestä puhuttaessa alustariippumattomuus tarkoittaa sitä, että sovellus voidaan kehittää Androidille, iOS:lle ja usein myös verkkoon käyttäen samaa koodipohjaa. Tämä taas tarkoittaa, että parhaimmillaan niin suunnittelu, kehitys kuin testauskin vievät vähemmän aikaa ja rahaa kuin kehitettäessä puhtaasti natiivia sovellusta. Natiivisovellus kas kehitetään toimimaan yhdellä alustalla alustan omaa kehitysympäristöä ja ohjelmointikieltä käyttäen, jolloin esimerkiksi Android- sekä iOS-laitteille suunniteltu sovellus pitäisi koodata ensin Androidille sitten iOS:ille. Se, onko yhden koodipohjan taktiikka sinun sovelluksellesi sopivin vaihtoehto, on oma kysymyksensä, mutta tämän kirjoituksen puitteissa sovitaan, että olet niin jo päättänyt. Seuraava kysymyksesi todennäköisesti on, että mikä cross-platform framework – tässä kehys – on paras. Lähdetään tutustumaan yhdessä kahteen tunnetuimpaan kehykseen, jotta saat kysymyksellesi vastinetta.
Kaksi käytetyintä mobiilikehystä
React Native ja Flutter ovat kaksi maailmalla eniten käytettyä mobiilikehystä, joiden avulla voidaan rakentaa mobiilisovelluksia useammalle eri alustalle. Molemmat ovat avoimen lähdekoodin kehyksiä, tukevat yhtä koodipohjaa Androidille ja iOS:lle, sekä sisältävät hot reload -ominaisuuden, joka yksinään jo nopeuttaa niin kehitystä kuin testaustakin.
Mikä on React Native?
Facebookin vuonna 2015 julkaisema React Native on avoimen lähdekoodin mobiilikehys, joka käyttää kunkin alustan natiivikomponentteja antaen sovelluksille niiden alustalle parhaiten istuvan ulkomuodon. Konepellin alla React Native käyttää JavaScriptiä ja JSX:ää (jälkimmäinen mahdollistaa HTML:n kirjoittamisen Reactilla), mikä tarkoittaa, että JavaScriptia osaavat kehittäjät oppivat sen yleensä melko nopeasti. React Nativelta löytyy myös suuri kehittäjäyhteisö ja sen avulla on kehitetty sovelluksia, kuten Discord, Instagram ja Pinterest.
Mikä on Flutter?
Googlen vuonna 2017 julkaisema Flutter on avoimen lähdekoodin mobiilikehys, joka käyttää Googlen omaa Dart-nimistä olio-ohjelmointikieltä. Sen kehittäjäyhteisö on kasvanut nopeasti, ja StackOverflow:n vuoden 2023 verkkokyselyssä se ohitti React Nativen suosituimpien teknologioiden kategoriassa Muut kehykset ja kirjastot. Flutterilla on kehitetty sovelluksia, kuten Google Pay, Etsy ja Phillips Hue.
Kuinka vaikeita React Native ja Flutter ovat oppia?
Tällä hetkellä Googlen Dart-ohjelmointikielellä ei ole muita suosittuja käyttötapauksia kuin Flutter. Siksi kehittäjän, jolla ei ole aiempaa kokemusta Dartista, täytyy Flutter-projektissa opetella täysin uusi kieli. Idention konsulttien kokemusten mukaan Dart-kielen oppimiskäyrä ei kuitenkaan ole niin jyrkkä kuin miltä se voi vaikuttaa. Huomattakoon, että Dartin syntaksi on samankaltainen kuin JavaScriptin, joten kehittäjä, joka osaa JavaScriptiä, ymmärtää luultavasti myös Dartsia hyvin pitkälle. Google on lisäksi pistänyt ekstrapaukkuja uuden projektin aloittamiseen sekä Flutterin dokumentaatioon tehdäkseen ensimmäisestä ripeän ja jälkimmäisestä sekä kattavan että helposti ymmärrettävän.
”Meillä oli Identiolla viikonlopun mittainen työpaja, jossa opettelimme Flutteria. Meitä oli kymmenen henkilöä, joilla ei ollut aiempaa kokemusta kyseisestä teknologiasta. Kaikilla oli tapahtuman päätteeksi toimiva sovellus.”
– Julius Rajala, Software Engineer
Vertailun vuoksi voidaan todeta, että kehittäjä, jolla on kokemusta ReactJS:stä, oppii React Nativen melko nopeasti. Todennäköisesti sinullakin on kehitystiimissäsi ohjelmistokehittäjiä, jotka ovat käyttäneet ReactJS:ää tai ainakin JavaScriptiä. React Nativen dokumentaatio kuitenkin kalpenee Flutteriin verrattuna sekä rakenteeltaan että sisällöltään. Dokumentaation osalta piste siis menee ehdottomasti Flutterille. Kokonaisuutena annan silti pisteet React Nativelle, sillä sen opettelu on kuitenkin selvästi helpompaa.
Onko sovelluksen käyttöliittymän rakentamisessa eroja?
React Native sisältää noin 25 käyttöliittymäkomponenttia. Kaikki ominaisuudet, joita ei voi rakentaa niiden avulla, on toteutettava joko käyttämällä kolmannen osapuolen kirjastoja tai kirjoittamalla ne alusta alkaen itse. Kolmannen osapuolen kirjastojen käyttö voi johtaa ongelmiin yhteensopivuuden kanssa, ja toisaalta ominaisuuksien luominen alusta alkaen on kallista. React Nativea pidetään kuitenkin vakaana kolmannen osapuolen komponenttien käyttämiseen esimerkiksi maksujen käsittelyyn tai geopaikannukseen ja tarjolla onkin laaja valikoima aktiivisesti ylläpidettyjä kirjastoja vastaaviin ominaisuuksiin. React Nativen etu piilee käyttöliittymän kannalta siinä, että se hyödyntää natiivikomponentteja. Natiivikomponentit on rakennettu juuri tiettyjä alustoja ja laitteita varten. Yksi esimerkki natiivikomponentista on jokaiselle tuttu kamerasovellus, joka näyttää erilaiselta ja käyttäytyy eri tavalla jokaisella alustalla.
Flutter taas pitää sisällään vielä kattavamman UI-komponenttikirjaston, sillä se on integroitu Googlen Material Designiin. Jos käyttöliittymä voidaan rakentaa tätä kirjastoa käyttämällä, yhteensopivuusongelmien kanssa ei tarvitse juurikaan taistella. Jos taas tarvetta on sellaiselle, mitä Material Design ei tarjoa, eivät vaihtoehdot kolmannen osapuolen kirjastojen suhteen ole yhtä laajat kuin React Nativella. Etuna tässä on silti se, että Material Design -kirjasto on hyvin suunniteltu ja vastaa useimpien modernien sovellusten tarpeisiin. Sovelluksen voi jopa suunnitella FlutterFlow’n avulla (lue erillinen blogitekstimme aiheesta), mikä tarkoittaa, että suunnittelussa käytetään näitä Flutterin sisäänrakennettuja UI-komponentteja. Se tekee toteutuksesta jo melko suoraviivaista.
Kumman suorituskyky on parempi?
Flutter ottaa suorituskyvyssä johdon, sillä Dartin tehokas käännösprosessi on suorituskyvyltään hieman parempi. Vaikutus käyttäjälle ei kuitenkaan ole niin merkittävä, että Flutterin käyttöä kannattaisi harkita vain tästä syystä. Mutta se on hyvä pitää mielessä.
Kumpi on helpompi ylläpitää?
Ylläpidon suhteen voitaisiin sanoa, että vallan mukana tulee vastuu, mutta tässä tapauksessa sanotaan, että kolmannen osapuolen kirjastojen myötä tulee päänsärky. No, vitsit sikseen. Kolmannen osapuolen kirjastojen käyttäminen tarkoittaa, että sinun on luotettava siihen, että näitä kirjastoja ylläpidetään aktiivisesti esimerkiksi tietoturva- ja yhteensopivuusongelmien välttämiseksi. Sinun on huomioitava myös kirjastojen viimeisimmät päivitykset ja se, pitävätkö nämä päivitykset kyseisen kirjaston yhteensopivana sovelluksesi kanssa. Tämä koskee sekä Flutteria että React Nativea. Itse React Nativen päivittäminen voi myös olla mielenkiintoinen kokemus, ja siitä vastaavalla kehittäjällä kannattaa olla lehmän hermot. Jotain hajoaa lähes aina, eikä vastaan tulleiden haasteiden korjaaminen ole yleensä nopeaa. Jos jätetäänkin huomiotta kolmannen osapuolen kirjastojen käyttö, React Native menettää pisteen ylläpidon suhteen.
Entä virheet ja sovelluspäivitykset?
Oletetaan, että sovelluksesi on saatavilla yleisimmissä jakelukanavissa eli sovelluskaupoissa kuten Google Play ja App Store. Silloin sovelluspäivitysten toimittaminen on melko samanlaista sekä Flutterissa että React Nativessa. Jos eroja huomaa, ne tulevat vastaan todennäköisimmin virheitä korjatessa tai testauksen yhteydessä, joten ne eivät näy niinkään käyttäjille vaan kehittäjille. Flutteriin sisälle on integroitu testausominaisuuksia, kun taas React Nativella ei ole erikseen virallista testauskehystä, vaan siinä käytetään Jestin kaltaisia testauskehyksiä.
Muita huomioitavia asioita React Nativen ja Flutterin välillä?
Tässä vaiheessa on syytä mainita, että emme koskaan tiedä, kuinka kauan nämä kehykset tulevat säilymään. Vain tästä näkökulmasta katsottuna natiivisovellusten kehittäminen voi olla ”turvallisempi” vaihtoehto. Tämä ei kuitenkaan tarkoita, että cross-platform olisi millään lailla huono valinta. React Native on ollut olemassa jo lähes vuosikymmenen ajan ja joitakin maailman suosituimmista sovelluksista on kehitetty sen avulla. Flutterin takana taas on Google. Googlella ei ehkä ole paras mahdollinen maine teknologioidensa pitkäaikaisessa tukemisessa, mutta Flutterin tulevaisuus on kuitenkin näyttänyt erittäin lupaavalta.
Kumpi sopii paremmin tarpeisiini?
Riippuu täysin siitä, mitä olet tekemässä. Mikä on budjettisi ja aikataulusi? Onko sinulla jo valmis suunnitelma? Kuka tai ketkä työskentelevät sovelluksen parissa? Riippuen sovelluksesi toiminnallisuuksista, erot sen kehittämisessä React Nativella tai Flutterilla voivat olla joko merkittäviä tai merkityksettömiä. Voin luvata, että saat toimivan sovelluksen kummallakin, mutta tie siihen voi olla erilainen. Päätös on tehtävä aina tilannekohtaisesti. Jos päätöksenteko on vaikeaa, voit aina kysyä asiaa taholta, jolta löytyy aiheesta enemmän kokemusta.
Kirjoittajan huomiot
Koska monille teistä React Native saattaa olla se tutuin mobiilikehys, halusimme kollegojeni kanssa muistuttaa, että on olemassa toinenkin loistava vaihtoehto – Flutter. Olen itse käyttänyt React Nativea enemmän ja sen puutteista huolimatta nautin edelleen sen parissa työskentelystä. Samalla näen ehdottomasti Flutterin tarjoamat mahdollisuudet ja pidän sitä yhtä varteenotettavana vaihtoehtona mobiilikehitysmaailmassa. Pidäthän Flutterin siis mielessä oman sovellusprojektisi kohdalla, sillä tutuin ei ole aina paras – tärkeintä on se, minkälaista sovellusta kehität ja minkälainen kehitystiimi teiltä löytyy.
