Splync v1.5 — Tilpasningsdygtige Fordelingsforhold pr. Projekt og Kategori

Den 16. september 2025 blev Splync v1.5 lanceret — blot fire dage efter vores internationale ægteskab endelig blev accepteret af byen. Indtil denne opdatering kunne Splync slet ikke tilpasse fordelingsforhold; hver udgift blev delt ligeligt som standard. Med v1.5 kan brugere nu indstille tilpassede forhold både pr. projekt og kategori. Denne ændring giver par og venner mulighed for at dele deres fælles udgifter på måder, der bedre afspejler deres virkelige liv, ikke bare en simpel 50:50. Du kan starte et nyt regnskabsprojekt med en 60:40 fordeling for daglige udgifter fra oktober, mens du holder huslejen på et lige 50:50, hvis det føles fair for jer begge. Og hvis dagligvarer føles mere afbalanceret ved 70:30, mens forsyningsselskaber føles bedre ved 62:38, kan du nu tildele disse forhold separat — kategori for kategori — inden for det samme projekt.

Den mest synlige ændring i v1.5 er den nye sektion Medlemmer & Standardandele, hvor du kan tilføje projektmedlemmer og tildele hver person en standardandel. Hvis et projekt har to medlemmer, kan forholdet være 50:50, 40:60, eller hvad der føles rigtigt. Med tre medlemmer kunne det være 33.33:33.33:33.34, 50:25:25, eller enhver kombination du foretrækker. Dette bliver projektets standardfordeling. Under dette kan du rulle ned for at justere hver kategoris andel, hvis du vil have det til at adskille sig fra projektets standard. Når du tildeler et tilpasset forhold til en kategori, skifter dens blå forholdsmarkør til orange — et lille visuelt tegn på, at kategorien bruger sin egen regel frem for den projektomfattende. Mens denne ændring tilføjer meget mere fleksibilitet til projektindstillingerne, gør den også oprettelses/redigeringsvisningen lidt mere kompleks. For at hjælpe med dette tilføjede jeg informationsknapper til hver sektion, så du kan trykke på dem for at se små Q&A-hjælpere.

Implementeringen af denne ændring var mere kompleks, end jeg havde forventet. Splync havde altid antaget en ren 50:50 verden — ét tal, anvendt overalt, og beregningen var gjort. Når jeg besluttede at understøtte tilpassede forhold, skulle hele den interne struktur gentænkes. Et projekt kunne ikke længere stole på en enkelt delt procentdel. Hver kategori havde brug for sit eget forhold, og hver udgift skulle referere både til projektets standard og kategoriets tilsidesættelse. For at få dette til at fungere, omskrev jeg beregningslogikken fra bunden. Hver udgift har nu et lille beslutningstræ: "Har denne kategori sit eget forhold? Hvis ja, brug det. Hvis ikke, fald tilbage til projektforholdet." Det lyder enkelt, når man forklarer det, men at holde datamodellen konsistent på tværs af appen — iOS-visninger, FastAPI-backend og MariaDB-skemaer — krævede mere omhyggelig justering, end jeg havde forventet.

Enhver opdatering, der berører serversiden, skal håndteres med ekstrem forsigtighed. Hvis du ved et uheld ændrer eksisterende serverkode, vil brugere, der stadig er på v1.4, straks støde på fejl eller systemfejl. For eksempel forventer serverprogrammet for v1.5, at projektindstillinger indeholder forholdsdata, men v1.4-app'en sender projektindstillinger uden nogen forhold overhovedet. Det øjeblik, de to versioner forsøger at kommunikere, mislykkes anmodningen — simpelthen fordi de taler lidt forskellige "sprog". Udviklere kan selvfølgelig foretage ændringer sikkert i et testmiljø. Den svære del begynder efter at have indsendt en ny version til Apples gennemgang, mens eksisterende brugere stadig er på v1.4. I hele perioden fra indsendelse til frigivelse skal serveren understøtte begge versioner samtidig, så Apple-gennemgangere kan teste v1.5, og eksisterende brugere kan fortsætte med at bruge v1.4 uden afbrydelser.

I app-udvikling er en "endpoint" blot det sted, hvor appen sender sine anmodninger på serveren — lidt ligesom en specifik skranke i et rådhus. Én skranke håndterer ægteskabsregistreringer, en anden håndterer bopælsoptegnelser, og en anden håndterer pas. Apps fungerer på samme måde: hver endpoint er et dedikeret vindue, hvor serveren accepterer en bestemt type anmodning som login, projektoprettelse, udgiftsredigering, venneanmodning osv. Når Splync v1.4 sender en anmodning, går den til det "gamle" vindue, der forstår det ældre format. Splync v1.5 sender sin anmodning til et "nyt" vindue, der forstår forholdsdata. Hvis serveren lukkede det gamle vindue for tidligt, ville v1.4-brugere ikke have noget sted at "indsende" deres data. Derfor skal serveren, under en opdatering, holde begge vinduer åbne — begge endpoints — indtil hver bruger sikkert er flyttet til den nyere version. Ærligt talt, at administrere disse to vinduer samtidig føltes som at tænke i en ekstra dimension.

Splync v1.5 kan tilpasse fordelinger pr. projekt og kategori, men endnu ikke pr. udgift. For at understøtte forhold pr. udgift har vi brug for et andet strukturelt lag — i bund og grund en dybere omskrivning af, hvordan hver udgift gemmer og beregner sine andele. Vi skal også være forsigtige med ikke at gøre appens grænseflade pludselig kompliceret bare for at tilføje mere kraft. Det er en større opgradering, end det lyder. Giv os venligst lidt mere tid til at nå dertil. Det er på vores horisont — og vi når det. Indtil da, lad os udforske, hvordan de nye forhold pr. projekt og kategori allerede gør fælles udgifter meget mere fleksible.