Splync v1.5 — Raporturi de Împărțire Personalizabile pe Proiect și Categorie

Pe 16 septembrie 2025, Splync v1.5 a fost lansat — la doar patru zile după ce căsătoria noastră internațională a fost acceptată de oraș. Până la această actualizare, Splync nu putea personaliza raporturile de împărțire deloc; fiecare cheltuială era împărțită egal în mod implicit. Cu v1.5, utilizatorii pot acum să seteze raporturi personalizate atât pe proiect, cât și pe categorie. Această schimbare le permite cuplurilor și prietenilor să își împartă costurile comune în moduri care reflectă mai bine viețile lor reale, nu doar un simplu 50:50. Poți începe un nou proiect contabil cu un raport de 60:40 pentru cheltuielile zilnice din octombrie, menținând în același timp chiria apartamentului la un echitabil 50:50 dacă asta vi se pare corect. Și dacă alimentele sunt mai echitabile la 70:30, iar utilitățile la 62:38, acum poți atribui aceste raporturi separat — categorie cu categorie — în același proiect.

Cea mai vizibilă schimbare în v1.5 este noua secțiune Membri & Cote Implicite, unde poți adăuga membri ai proiectului și poți atribui fiecăruia o cotă implicită. Dacă un proiect are doi membri, raportul poate fi 50:50, 40:60 sau orice valoare consideri potrivită. Cu trei membri, poate fi 33.33:33.33:33.34, 50:25:25 sau orice combinație preferi. Aceasta devine împărțirea implicită a proiectului. Mai jos, poți derula pentru a ajusta cota fiecărei categorii dacă vrei să fie diferită de cea implicită a proiectului. Când atribui un raport personalizat unei categorii, marca sa albastră devine portocalie — un mic indiciu vizual că categoria folosește propria regulă în loc de cea generală. Deși această schimbare adaugă mult mai multă flexibilitate setărilor de proiect, face și vizualizarea de creare/editare a proiectului un pic mai complexă. Pentru a ajuta, am adăugat butoane informative în fiecare secțiune, astfel încât să le poți atinge pentru a vedea mici ajutoare Q&A.

Implementarea acestei schimbări a fost mai complexă decât mă așteptam. Splync a presupus întotdeauna o lume curată de 50:50 — un singur număr, aplicat peste tot, și matematica era gata. Odată ce am decis să susțin rapoarte personalizate, întreaga structură internă a trebuit regândită. Un proiect nu mai putea să se bazeze pe un singur procentaj comun. Fiecare categorie avea nevoie de propriul său raport, iar fiecare cheltuială trebuia să facă referire atât la raportul implicit la nivel de proiect, cât și la suprascrierea la nivel de categorie. Pentru a face acest lucru să funcționeze, am rescris logica de calcul de la zero. Fiecare cheltuială are acum un mic arbore decizional: „Această categorie are propriul raport? Dacă da, folosește-l. Dacă nu, revino la raportul proiectului.” Sună simplu când explici, dar menținerea modelului de date consistent în aplicație — vizualizările iOS, backend-ul FastAPI și schemele MariaDB — a necesitat ajustări mai atente decât mă așteptam.

Orice actualizare care atinge partea de server trebuie gestionată cu mare grijă. Dacă modifici accidental codul serverului existent, utilizatorii care încă folosesc v1.4 vor întâmpina imediat erori sau probleme de sistem. De exemplu, programul serverului pentru v1.5 se așteaptă ca setările proiectului să includă date despre raporturi, dar aplicația v1.4 trimite setările proiectului fără niciun raport. În momentul în care cele două versiuni încearcă să comunice, cererea eșuează — pur și simplu pentru că „vorbesc” limbaje ușor diferite. Dezvoltatorii pot, desigur, să facă modificări în siguranță într-un mediu de testare. Partea dificilă începe după trimiterea unei noi versiuni pentru revizuirea Apple, în timp ce utilizatorii existenți sunt încă pe v1.4. Pe toată perioada de la trimitere la lansare, serverul trebuie să susțină ambele versiuni în același timp, astfel încât examinatori Apple să poată testa v1.5 și utilizatorii existenți să poată continua să folosească v1.4 fără întreruperi.

În dezvoltarea aplicațiilor, un „endpoint” este pur și simplu locul unde aplicația își trimite cererile pe server — un pic ca un ghișeu specific la un primărie. Un ghișeu se ocupă de înregistrările de căsătorie, altul de evidențele locuitorilor și altul de pașapoarte. Aplicațiile funcționează la fel: fiecare endpoint este o fereastră dedicată unde serverul acceptă un tip specific de cerere, cum ar fi autentificarea, crearea de proiecte, editarea cheltuielilor, cererea de prietenie etc. Când Splync v1.4 trimite o cerere, merge la „fereastra veche” care înțelege formatul mai vechi. Splync v1.5 își trimite cererea la „fereastra nouă” care înțelege datele despre raporturi. Dacă serverul ar închide fereastra veche prea devreme, utilizatorii v1.4 nu ar avea unde să își „depună” datele. De aceea, în timpul unei actualizări, serverul trebuie să țină ambele ferestre deschise — ambele endpoint-uri — până când fiecare utilizator s-a mutat în siguranță la versiunea mai nouă. Sincer, gestionarea acestor două ferestre în același timp a fost ca și cum ai gândi într-o dimensiune suplimentară.

Splync v1.5 poate personaliza împărțirile pe proiect și pe categorie, dar nu încă pe cheltuială. Pentru a suporta raporturi pe cheltuială, avem nevoie de un alt strat structural — practic o rescriere mai profundă a modului în care fiecare cheltuială își stochează și își calculează cotele. De asemenea, trebuie să fim atenți să nu complicăm brusc interfața aplicației doar de dragul de a adăuga mai multă putere. Este o actualizare mai mare decât pare. Te rog să ne dai puțin mai mult timp pentru a ajunge acolo. Este pe orizontul nostru — și vom ajunge acolo. Până atunci, să explorăm cum noile raporturi pe proiect și pe categorie fac deja cheltuielile comune mult mai flexibile.