Splync v1.5 — Tilpassbare fordelingsnøkler per prosjekt og kategori

Den 16. september 2025 ble Splync v1.5 lansert — bare fire dager etter at vårt internasjonale ekteskap endelig ble godkjent av byen. Inntil denne oppdateringen kunne ikke Splync tilpasse fordelingsnøkler i det hele tatt; alle utgifter ble delt likt som standard. Med v1.5 kan brukere nå sette tilpassede nøkler både per prosjekt og per kategori. Denne endringen lar par og venner dele sine felles kostnader på måter som bedre reflekterer deres virkelige liv, ikke bare en enkel 50:50. Du kan starte et nytt regnskapsprosjekt med en 60:40 fordeling for daglige utgifter fra oktober, mens du holder husleien i leiligheten på en jevn 50:50 hvis det føles rettferdig for dere begge. Og hvis dagligvarer føles mer balansert på 70:30 mens strømregninger føles bedre på 62:38, kan du nå tilordne disse nøklene separat — kategori for kategori — innen det samme prosjektet.

Den mest synlige endringen i v1.5 er den nye seksjonen for medlem- og standardandeler, hvor du kan legge til prosjektmedlemmer og tildele hver person en standardandel. Hvis et prosjekt har to medlemmer, kan fordelingen være 50:50, 40:60, eller hva som føles riktig. Med tre medlemmer kan det være 33,33:33,33:33,34, 50:25:25, eller hvilken som helst kombinasjon du foretrekker. Dette blir prosjektets standardfordeling. Under det kan du bla nedover for å justere hver kategoris andel hvis du vil at den skal avvike fra prosjektets standard. Når du tildeler en tilpasset nøkkel til en kategori, endres dens blå nøkkelmarkør til oransje — en liten visuell indikasjon på at kategorien bruker sin egen regel i stedet for prosjektets. Selv om denne endringen gir mye mer fleksibilitet til prosjektinnstillingene, gjør den også opprett-/rediger-prosjektvisningen litt mer kompleks. For å hjelpe med dette la jeg til informasjonsknapper i hver seksjon slik at du kan trykke på dem for å se små Q&A-hjelpere.

Å implementere denne endringen var mer komplisert enn jeg forventet. Splync hadde alltid antatt en enkel 50:50-verden — ett tall, brukt overalt, og matematikken var gjort. Når jeg bestemte meg for å støtte tilpassede nøkler, måtte hele den interne strukturen revurderes. Et prosjekt kunne ikke lenger stole på en enkelt delt prosentandel. Hver kategori trengte sin egen nøkkel, og hver utgift måtte referere både til prosjektets standard og kategorienes overstyringer. For å få dette til å fungere, omskrev jeg beregningslogikken fra bunnen av. Hver utgift har nå et lite beslutningstre: “Har denne kategorien sin egen nøkkel? Hvis ja, bruk den. Hvis ikke, bruk prosjektets nøkkel.” Det høres enkelt ut når man forklarer det, men å holde datamodellen konsistent i hele appen — iOS-visninger, FastAPI-backend, og MariaDB-skjemaer — krevde mer omhyggelig justering enn jeg forventet.

Enhver oppdatering som berører serversiden må håndteres med ekstrem forsiktighet. Hvis du ved et uhell endrer eksisterende serverkode, vil brukere som fortsatt er på v1.4 umiddelbart støte på feil eller systemproblemer. For eksempel forventer serverprogrammet for v1.5 at prosjektinnstillinger inkluderer nøkkelinformasjon, men v1.4-appen sender prosjektinnstillinger uten noen nøkler i det hele tatt. I det øyeblikket disse to versjonene prøver å kommunisere, mislykkes forespørselen — rett og slett fordi de snakker litt forskjellige “språk.” Utviklere kan selvfølgelig gjøre endringer trygt i et testmiljø. Det vanskelige begynner etter innlevering av en ny versjon for Apples gjennomgang mens eksisterende brukere fortsatt er på v1.4. I hele perioden fra innlevering til lansering må serveren støtte begge versjoner samtidig slik at Apple-gjennomgangere kan teste v1.5 og eksisterende brukere kan fortsette å bruke v1.4 uten avbrudd.

I apputvikling er et “endepunkt” ganske enkelt stedet hvor appen sender sine forespørsler på serveren — litt som en spesifikk skranke på et rådhus. Én skranke håndterer ekteskapsregistreringer, en annen håndterer beboeroppføringer, og en annen håndterer pass. Apper fungerer på samme måte: hvert endepunkt er et dedikert vindu hvor serveren aksepterer en spesifikk type forespørsel som innlogging, prosjektopprettelse, utgiftsredigering, vennforespørsel, etc. Når Splync v1.4 sender en forespørsel, går den til det “gamle” vinduet som forstår det eldre formatet. Splync v1.5 sender sin forespørsel til et “nytt” vindu som forstår nøkkelinformasjon. Hvis serveren stengte det gamle vinduet for tidlig, ville v1.4-brukere ikke ha noe sted å “sende” sine data. Derfor må serveren under en oppdatering holde begge vinduene åpne — begge endepunktene — inntil alle brukere har trygt flyttet til den nyere versjonen. Å være ærlig, å håndtere disse to vinduene samtidig føltes som å tenke i en ekstra dimensjon.

Splync v1.5 kan tilpasse fordelinger per prosjekt og per kategori, men foreløpig ikke per utgift. For å støtte forhold per utgift, trenger vi et annet strukturelt lag — egentlig en dypere omskrivning av hvordan hver utgift lagrer og beregner sine andeler. Vi må også være forsiktige med ikke å gjøre grensesnittet til appen plutselig komplisert bare for å tilføre mer kraft. Det er en større oppgradering enn det høres ut. Vennligst gi oss litt mer tid til å komme dit. Det er på vår horisont — og vi vil nå det. I mellomtiden, la oss utforske hvordan de nye per-prosjekt og per-kategori nøklene allerede gjør felles utgifter mye mer fleksible.