Native või cross-platform – millist lähenemist mobiilirakendustel (äppidel) valida?

09 Mar 2020

Sirje Laube

Mobiiliäppide planeerimine pole lihtne ülesanne – see nõuab palju eeltööd ja otsuste tegemist.

Üks sellistest tähtsatest otsustest on platvormi valik ning millist lähenemist arendamisel kasutada – native (platvormipõhine) või cross-platform (platvormist sõltumatu). Nagu paljude planeerimisel esile kerkivate küsimuste puhul, pole ka siin ühest vastus. Et aga otsustamist natuke lihtsamaks teha, oleme teinud väikese võrdluse mõlema lähenemistee headest ja halbadest külgedest.

Mis on native? Mis on cross-platform?

Enne kui liigun võrdluse juurde, seletaksin lahti mõisted native ja cross-platform. Enamus nutiseadmeid kasutavad ühte kahest platvormist – Android või iOS. 2020. aasta veebruari seisuga jagunes nende platvormide turuosa Eestis vastavalt Android OS 67,68% ja iOS 31,7%. Lisaks kasutatakse nutiseadmetes ka muid platvorme, kuid nende turuosa moodustab kokku vaid 0.62%. Seetõttu kirjutatakse ka enamus äppe vaid Androidile või iOS’ile.

Erinevusi nende platvormide vahel on mitmeid – kuid peamisteks võib tuua platvormide arhitektuurierinevused ning programmeerimiskeeled, milles neile platvormidele äppe kirjutatakse - Java või Kotlin Android platvormile ning Objective-C või Swift iOSile.

Native ja cross-platform lähenemise erinevus tulebki programmeerimiskeelte erinevustest. Native arendamine tähendab, et Androidile kirjutatavat koodi ei saa kasutada iOSi äpi tegemiseks ja vastupidi. Seega, kui soovitakse katta nii Androidi kui ka iOSi turgu, on vaja kahte eraldiseisvat äppi.

Cross-platform äppide arendamisel kasutatakse aga ühte programmeerimiskeelt (nt Javascript) ning see koodibaas sillastatakse erinevatele platvormidele. Seega, põhimõtteliselt kirjutatakse kood ühe äpi jaoks. Järgnevalt toon välja peamised native ja cross-platformi vahelised erinevused.

Native ja cross-platform äppide võrdlus

Jõudlus

Native (N): need äpid suudavad efektiivsemalt ära kasutada kõiki platvormi ja riistvara poolt pakutavaid võimalusi ning seadme ressursse (nagu mälu, aku ja protsessor).

Cross-platform (CP): nendel äppidel on piiratud juurdepääs seadme võimalustele (nii tark- kui ka riistvaralisetele komponentidele) ning üks-suurus-sobib-kõigile-lähenemine tähendab, et sellised äpid on tihtipeale aeglasemad ja käituvad ettearvamatumalt.

Võtja – Native

Arenduskulu

N: selliste äppide arendamiseks kulub enamasti rohkem ajalist ja finantsilist ressurssi. Et olla kättesaadav mõlema platvormi jaoks, on vaja arendada kahte eraldiseisvat äppi – ühte Androidi ja teist iOSi jaoks.

CP: kuna eri platvormidele arendamiseks kasutatakse sama koodibaasi, siis on CP arendus tihtipeale poole odavam ja võtab enamasti ka poole vähem aega.

Samas kui tegemist on keerulisemat funktsionaalsust sisaldava äpiga, siis võib CP võimalike bugide hulk olla märkimisväärselt suurem. Samuti võib nende tuvastamise ja parandamise peale minna oluliselt rohkem aega, kui native äpi puhul. Ehk – CP puhul saab äpid kiiresti mõlemas ökosüsteemis tööle, kuid pikas perspektiivis võivad kulud olla sarnased.

Võitja – Viik

Kasutajakogemus

N: nende äppide arendamiseks kasutatakse platvormispetsiifilisi arenduskeskkondi (integrated development enviroment ehk IDE), mis võimaldavad lihtsustatud disaini ja arendusprotsessi ning platvormispetsiifiliste kõrgete kasutajakogemusstandarditele vastavate äppide tootmist.

CP: ühine kood tähendab ka ühtset disaini. Androidil ja iOSil on aga erinevad disaini eeskirjad ja standardid, mida CP äppidel on raske järgida. Seega native äppe kasutav inimesele võib tunduda võõrastav, kui ta hakkab kasutama CP äppi.

Võitja – Native

Kasutajaskonna suurus

N: kui arendada vaid ühele platvormile (näiteks seab piirid eelarve ja/või aeg), siis kaotad suure osa potentsiaalseid kasutajaid.

CP: üks porditav koodibaas tähendab seda, et oled korraga kättesaadav kõikidele võimalikele kasutajatele, kes kasutavad erinevate operatsioonisüsteemidega platvorme.

Võitja – Cross-platform

OS uuenduste integratsioon

N: native keeled ja tööriistad toetavad OS’i uuendusi nende väljalaskepäevast alates.

CP: OS uuenduste väljalaskel ja nende integreerimisel CP arendustööriistadesse tekib paratamatult viivitus.

Võitja – Native

Äpi enda uuenduste integratsioon

N: kui omada iOSi ja Androidi jaoks eraldiseisvaid äppe, siis see tähendab, et disaini- või funktsionaalsusuuenduste sisseviimine võtab rohkem ressursse ning igapäevane haldamine on tülikam.

CP: üks koodibaas tähendab seda, et äpi igapäevane haldamine on lihtsam ning erinevate platvormide kasutajad saavad uuendatud äppi kasutada kiiremini/samal ajal.

Võitja – Cross-platform

Mida arvestada native vs cross-platform otsuse tegemisel?

Nagu näha, mõlemal valikul on omad plussid ja miinused. Siin kohal ongi vaja analüüsida faktoreid, mis peaksid otsustamise lihtsamaks tegema.

Millist tüüpi äppi plaanid teha?

Firmasiseseks kasutamiseks (business-to-employee ehk B2E) – näiteks tööriistad või sisesuhtlusäpid. Sellistest äppidest eeldatakse pikka eluiga ning need võivad olla üsna keerulised. Samas ei pea need olema võimelised kasutama kõige uuemaid OS’i funktsionaalsuseid. Ka võib firma otsustada, et kasutatakse vaid ühe platvormi seadmeid.
Igapäevaseks kasutamiseks klientidele (business-to-customer ehk B2C) – näiteks e-poe äpp. Sellised äpid peaks olema pika elueaga, võimalikult hea jõudluse ja kasutuskogemusega ning ilmselt suunatud kõikidele juhtivatele platvormidele turul (hetkel nii Android kui iOS).
Turundusäpid kasutamiseks klientidele (B2C) – näiteks kampaania või ürituse jaoks loodud äpid. Need äpid on ilmselt äpipoodides üsna lühiajaliselt või periooditi, üsna lihtsad, kuid samas silmapaistvad.
Igapäevaseks kasutamiseks äripartneritele (business-to-business ehk B2B) – üsna sarnane B2E tüüpi äpile (nii keerukuse kui ka eluea mõttes), erinevus seisneb selles, et firmal pole kontrolli äripartneri seadmestrateegia üle ja toetama peaks erinevaid platvorme.

Mõned suunajuhised

Kui plaanid ehitada kompleksset äppi, mis sõltub suures osas native tööriistadest ja võimalustest või kasutab uusimaid tehnoloogiaid (näiteks liitreaalsus ehk augmented reality ja masinõpe ehk machine learning), siis on parimaks valikuks ilmselt native lähenemine.

Erinevad integratsioonivõimalused (nagu Dropbox ja Stripe) on cross-platformil nõrgemini toetatud või puuduvad üldse, mis omakorda tähendab, et vastav liidestus tuleb arendajatel ise kirjutada või tuleb sõltuda mõnest vähetoetatud vabavaralisest jupist.

Kui plaanid B2C äppi, millelt oodatakse pikka eluiga ja head jõudlust, siis võiksid selle ehitamiseks kasutada native lähenemist.

Kui sa oled teinud piisavalt eeltööd veendumaks, et su äpp on lihtsama äriloogikaga ning tähtsateks piiranguteks on ka ajaline ja/või finantsiline ressurss, siis kaalu cross-platform lähenemist.

Kokkuvõte

Küsimusel „Kas minna native või cross-platform teed?“ pole ühest vastust. Kindlasti tasub hoolikalt läbi mõelda, millist äppi luua soovid. Kui keerukas ja kui pika elueaga see peaks olema? Milline on oodatav kasutajaskond? Millised on ressursid? Põhjalik eeltöö ja spetsialistidega arutelu aitab leida just sinu vajadustele parima lahenduse.