Actualizare: 5 octombrie 2026

FocusGuard apare acum ca lansat în portofoliul Trinx, cu landing public. Notele tehnice din mai, păstrate mai jos, descriu etapa anterioară lansării; nu reprezintă checklistul actual din store. Comportamentul permisiunilor și al limitării cere în continuare verificări specifice dispozitivului.

FocusGuard: instrumente native pentru timpul pe ecran

Note tehnice originale din mai 2026

FocusGuard este o aplicație de screen-time care întrerupe folosirea compulsivă a telefonului cu ecrane de friction și o colecție de mesaje motivaționale (și intenționat enervante) afișate ca overlay. Problema e cea evidentă: doomscrolling-ul și deschiderea reflexă a aplicației care transformă „verific ceva rapid" în patruzeci de minute pierdute. Categoria e plină de nudge-uri blânde pe care le închizi fără să le citești. Pariul FocusGuard e că reminderele delicate nu funcționează, așa că se bazează pe blocare la nivel de OS și pe overlay-uri gândite să fie greu de ignorat.

Am construit-o întâi pentru mine. Voiam limite pe care sistemul de operare chiar le impune, nu un banner pe care îl dau la o parte pe pilot automat. Cerința asta singură — blocare reală, nu sugestie — a dictat majoritatea deciziilor tehnice grele, inclusiv pe cea de a arunca prima versiune și a rescrie totul nativ.

Mecanica: warning, busted, lockout

Esența FocusGuard nu e tracking-ul; destule aplicații îți arată un grafic cu săptămâna ta și nu schimbă nimic. Esența e întreruperea.

Când treci de limita de timp setată pe o aplicație, FocusGuard pune un overlay pe tot ecranul peste aplicația care distrage. Sunt trei stări care escaladează. Un ecran de warning când te apropii sau abia ai depășit o limită. Un ecran „busted" când ai trecut cu mult peste și încă dai scroll. Și un lockout care chiar stă între tine și aplicație. Fiecare ecran trage dintr-o colecție de mesaje cu variante de ton, savoare și accent, însoțite de GIF-uri de reacție, ca să nu devină tapet pe care creierul învață să-l ignore. Exact ăsta e fondul ideii de behavioral design: un singur mesaj static „ai atins limita" e filtrat de creier într-o zi. Un text care se rotește, ușor absurd și cu accent, păstrează friction-ul suficient de nou cât să fie observat.

Mesajele și GIF-urile nu sunt incluse în binar. Se sincronizează din Firestore cu caching pe diferențe de versiune, ca să pot schimba tonul, adăuga replici noi sau înlocui reacții fără să lansez un update de aplicație, iar clientul re-descarcă doar colecțiile care chiar s-au modificat. Mai multe despre de ce contează sync-ul versionat și conștient de diferențe în pattern-urile de offline-first sync la care revin mereu.

Două aplicații native, o singură problemă de platformă

La blocare se rupe ideea de „folosește pur și simplu un framework cross-platform", și ăsta e motivul pentru care acest repo e o rescriere.

Prima versiune a fost React Native și Expo. Era ok pentru dashboard și grafice. Nu era ok pentru partea care contează, fiindcă partea care contează trăiește în interiorul sistemului de operare, unde nu există un bridge cross-platform curat. Pe Android, impunerea unei limite înseamnă citirea statisticilor de utilizare, apoi folosirea serviciilor de accessibility și overlay ca să detectezi că o aplicație blocată e în prim-plan și să desenezi un Activity peste ea. Pe iOS, singura cale acceptată e stiva Screen Time — FamilyControls, ManagedSettings și DeviceActivity — cu un Shield custom ca suprafață de întrerupere, rulând în app extensions, în afara procesului principal.

Nimic din toate astea nu e un strat subțire de JS peste un apel nativ. E teritoriu adânc, specific fiecărei platforme, plin de permisiuni și execuție în fundal, unde cele două sisteme de operare nici măcar nu sunt de acord asupra formei problemei. Așa că am rescris FocusGuard ca două aplicații complet native: Android în Kotlin și Jetpack Compose, iOS în Swift și SwiftUI. Planul de migrare mapează fiecare felie de React Native pe echivalentul ei din Kotlin și Swift, ceea ce a făcut rescrierea un port metodic, nu un pariu de la zero. Ca solo dev, asta e fezabil doar cu workflow-ul asistat de AI pe care mă bazez în tot ce livrez — mai multe în 11 produse ca fondator solo.

Backend-ul Firebase ca un contract între platforme

Două aplicații native creează un risc evident: drift-ul. Android și iOS pot începe pe nesimțite să scrie forme ușor diferite ale acelorași date, până când backend-ul „comun" e comun doar cu numele.

Tratez asta privind Firebase ca pe un contract strict, nu ca pe o găleată. Ambele aplicații lovesc un singur backend — Auth, Firestore, Functions, Storage, Analytics și Crashlytics. Regulile de securitate din Firestore folosesc whitelist pe câmpuri: un write pe un document e respins dacă nu fiecare câmp e pe lista permisă, cu tipul corect. Asta transformă fișierul de reguli în schema pe care ambele platforme trebuie să o respecte. Dacă aplicația de iOS încearcă să scrie un câmp pe care Android nu-l cunoaște, regulile îl resping, iar eu aflu la momentul write-ului, nu peste trei săptămâni când un grafic afișează gunoi.

Ca regulile să rămână oneste, sunt în spatele unui CI gate cu teste rulate înaintea regulilor. Rădăcina repo-ului e un mic proiect TypeScript — tsx plus Vitest — al cărui rol e să ruleze teste pe regulile Firestore în emulator. O modificare de reguli care slăbește un whitelist sau strică o constrângere existentă pică în CI înainte să poată ajunge la release. A scrie testul de reguli întâi, apoi regula, apoi codul de client care depinde de ea, e aceeași disciplină red-green pe care aș folosi-o pentru logica aplicației, aplicată pe granița de securitate, unde contează cel mai mult.

Stack-ul

Android e Kotlin 2.0 cu Jetpack Compose pentru UI, Hilt pentru dependency injection, Room și DataStore pentru persistența locală, Retrofit pentru networking, Vico pentru graficele de insights și WorkManager pentru monitorizarea în fundal care ține tracking-ul de utilizare în viață. iOS e Swift 5.10 și SwiftUI, cu SwiftData pentru stocare locală și trio-ul FamilyControls / ManagedSettings / DeviceActivity pentru blocare, împărțite pe două app extensions, ca Shield-ul și monitorizarea de activitate să ruleze unde le cere iOS.

Ambele stau pe singurul backend Firebase, cu regulile lui impuse prin whitelist. Rădăcina repo-ului poartă tooling-ul TypeScript pentru testele de reguli, iar pentru marketing există o pagină de landing separată în Astro 5. UI-ul produsului și întreaga colecție de mesaje sunt doar în engleză; documentele interne sunt în română. E un produs pentru piața de limbă engleză, scris din România — motiv pentru care articolul ăsta există în ambele limbi.

Unde e acum și ce urmează

FocusGuard e un MVP, pre-launch. Vreau să fiu precis aici, fiindcă aplicațiile de screen-time sunt exact categoria în care e tentant să rotunjești „merge pe telefonul meu" la „e live".

Ce există e real: un cod nativ complet pe ambele platforme, la versionCode 1 / 1.0.0, mecanica de blocare și overlay funcționând cap-coadă, sync-ul de conținut din Firestore, testele de reguli rulate în CI, documente de billing și de setup în store, cercetare ASO de cuvinte-cheie și pagina de landing. Ce nu există e o listare confirmată în store. Nu pot pretinde că vreuna dintre aplicații e publicată și nu voi cita numere de descărcări sau de utilizatori, fiindcă nu există vreunul pe care să-l susțin.

Golurile oneste sunt concrete. Pe Android, keystore-ul de release e încă un template, deci mai e de lucru la semnare și la Play Console până la un release real. Pe iOS, billing-ul e chiar neterminat — partea de StoreKit 2 din FocusGuard Pro e marcată TBD, iar planul e cu receipts verificate pe server care setează un flag pro, dar „planificat" nu e „gata". Calea de Play Billing v7 pe Android e mai avansată, însă tot stratul de monetizare are nevoie de testarea cap-coadă pe care o poți face cu adevărat doar odată ajuns în pipeline-ul de review din store.

Cealaltă întrebare deschisă e cea pe care o întâlnește orice aplicație de blocare: cât de greu să faci evadarea. Friction-ul trivial de ocolit e teatru; cel imposibil de ocolit e un coșmar de suport prima dată când cineva chiar are nevoie de telefon. Reglarea liniei ăsteia — cât de încăpățânat ar trebui să fie lockout-ul, cum cade textul cu accent peste săptămâni, nu peste minute — e munca de produs care a rămas, și e partea pe care o pot învăța doar de la oameni care nu sunt eu.

Dacă vrei să vezi cum se așază FocusGuard lângă restul lucrurilor pe care le livrez, lista completă de proiecte e aici. Iar dacă te interesează partea de sync multi-platformă, articolul despre offline-first sync e cel cu care aș începe. Dacă vrei să afli când ajunge efectiv într-un store, newsletterul e locul unde voi spune asta.

KotlinSwiftUIFirebasemobilebehavioral-design
Distribuie articolul