Splync v1.5 — Rapporti di suddivisione personalizzabili per progetto e categoria

Il 16 settembre 2025 è stata lanciata Splync v1.5, solo quattro giorni dopo che il nostro matrimonio internazionale è stato finalmente riconosciuto dalla città. Fino a questo aggiornamento, Splync non poteva personalizzare i rapporti di suddivisione; ogni spesa era divisa equamente di default. Con v1.5, gli utenti possono ora impostare rapporti personalizzati sia per progetto che per categoria. Questo cambiamento consente a coppie e amici di dividere i costi comuni in modi che riflettono meglio la loro vita reale, non solo un semplice 50:50. Puoi avviare un nuovo progetto contabile con una suddivisione 60:40 per le spese quotidiane da ottobre, mantenendo l'affitto dell'appartamento a un equo 50:50 se così sembra giusto a entrambi. E se la spesa alimentare è più equilibrata a 70:30 mentre le utenze a 62:38, ora puoi assegnare quei rapporti separatamente — categoria per categoria — all'interno dello stesso progetto.

Il cambiamento più evidente in v1.5 è la nuova sezione Membri e Quote Predefinite, dove puoi aggiungere membri al progetto e assegnare a ciascuno una quota predefinita. Se un progetto ha due membri, il rapporto potrebbe essere 50:50, 40:60 o quello che sembra giusto. Con tre membri, potrebbe essere 33.33:33.33:33.34, 50:25:25 o qualsiasi combinazione preferisci. Questo diventa il rapporto predefinito del progetto. Sotto puoi scorrere per regolare la quota di ciascuna categoria se vuoi che sia diversa dal predefinito del progetto. Quando assegni un rapporto personalizzato a una categoria, il suo segno blu diventa arancione — un piccolo indicatore visivo che la categoria sta usando la propria regola invece di quella dell'intero progetto. Mentre questo cambiamento aggiunge molta più flessibilità alle impostazioni del progetto, rende anche la vista di creazione/modifica progetti un po' più complessa. Per aiutarti, ho aggiunto pulsanti informativi a ciascuna sezione così puoi toccarli per vedere piccoli aiuti Q&A.

Implementare questo cambiamento è stato più complesso di quanto pensassi. Splync ha sempre pensato a un mondo pulito 50:50 — un numero, applicato ovunque, e la matematica era fatta. Una volta deciso di supportare rapporti personalizzati, l'intera struttura interna ha dovuto essere ripensata. Un progetto non poteva più fare affidamento su una singola percentuale condivisa. Ogni categoria necessitava del proprio rapporto, e ogni spesa doveva fare riferimento sia al predefinito del livello del progetto sia all'override del livello della categoria. Per far funzionare questo, ho riscritto la logica di calcolo dalle basi. Ogni spesa ora ha un piccolo albero decisionale: "Questa categoria ha il proprio rapporto? Se sì, usa quello. Se no, ricadi sul rapporto del progetto." Sembra semplice da spiegare, ma mantenere il modello di dati coerente in tutta l'app — viste iOS, backend FastAPI e schemi MariaDB — ha richiesto una sintonizzazione più attenta di quanto pensassi.

Qualsiasi aggiornamento che tocca il lato server deve essere gestito con estrema cura. Se modifichi accidentalmente il codice server esistente, gli utenti ancora su v1.4 incontreranno immediatamente bug o errori di sistema. Ad esempio, il programma server per v1.5 si aspetta che le impostazioni del progetto includano dati sui rapporti, ma l'app v1.4 invia impostazioni del progetto senza alcun rapporto. Nel momento in cui queste due versioni tentano di comunicare, la richiesta fallisce — semplicemente perché parlano "linguaggi" leggermente diversi. Gli sviluppatori possono, ovviamente, apportare modifiche in sicurezza in un ambiente di test. La parte difficile inizia dopo aver inviato una nuova versione per la revisione di Apple mentre gli utenti esistenti sono ancora su v1.4. Durante tutto il periodo dalla presentazione al rilascio, il server deve supportare entrambi le versioni contemporaneamente in modo che i revisori Apple possano testare v1.5 e gli utenti esistenti possano continuare a utilizzare v1.4 senza interruzioni.

Nello sviluppo di app, un "endpoint" è semplicemente il luogo dove l'app invia le sue richieste al server — un po' come uno sportello specifico in un municipio. Uno sportello gestisce le registrazioni dei matrimoni, un altro i registri dei residenti, e un altro ancora i passaporti. Le app funzionano allo stesso modo: ogni endpoint è una finestra dedicata dove il server accetta un tipo specifico di richiesta come login, creazione di progetti, modifica delle spese, richiesta di amicizia, ecc. Quando Splync v1.4 invia una richiesta, va alla "vecchia" finestra che comprende il formato più vecchio. Splync v1.5 invia la sua richiesta a una "nuova" finestra che comprende i dati dei rapporti. Se il server chiudesse la vecchia finestra troppo presto, gli utenti di v1.4 non avrebbero dove "inviare" i loro dati. Ecco perché, durante un aggiornamento, il server deve mantenere aperte entrambe le finestre — entrambi gli endpoint — fino a quando ogni utente non si è spostato in sicurezza alla versione più recente. Ad essere sincero, gestire queste due finestre contemporaneamente sembrava pensare in una dimensione extra.

Splync v1.5 può personalizzare le suddivisioni per progetto e per categoria, ma non ancora per singola spesa. Per supportare i rapporti per singola spesa, abbiamo bisogno di un altro strato strutturale — essenzialmente una riscrittura più profonda di come ogni spesa memorizza e calcola le sue quote. Dobbiamo anche fare attenzione a non complicare improvvisamente l'interfaccia dell'app solo per aggiungere più potenza. È un aggiornamento più grande di quanto sembri. Per favore, dacci un po' più di tempo per arrivarci. È nel nostro orizzonte — e ci arriveremo. Fino ad allora, esploriamo come i nuovi rapporti per progetto e per categoria rendono già le spese condivise molto più flessibili.