Flutter või natiivne? Väikeettevõtte esimene äpp

„Flutter arendaja“ ja „mobiilirakenduste arendus“ on otsingud, mille taga on tavaliselt üks eeldus juba tehtud: et äpp on õige samm. Enne stack’i valimist tasub selle eelduse peale korra tagasi tulla, sest osa ettevõtteid, kes küsivad äpi hinda, vajavad tegelikult ainult paremat mobiiliveebi.

Kas äpp on õige küsimus

Äpp annab kolm asja, mida mobiiliveeb ei anna: koha kasutaja avakuval, push-teavitused ilma e-posti loata ja juurdepääsu seadme funktsioonidele nagu kaamera, GPS taustal või NFC. Kui äri ei vaja ühtegi neist kolmest — kui piisab sellest, et klient avab lehe brauseris, vaatab hinda ja täidab vormi —, on hästi ehitatud responsive veebileht odavam tee samale tulemusele. Äpp tasub end ära siis, kui kasutaja tuleb tagasi korduvalt ja regulaarsus ise on väärtus: lojaalsusprogramm, teenus, mida kasutatakse iga nädal, või seade, mis peab andmeid koguma ka siis, kui äppi parasjagu vaadata ei viitsita.

Natiivne, Flutter või midagi vahepealset

Kui äpp on õige otsus, on järgmine küsimus, mis keeles see ehitada.

Natiivne (Swift iOS-ile, Kotlin Androidile) annab kõige täielikuma juurdepääsu platvormi funktsioonidele ja parima jõudluse serva peal — aga see tähendab kahte eraldi koodibaasi, kahte meeskonda või kahekordset tööd samalt inimeselt, ja kahte kohta, kus bugi võib tekkida.

Flutter annab ühe koodibaasi, mis jookseb iOS-il ja Androidil korraga. Enamiku väikeettevõtte äppide jaoks — need, mis näitavad sisu, võtavad tellimusi vastu, haldavad kontot või kuvavad seadme andmeid — pole vahet, mida kasutaja platvormil parasjagu näeb: liides on peaaegu identne mõlemal. Ühe koodibaasi eelis pole ainult väiksem esialgne töö, vaid ka see, et iga hilisem muudatus tehakse üks kord, mitte kaks.

Meie valik on Flutter enamiku projektide jaoks täpselt sel põhjusel: enamikul äridest, kes küsivad äppi, ei ole ressurssi hooldada kahte eraldi koodibaasi aastate kaupa. Natiivne tuleb kõne alla siis, kui äpp vajab midagi väga platvormispetsiifilist — sügavat integratsiooni operatsioonisüsteemi tasemel funktsiooniga, mida ristplatvormsed raamistikud veel ei kata hästi.

Mis juhtub pärast koodi valmimist

Koodi kirjutamine on pool tööst. Teine pool on see, mida enamik esmakordseid tellijaid alahindab:

• App Store Connect ja Google Play nõuavad mõlemad oma kontosid, arendajatasusid ja läbivaatust — Apple oma on rangem ja võtab tavaliselt kauem.
• Kauplusekirjed — ikoon, ekraanipildid, kirjeldus igas keeles, mida toetad — on omaette töö, mitte automaatne lisand koodile.
• Läbivaatuse tagasilükkamine on tavaline esimesel korral, sageli väikeste asjade pärast: puuduv privaatsuspoliitika link, ebaselge õigustus mõne loa jaoks. Sellega tuleb arvestada ajakavas, mitte pidada seda erandiks.
• Tellimused ja ostud äpis käivad enamasti RevenueCati taolise tööriista kaudu, mis haldab Apple’i ja Google’i erinevaid ostusüsteeme ühest kohast.

	Natiivne (Swift + Kotlin)	Flutter
Koodibaase	Kaks	Üks
Platvormijuurdepääs	Kõige täielikum	Enamiku funktsioonide jaoks piisav
Hilisema muudatuse kulu	Kaks korda tehtav töö	Üks kord tehtav töö
Sobib kõige paremini	Sügavalt platvormispetsiifilised äpid	Enamik äri-, teenuse- ja seadmeäppe

Kui äpp on üks osa suuremast plaanist

Väikeettevõtte esimene äpp on harva üksik projekt — enamasti kaasneb sellega ka veebiväljund (turundussait, kliendiportaal) ja mõnikord ka mõõdikute jälgimine, mida keegi peab hiljem loema. Sel juhul tasub küsida, kas äpp ja veeb jagavad tagaotsa: kas kasutajaandmed, tellimused ja autentimine elavad ühes süsteemis, mida mõlemad küsivad, või ehitatakse iga liides omaette lukuga uksega. Jagatud tagaots ei ole automaatselt õige valik — mõnikord on lihtsam hoida veeb ja äpp lahus —, aga see on otsus, mis tasub teha teadlikult, mitte kogemata, sest see, mis alguses tundub kahe eraldi väikese projektina, kasvab enamasti üheks süsteemiks, mida keegi peab pikas plaanis tervikuna mõistma.

Kui äpp toetab riistvara

Osa äppe pole eraldiseisev toode, vaid liides mingi muu seadme või teenuse jaoks — GPS-jälgija, sensor, eSIM-i haldus. Sel juhul ei alga arendus liidesest, vaid sellest, mis andmeid seade saadab ja kui usaldusväärselt see peab taustal töötama ka siis, kui kasutaja äppi parasjagu ei vaata. Oleme selliseid süsteeme ehitanud enda toodetena — GPS-jälgimissüsteem ja IoT-jälgimistööriist on mõlemad meie oma, mitte kliendi juhtumiuuring, ja mõlema puhul oli suurem osa tööst mitte liides, vaid see, mis toimub seadme ja äpi vahel enne, kui kasutaja midagi näebki. Kes on uudishimulik, milline see reaalselt välja näeb, leiab need meie tehtud tööde ülevaates, sealhulgas GPS-jälgimissüsteemi juhtumi.

Mis juhtub pärast poodi jõudmist

Äpp ei ole valmis, kui see poes on. Apple ja Google muudavad reegleid ja API-sid ise, tavaliselt kord-paar aastas nii, et vana build lakkab töötamast uute seadmete või OS-versioonidega enne, kui keegi on plaaninud selleks aega. See on erinev veebilehe hooldusest, kus servalt renderdatud staatiline sait võib seista muutumatuna aastaid — äpp elab ökosüsteemis, mis liigub tema alt. Kes seda kuue kuu või aasta pärast jälgib ja uuendab, on küsimus, mille vastus tuleb otsustada enne käivitust, mitte pärast esimest tagasilükkamist.

Ühe meie oma toote — eSIM-brändi — puhul on mobiiliäpp kasutaja peamine kokkupuutepunkt tootega, mitte lisand veebilehele: ost, aktiveerimine ja tugi käivad kõik läbi äpi. See on hea näide sellest, miks „äpp kui liides“ ja „äpp kui toode ise“ on kaks erinevat ehitusülesannet — esimesel juhul on äpp abivahend, teisel juhul kannab see kogu ärimudelit ja peab seda tegema usaldusväärselt igal seadmel.

Olemasoleva äpi ülevõtmine

Mitte iga projekt ei alga tühjalt lehelt. Kui sul on juba äpp, mille algne arendaja on kadunud või kelle koodiga keegi enam ei taha tegeleda, on esimene samm audit: mis seal tegelikult on, milline osa töötab, mis on tehniline võlg ja kas ülevõtmine on üldse mõistlik, või on odavam alustada uuesti. See vastus ei ole kunagi „ilmselt“, vaid tuleb koodi ja poekonto reaalsest seisust.

Meie mobiilirakenduste teenuse lehel on kirjas täpsemalt, mis stack’iga töötame ja kuidas poekirjete ja läbivaatuse protsess meie käe all välja näeb. Kui äpi vajadus on veel lahtine küsimus, on lihtsam seda otse läbi rääkida kui üksi otsustada.

Reegel, mida kasutame

Alusta küsimusest „kas kasutaja tuleb tagasi“, mitte küsimusest „mis stack’is“. Kui vastus esimesele on jah, on stack peaaegu alati Flutter, kuni miski konkreetne platvormivajadus ütleb teisiti — ja isegi siis on see erand, mitte reegel.