Când cineva îți propune React Native, întrebarea firească e „nu iese mai prost decât o aplicație adevărată?”. Răspunsul scurt: pentru aplicații de business, nu. Răspunsul lung merită cinci minute, pentru că există cazuri în care nativul rămâne singura variantă corectă.
Ce înseamnă fiecare abordare
Nativ înseamnă două aplicații separate: una scrisă în Swift pentru iPhone, una în Kotlin pentru Android. Două baze de cod, doi dezvoltatori sau două echipe, două seturi de erori, două lansări.
React Native înseamnă o singură bază de cod care produce ambele aplicații. Interfața folosește componentele native ale fiecărui sistem — un buton pe iPhone e un buton iOS real, nu o imitație — dar logica se scrie o singură dată.
Distincția asta e importantă: React Native nu e un site împachetat într-o aplicație. Aceea e altă categorie, se numește aplicație hibridă, e mai ieftină și se vede că e mai ieftină.
Diferența de buget, cu cifre
Pentru o aplicație de business cu conturi, listă de comenzi, notificări și lucru offline:
| Nativ (iOS + Android) | React Native | |
|---|---|---|
| Dezvoltare inițială | ~1.700 € | ~900 € |
| O funcție nouă medie | 2 × efortul | 1 × efortul |
| Corectarea unei erori | de două ori, uneori diferit | o dată |
| Mentenanță anuală | mai mare | mai mică |
| Echipă necesară | două specializări | una |
Raportul se păstrează în timp: fiecare modificare ulterioară costă aproximativ dublu pe nativ. Pentru o aplicație care trăiește trei ani și primește actualizări, diferența cumulată depășește costul inițial.
Când nativul e alegerea corectă
Sunt cazuri clare, nu chestiuni de gust:
- Grafică intensă. Jocuri, realitate augmentată, prelucrare video în timp real. React Native nu e făcut pentru asta.
- Funcții de sistem foarte noi. Când Apple scoate ceva la conferința anuală, suportul în React Native apare cu câteva luni întârziere. Dacă produsul tău depinde de acea funcție în prima lună, ai nevoie de nativ.
- Widgeturi complexe pe ecranul de start sau integrare adâncă cu ceasul. Se pot face, dar partea aceea se scrie tot nativ, deci avantajul dispare.
- Cerințe de securitate excepționale. Aplicații bancare cu detecție de dispozitiv modificat, de exemplu.
Când React Native e alegerea evidentă
- Aplicația arată date dintr-un sistem pe care îl ai deja: comenzi, stocuri, programări, facturi.
- Ai nevoie de ambele platforme, dar bugetul ajunge pentru una.
- Aplicația va primi funcții noi des, iar tu vrei să livrezi rapid.
- Echipa ta știe deja JavaScript sau TypeScript.
Marea majoritate a aplicațiilor de business intră aici. Aplicația de livrări pe care am construit-o pentru Băiatul cu Flori e React Native, funcționează pe ambele platforme și oamenii de pe teren o folosesc zilnic, fără să se pună problema că ar fi „mai puțin nativă”.
Mituri care au fost adevărate acum cinci ani
„Se mișcă mai încet”
A fost adevărat până în 2022, când React Native comunica cu partea nativă printr-o punte care putea deveni aglomerată. Arhitectura nouă a eliminat problema. Pentru liste, formulare, hărți și navigare — adică pentru tot ce face o aplicație de business — diferența nu se simte.
„Nu arată nativ”
Depinde de cine o construiește. Dacă cineva ia designul de pe Android și îl pune identic pe iOS, se vede. Dacă respectă convențiile fiecărui sistem — navigarea, gesturile, poziția butoanelor — nu se vede. Aceeași regulă se aplică și aplicațiilor native prost făcute.
„Apple respinge aplicațiile React Native”
Nu. Respinge aplicațiile care sunt doar un site împachetat, indiferent de tehnologie. O aplicație React Native cu funcții proprii trece la fel de ușor ca una nativă.
Ce trebuie verificat înainte de decizie
O listă scurtă de întrebări care evită surprizele:
- Aplicația are nevoie de Bluetooth pentru un dispozitiv anume? Verifică dacă există bibliotecă pentru acel dispozitiv.
- Are nevoie să funcționeze complet fără internet? Se poate, dar trebuie proiectat de la început, nu adăugat după.
- Trebuie să ruleze ceva în fundal la intervale fixe? Ambele sisteme limitează asta agresiv; verifică ce e realist.
- Ai nevoie de plăți în aplicație? Apple ia 15–30% din tranzacțiile pentru conținut digital. Pentru bunuri fizice nu ia nimic. Diferența schimbă modelul de business.
Conturile din magazine
Un detaliu administrativ care încurcă multe firme: conturile de developer trebuie să fie ale tale, pe firma ta, nu ale furnizorului.
- Apple Developer Program: 99 $ pe an, cere un cont de organizație și un cod DUNS pentru firmă. Obținerea codului poate dura una-două săptămâni, deci se începe devreme.
- Google Play Console: 25 $, taxă unică.
Furnizorul primește acces ca dezvoltator. Dacă schimbi furnizorul, aplicația rămâne a ta, cu tot cu recenzii și utilizatori. Dacă e invers, pleci fără aplicație.