Salutare tuturor. Am scos recent un habit tracker pe store-uri, făcut cap-coadă în Expo, și după prima lună am adunat vreo 200 de useri activi. Nu e o cifră care să te dea pe spate, dar e suficient cât să-mi dea niște palme peste ceafă legate de deciziile tehnice luate la început.
De ce Expo și ce am pus sub capotă
Am mers pe Expo Managed Workflow. Acum 5 ani fugeam de el ca dracu' de tămâie, dar acum, cu Config Plugins și EAS (Expo Application Services), nu prea mai ai motive să te chinui cu setup-uri native manuale decât dacă faci ceva extrem de exotic. Stack-ul a fost relativ simplu: Expo Router pentru navigație, Supabase pentru auth și baza de date, și TanStack Query pentru gestionarea stării de server.
Am ales Supabase pentru că voiam să fiu gata de launch în două weekend-uri. Mi-a salvat cam 30% din timpul de development pe partea de backend, mai ales cu Row Level Security (RLS) care m-a scăpat de scris un API layer separat. Pur și simplu interoghez baza direct din client și las politicile de securitate să-și facă treaba.
Unde s-a rupt filmul și unde am greșit
Cea mai mare greșeală a fost abordarea „offline-first” implementată prost. Am vrut ca aplicația să meargă brici și pe munte, fără semnal, așa că am început cu o logică custom de sincronizare între SQLite local și Supabase. Mare prostie. M-am trezit cu conflicte de date pe care nu le anticipasem la un proiect pornit de la zero. La 200 de useri, am avut vreo 15 tichete de suport de tipul „mi-a dispărut progresul de ieri” sau „habitul apare de două ori”.
Dacă aș lua-o de la capăt, aș lăsa-o „online-only” cu un cache agresiv prin TanStack Query până când chiar aș fi avut nevoie de un sistem de sync serios. Am pierdut vreo 3-4 seri bune debug-uind conflicte de timestamp-uri care puteau fi evitate dacă nu mă chinuiam să reinventez roata sincronizării.
Trade-offs sincere: Expo Router și FlashList
Expo Router e mișto, are feeling de Next.js, dar are momente când te încurcă la deep linking dacă nu ești extrem de atent la structura de foldere. Am avut bătăi de cap cu e-mailurile de confirmare de la Supabase care nu deschideau aplicația corect pe Android în mediul de producție. Rezolvarea a fost să trec la scheme custom, dar a durat până m-am prins de ce nu mergea în release build deși în development era totul ok.
Altă fază: m-am obsedat de performanța listelor. Am folosit FlashList de la Shopify, care e genială, dar am pierdut prea mult timp optimizând re-randări pe care userul oricum nu le observa pe un telefon de generație nouă. La un habit tracker, oamenii vor să bifeze ceva rapid și să închidă app-ul, nu să admire 120 FPS la un scroll infinit de 10 elemente. Am prioritizat greșit micro-optimizările în detrimentul UX-ului de onboarding.
Ce aș schimba mâine
În primul rând, aș configura EAS Build și Submit din prima zi. Am lăsat asta spre final și m-am trezit că build-ul de producție crapă din cauza unei variabile de mediu lipsă exact când voiam să dau drumul la o mică promovare pe Reddit.
Dacă aveți de gând să lansați ceva mic, sfatul meu e să nu vă complicați cu baze de date locale complexe din prima zi. Mergeți pe ceva simplu, validați ideea, și dacă treceți de pragul de 1000 de useri, atunci merită să investiți timp în arhitecturi de sync complicate. Simplitatea bate scalabilitatea teoretică de fiecare dată la lansare.
Voi ce stack folosiți pentru proiectele de tip „weekend warrior”? Ați trecut pe Expo Router sau rămâneți la clasicul React Navigation?