Salutare tuturor. Am vrut să testez pe bune noul workflow de la Expo (EAS și Expo Router) așa că am construit și lansat un mini habit tracker în App Store și Play Store. În prima lună am strâns aproape 200 de utilizatori activi, complet organic, iar experimentul mi-a arătat exact unde strălucește toolchain-ul actual de React Native și unde te lovești de pragul de sus.
Dacă te gândești să lansezi un proiect personal pe mobil, am adunat aici câteva concluzii reci, direct din producție.
Stack-ul tehnic: De ce am ales offline-first
Aplicația e simplă: îți definești obiceiuri zilnice și le bifezi. Am vrut neapărat să meargă instant, fără loading spinners când ești în metrou sau ai semnal prost.
De asta am mers pe un setup offline-first:
- Frontend: Expo (cu Expo Router v2).
- Bază de date locală: WatermelonDB. E incredibil de rapidă fiindcă rulează pe un thread separat, dar configurarea lui în Expo e un chin total din cauza pachetelor native.
- Backend: Supabase pentru autentificare și sync-ul bazei de date.
Trade-off-ul e evident. Ai o viteză de răspuns de sub 10ms la orice acțiune a userului (totul e local), dar sincronizarea cu backend-ul devine o problemă de inginerie în sine. Dacă aș fi folosit un simplu Fetch către un API clasic Postgres, terminam aplicația în 3 zile în loc de 3 săptămâni.
Greșeala cu sincronizarea care mi-a stricat weekendul
Cea mai mare prostie pe care am făcut-o a fost arhitectura de sync. Am vrut să fac sincronizare bidirecțională în timp real. Când userul bifa ceva offline și apoi pornea netul, trimiteam delta-urile în Supabase.
La vreo 50 de useri activi, au început să apară conflicte de scriere. Unii foloseau aplicația de pe două device-uri (iPad și telefon). WatermelonDB genera ID-uri locale, Supabase avea regulile lui, iar logica mea de „last write wins” a început să șteargă progresul oamenilor. Am pierdut cam 15 ore de debugging să repar asta și am pierdut și vreo 10 useri care s-au enervat că li s-au șters datele.
Lecția învățată? Pentru un MVP, nu te complica cu sync bidirecțional complex. Lasă datele pe telefon și oferă o opțiune simplă de export manual sau folosește o schemă ultra-simplificată unde doar adaugi înregistrări (append-only log), fără update-uri complexe.
Costuri reale și performanță
Pe partea de costuri, totul a fost ridicol de ieftin. Practic, m-a costat doar licența de Apple Developer (99 USD/an).
- Supabase: Pe tier-ul free (baza de date e minusculă, doar text).
- EAS Build (Expo): Am folosit serverele lor gratuite. Coada de așteptare durează uneori 15 minute la orele de vârf, dar am economisit zeci de dolari pe care i-aș fi dat pe mașini virtuale în cloud.
Aplicația are acum în jur de 210 useri unici pe lună. Crash-rate-ul e sub 0.5%, ceea ce pentru un proiect făcut în weekenduri e chiar decent.
Ce aș schimba acum?
Dacă aș lua proiectul de la zero mâine, aș arunca WatermelonDB la gunoi pentru un MVP. Aș folosi direct SQLite simplu sau chiar AsyncStorage dacă datele sunt puține. Setup-ul de WatermelonDB cu JSI mi-a mâncat zile din viață la fiecare update de versiune Expo.
Voi ce folosiți pentru stocare locală în Expo când aveți nevoie de ceva mai serios decât simple chei-valori?