Pred tromi rokmi sme React Native zvolili ako default pre väčšinu mobilných projektov. Dnes ho zvolíme približne v rovnakom percente prípadov. Argumenty na oboch stranách stola však pribudli. Toto je krátke zhrnutie toho, kde dnes stojíme — vrátane projektu, kde sme sa rozhodli zle.
Zhruba 60–70 % mobilných projektov, ktoré v EliteTech dodávame, stále beží na React Native.
Čo sa za tri roky zmenilo proti React Native
Tooling od Apple a Google sa zlepšil. SwiftUI a Jetpack Compose sú dnes citeľne lepšie ako v roku 2023 — a hlavne stabilnejšie ako pred rokom. Native development bolí menej, než bolieval.
Tooling React Native sa tiež zlepšil. New Architecture (Fabric + TurboModules) je už defaultná a stable. Expo SDK 52 priniesol prakticky bezbolestné buildy. Performance gap, ktorý bol pred troma rokmi reálnym argumentom, je dnes pri 90 % aplikácií merateľný iba mikrobenchmarkami.
Argument „native je rýchlejší” je dnes pravdivý, ale väčšinou irelevantný. Argument „JS bundle je tučný” tiež. Argument „crash reporting je trošku horší” odpadol — Sentry pre RN je dnes prakticky identický s native verziou.
Čo sa za tri roky nezmenilo v prospech React Native
Jedna kódová základňa pre iOS aj Android. To bol vždy hlavný argument. Pre väčšinu B2B aplikácií a 80 % B2C aplikácií, ktoré nepotrebujú vrchol UI inovácie, to znamená polovičný tím, polovičnú dĺžku release cyklu a jednotnú business logiku. Tento argument starne ako dobré víno — neoslabuje sa, zosilňuje sa tým, že platy seniorov ďalej rastú.
Hot reload pri vývoji. Žiadna native technológia toto zatiaľ nedostihla. Cyklus „zmena → kompilácia → install → otvor obrazovku, ktorú testuješ” je v native 5–15× pomalší než v RN. Pre tím, ktorý iteruje na UI tridsaťkrát za deň, je to merateľný rozdiel v output-e.
Zdieľanie kódu s webom. Ak má klient aj webovú aplikáciu, väčšina business logiky je presne tá istá. RN + Next.js + monorepo nám pravidelne vychádza ako zhruba 30 % menej kódu než paralelný native + web stack. Toto sa za posledných šesť rokov nezmenilo.
Dve výnimky, pri ktorých dnes siahame po native
Prvá výnimka: aplikácie, kde rozhoduje grafický výkon. Kamerové aplikácie, AR, hry, niečo s ťažkou editáciou videa alebo real-time computer vision. Tam ide o framerate a o prístup k native graphics API. RN vie urobiť 90 % toho, čo native — ale tých 10 %, kde je rozdiel, je presne tam, kde rozhoduje pocit.
Druhá výnimka: aplikácie, kde Apple alebo Google priniesli platformovo špecifické fíčry, ktoré sa do RN ekosystému ešte nedostali. Live Activities na iOS, App Intents pre Siri, niektoré Wear OS API. Existujú native moduly, ktoré to pokrývajú — ale ak má aplikácia tieto fíčry v jadre, native development bude rýchlejší.
Projekt, u ktorého sme sa pomýlili
V roku 2024 sme jednému klientovi odporučili React Native pre B2C aplikáciu, ktorá silne závisela od Apple Wallet integrácie a Apple Live Activities pre real-time updaty. Skĺzli sme dva mesiace, lebo sme strávili šesť týždňov písaním vlastných native modulov, ktoré komunita ešte neudržiavala. Aplikácia dodaná, beží — ale ak by sme začínali znova, šli by sme Swift + Kotlin a ušetrili by sme klientovi dva mesiace a nám šesťdesiat hodín nudných native-module pull requestov.
Čo sme si z toho prepísali do vlastných pravidiel: ak má aplikácia v core feature sete tri alebo viac platformovo špecifických fíčrov, ktoré nemajú stabilné RN balíky s aktívnou údržbou, prepneme na native bez debaty.
Default by mal byť ten, ktorý platí pre 80 % prípadov. Disciplína je v tom, že keď zvyšných 20 % zaklope, nepredstierame, že to nepočujeme.
React Native nie je hype, ktorý prešiel. Je to nudná, dospelá technológia, ktorú vieme dobre. Preto sa stále hodí pre väčšinu klientov, ktorým robíme mobil. Ak chcete druhý názor na to, či by ste mali svoj projekt postaviť v RN alebo native, ozvite sa — discovery na mobilnú aplikáciu trvá dva týždne a väčšinou končí jednostranovým memom, kde je odporúčanie jasné.
