Mobilo aplikāciju izstrāde 2026 – React Native, Expo un iOS/Android ceļvedis.

Mobilo aplikāciju izstrāde 2026. gadā - ko tiešām izvēlēties un kāpēc lielākā daļa projektu iesākas nepareizi

Latvijas uzņēmēji arvien biežāk nāk pie mums ar vienu un to pašu jautājumu - vai man vajag aplikāciju. Parasti aiz tā slēpjas vēl viens jautājums, ko viņi neuzdod skaļi: cik tas maksās un vai tas vispār atmaksāsies. Tas ir labs jautājums, un uz to nav vienas atbildes, taču ir virkne lietu, ko vērts saprast pirms kāds sāk ģenerēt piedāvājumus.

Mobilo aplikāciju izstrāde ir mainījusies ļoti būtiski pēdējo trīs gadu laikā. Tas, ko 2018. gadā varēja izdarīt tikai ar lielu budžetu un divām atsevišķām komandām iOS un Android platformām, šodien ir sasniedzams ar daudz efektīvākiem instrumentiem. Bet "efektīvāks" nenozīmē "vienkāršāks" vai "lētāks automātiski", un te sākas lielākā daļa pārpratumu.

Trīs ceļi uz lietotāja viedtālruni

Pirmais ir native izstrāde - atsevišķi kodi iOS (Swift vai Objective-C) un Android (Kotlin vai Java). Tas dod vislabāko veiktspēju un pilnu piekļuvi ierīces funkcijām, bet reāli nozīmē divas paralēlas izstrādes komandas un attiecīgi divkāršotu budžetu. Lielākā daļa Latvijas uzņēmumu šo ceļu pašlaik neiziet, ja vien aplikācija nav biznesa pamatprodukts.

Otrais ir hibrīdā izstrāde ar React Native vai Flutter. Šis ir visizplatītākais risinājums šodien, un ar labu iemeslu. Viens koda bāzes fails darbojas abās platformās, izstrādes laiks samazinās par 30-50%, un galvenās natīvās funkcijas ir pieejamas. React Native aiz muguras stāv Meta, Flutter - Google. Abi ir nobrieduši, abi ir ražošanas gatavi. Pie mums praksē lielākā daļa projektu šobrīd iet caur React Native ekosistēmu, īpaši ja klients jau strādā ar React tīmekļa daļu.

Trešais variants ir no-code / low-code platformas - FlutterFlow, Adalo, Bubble ar mobilajiem paplašinājumiem, Glide. Šis nav "viltus" ceļš, kā reizēm mēdz domāt tehniski cilvēki. Ja aplikācija ir vienkāršs MVP ar standarta funkcijām, datu bāzi no Airtable vai Firebase, tad no-code risinājums var nonākt veikalā par desmitiem tūkstošu eiro lētāk un mēnešiem ātrāk. Ierobežojumi sākas, kad vajag specifiku - custom animācijas, sarežģītu offline loģiku vai dziļu integrāciju ar trešo pušu API.

Expo un React Native ekosistēma praktiski

Expo ir ietvars virs React Native, kas novērš lielāko daļu sākotnējo sāpju. Tas abstrahhē Xcode un Android Studio konfigurāciju, nodrošina OTA (over-the-air) atjauninājumus bez App Store apstiprināšanas procesa, un ar Expo Go lietotni izstrādātājs var rādīt klientam darbojoša prototipa testēšanu uzreiz, bez jebkādas instalēšanas. Tas ir ērti un ātri.

Bet Expo ir arī ierobežojumi. Managed workflow - pilnībā Expo vadīts process - neļauj pievienot custom native moduļus. Ja projektam vajag, piemēram, specifiskas Bluetooth funkcijas vai biometriju ar custom SDK, tad jāiet uz bare workflow, kas faktiski ir standarta React Native ar Expo rīkiem pa virsu. Lielākā daļa nopietnu projektu nonāk tur vienā vai otrā brīdī.

EAS (Expo Application Services) ir Expo mākonī bāzēts build serviss, kas būvē .ipa un .apk/.aab failus bez vajadzības pašam uzturēt macOS build mašīnu. Tas ir ļoti praktisks, jo iOS aplikāciju var buildot uz Windows vai Linux, kas tradicionāli nebija iespējams. Cenu modelis ir sadalīts pa build minūtēm, bezmaksas kvota ir ierobežota, bet diezgan pietiekama izstrādei.

Apple un Google konti - birokrātija, ko neviens negrib, bet visi vajag

Apple Developer Program maksā 99 USD gadā. Reģistrācija uzņēmumam (ne privātpersonai) prasa D-U-N-S numuru, kas Latvijā nozīmē papildus pieprasījumu caur Dun & Bradstreet - process var aizņemt 1-2 nedēļas ja D-U-N-S numura vēl nav. Tas ir jāzina pirms projekta laika plānošanas, jo vairāki klienti ir pārsteigti, ka šis solis vien var nozīmēt pāris nedēļu kavēšanos.

Google Play Console maksā vienreizēju 25 USD. Reģistrācija ir ātrāka, taču Google pēdējo gadu laikā ir ieviesusi stingrākas pārbaudes jauniem kontiem. Pirmās aplikācijas publicēšana var prasīt closed testing periodu ar vismaz 20 testētājiem un vairāku nedēļu gaidīšanu pirms atvērtās publicēšanas.

Ja klients vēlas, lai mēs publicējam aplikāciju savā kontā un vēlāk nododam - tas tehniski ir iespējams App Store gadījumā caur App Transfer procesu, taču ir savi ierobežojumi un Watch/iMessage paplašinājumi netiek nodoti. Google Play piedāvā Developer Account Transfer, kas ir sarežģītāks un ne vienmēr gludi darbojas. Vispareizākais ceļš ir, ka klientam ir savs konts no sākuma.

TestFlight un beta testēšana Android

TestFlight ir Apple iOS beta testēšanas platforma un tā ir viena no labākajām lietām Apple ekosistēmā. Testētāji saņem uzaicinājumu uz e-pastu, instalē TestFlight lietotni, un tad katrs jauns build parādās automātiski. Var uzaicināt līdz 10 000 ārējo testētāju bez vajadzības pēc ierīces UDID reģistrācijas (kas bija sāpes senajā laikā). Iekšējie testētāji (līdz 100 cilvēki ar Developer Program piekļuvi) saņem buildu uzreiz, ārējie pēc Apple apstiprinājuma, kas parasti aizņem līdz 24 stundām.

Android pusē Google Play Console piedāvā Internal testing, Closed testing un Open testing posmus. Internal testing ir faktiski tūlītējs, Closed testingam var definēt e-pastu sarakstu vai Google grupu. Ir arī iespēja sūtīt APK failu tieši - tas vairs nav ieteicams drošības apsvērumu dēļ, bet savā komandā testēšanai joprojām darbojas.

Firebase App Distribution ir alternatīva, kas darbojas abām platformām un ir ērta, ja komanda jau izmanto Firebase ekosistēmu. Tā ļauj automatizēt distribūciju caur CI/CD pipeline.

Izstrādes process no idejas līdz veikalam

Pirms koda pirmās rindiņas ir nepieciešama Discovery fāze - funkcionālā specifikācija, user flow diagrammas, wireframe prototipi. Šo posmu bieži grib izlaist, īpaši ja budžets ir saspringts. Tas ir kļūda, un to mēs redzam atkārtoti. Ja sāc kodēt pirms ir skaidrs, ko aplikācija dara un kāpēc, tad vismaz trešdaļa darba tiks pārrakstīta.

Pēc tam nāk dizains - UI/UX prototips Figma vai līdzīgā rīkā. Apple ir publicējis Human Interface Guidelines, Google - Material Design 3 principus. Tās nav tikai estētikas vadlīnijas, tās ietekmē App Store pieņemšanas procesu. Aplikācija, kas neatbilst platformas UX konvencijām, var tikt noraidīta vai saņemt zemas atzīmes lietotāju recenzijās.

Izstrādes fāzē tipiska hibrīdā projekta struktūra izskatās aptuveni šādi - sākotnējā setup un arhitektūra, komponenšu bibliotēkas izveide, API integrācija ar backend, platformas specifiskā polishing fāze. Šī pēdējā fāze bieži tiek novērtēta par maz - pat ar React Native vai Flutter gatava aplikācija uz iOS un Android izskatās un jūtas mazliet savādāk, un tas ir jāpielāgo apzināti.

App Store Review process vidēji aizņem 1-3 dienas, taču var aizņemt ilgāk. Google Play parasti ir ātrāks, bet arī tur pirmajām publikācijām var būt 7+ dienu gaidīšana. Noraidījuma iemesli bieži ir banāli - nepareizi ekrānuzņēmumi, nepilnīgas privātuma politikas URL, vai nepareizi aprakstītas atļaujas.

Kad no-code ir īstais lēmums

Šeit ir pretintuitīvā patiesība - ja uzņēmumam vajag iekšējo rīku, piemēram, darba laika uzskaiti, piegādes maršrutu apstiprināšanu vai vienkāršu klientu portālu, un lietotāju skaits ir mazāks par 500, no-code platforma bieži ir gudrāks biznesa lēmums nekā custom izstrāde. FlutterFlow ģenerē reālu Flutter kodu, kuru var eksportēt un turpināt attīstīt ar izstrādātājiem. Tas nav strupceļš.

Problēma rodas, kad uzņēmumi sāk ar no-code, izaug tam pāri, un tad meklē migrācijas ceļu. Tas ir iespējams, bet nav bezmaksas. Ja jau sākotnēji ir skaidrs, ka aplikācijai būs sarežģīta biznesa loģika un tā ir stratēģisks produkts, tad custom izstrāde ar pareizu arhitektūru izmaksā mazāk ilgtermiņā.

Mobilo aplikāciju izstrāde Latvijas tirgum šodien ir daudz pieejamāka nekā pirms pieciem gadiem, bet tas nenozīmē, ka ir kļuvusi bezrūpīgāka. Tehnoloģiskās izvēles, ko pieņem sākumā, nosaka projekta grilingas mēnešus vēlāk. Ja plāno ieguldīt aplikācijā, vislabākā pirmā kustība nav atrast lētāko izstrādātāju, bet saprast, kas tieši tev vajadzīgs un kāpēc.