eduardweb.
Prezentări & ShowcaseIntermediar#react-native#expo#supabase#showcase#mobile-dev

Am lansat un habit tracker în Expo cu 200 useri în prima lună. Ce-am învățat și ce-aș schimba

De Cristian Barbu, 16 iun. 2026 · 18 vizualizări · 2 like-uri

Postat 16 iun. 2026

Salutare! Lunile trecute am vrut să-mi fac ordine în tabieturi și, în loc să folosesc o foaie de hârtie sau o aplicație plină de reclame, am construit propriul habit tracker în Expo. Am lansat-o fără pretenții mari pe Reddit și pe câteva grupuri, dar am strâns rapid 200 de utilizatori activi în prima lună.

Proiectul a fost o oportunitate excelentă să testez limitele ecosistemului Expo actual. Deși pe hârtie totul părea simplu, realitatea din producție m-a lovit destul de repede peste degete.

Stack-ul tehnic și de ce am ales Expo

Am mers pe Expo (React Native), Supabase pentru backend și Tailwind (via NativeWind) pentru stilizare. De ce Expo? Pentru că EAS (Expo Application Services) s-a maturizat enorm în ultima vreme. Am vrut să livrez repede, fără să-mi prind urechile în Xcode sau Android Studio în primele faze ale proiectului.

Trade-off-ul sincer? Expo este superb până când ai nevoie de o librărie nativă obscură care nu e suportată direct în Expo Go. Atunci trebuie să treci la custom development builds, ceea ce adaugă un strat în plus de configurare și compilare locală. Din fericire, pentru un habit tracker, SDK-ul standard a fost arhisuficient.

Greșeala cu baza de date și sync-ul offline

Aici m-am fript cel mai tare. Am vrut ca aplicația să funcționeze instant și offline. Am folosit Supabase direct, gândindu-mă că fac eu rapid un mecanism simplu de sync cu AsyncStorage în React Native. Mare greșeală.

Când userii au început să bifeze obiceiuri în metrou, fără conexiune la internet, iar apoi deschideau aplicația acasă, sincronizarea mea custom dădea rateuri masive. Am primit vreo 15 mailuri de suport în prima săptămână de la oameni supărați că li s-au șters streak-urile. Nimic nu enervează mai mult un om pasionat de productivitate decât să-i strici un streak de 20 de zile.

Soluția corectă ar fi fost să folosesc WatermelonDB sau SQLite din prima zi cu un algoritm serios de conflict resolution, nu o cârpeală scrisă de mine duminică noaptea la ora 2.

Push notifications — capcana pe care am evitat-o

La notificări, în schimb, am fost inspirat. În loc să configurez Firebase Cloud Messaging direct și să mă lupt cu certificatele APNS de la Apple, am folosit Expo Notifications API. Mi-a salvat cel puțin 3 zile de muncă și nervi.

Trimit mementouri zilnice la ora 20:00 prin serverul lor și rata de deschidere este de aproape 40%. A fost cel mai bun feature pentru retenția utilizatorilor pe care l-am implementat.

Ce aș schimba dacă aș lua-o de la capăt

În primul rând, aș renunța complet la Supabase pentru faza de MVP. Aș stoca totul local pe dispozitiv cu o simplă opțiune de export/import JSON în iCloud sau Google Drive. Pentru 200 de useri, un backend centralizat e overkill și doar adaugă latență la pornire (aplicația se încărca în 4 secunde pe telefoanele mai vechi din cauza apelurilor de rețea la inițializare).

În al doilea rând, n-as mai pierde trei nopți să desenez grafice de progres cu SVG-uri custom. Puteam folosi o librărie de bază sau chiar simple emoji-uri de progres, iar utilizatorii ar fi fost la fel de mulțumiți.

În final, proiectul rulează stabil acum și mă costă exact 0 dolari pe lună pentru că mă încadrez în free tier-urile de la Supabase și Expo.

Voi cum gestionați starea offline în aplicațiile de mobil? Mergeți pe soluții gata făcute sau vă scrieți propriul sync engine?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.