Splync v1.5 — Anpassningsbara delningsförhållanden per projekt och kategori

Den 16 september 2025 släpptes Splync v1.5 — bara fyra dagar efter att vårt internationella äktenskap äntligen godkändes av staden. Fram till denna uppdatering kunde Splync inte anpassa delningsförhållanden alls; varje kostnad delades lika som standard. Med v1.5 kan användare nu ställa in egna förhållanden både per projekt och per kategori. Denna förändring gör att par och vänner kan dela sina gemensamma kostnader på sätt som bättre återspeglar deras verkliga liv, inte bara en enkel 50:50. Du kan starta ett nytt bokföringsprojekt med en 60:40-fördelning för dagliga utgifter från oktober, samtidigt som du håller din hyran för lägenheten jämn 50:50 om det känns rättvist för er båda. Och om matinköp känns mer balanserade vid 70:30 medan elräkningen känns bättre vid 62:38, kan du nu tilldela dessa förhållanden separat — kategori för kategori — inom samma projekt.

Den mest synliga förändringen i v1.5 är den nya sektionen Medlem & Standardandelar, där du kan lägga till projektmedlemmar och tilldela varje person en standardandel. Om ett projekt har två medlemmar kan förhållandet vara 50:50, 40:60 eller vad som känns rätt. Med tre medlemmar kan det vara 33,33:33,33:33,34, 50:25:25 eller vilken kombination du föredrar. Detta blir projektets standardfördelning. Under detta kan du bläddra ner för att justera varje kategoris andel om du vill att den ska skilja sig från projektets standard. När du tilldelar ett anpassat förhållande till en kategori, ändras dess blå förhållandemarkering till orange — en liten visuell ledtråd att kategorin använder sin egen regel istället för den projektomfattande. Även om denna förändring ger mycket mer flexibilitet till projektinställningarna, gör den också skapa/redigera projektvy något mer komplex. För att hjälpa med detta har jag lagt till informationsknappar i varje sektion så att du kan trycka på dem för att se små frågor och svar.

Det var mer komplicerat än jag trodde att genomföra denna förändring. Splync hade alltid antagit en ren 50:50 värld — ett nummer, tillämpat överallt, och matematiken var klar. När jag bestämde mig för att stödja anpassade förhållanden, måste hela den interna strukturen omvärderas. Ett projekt kunde inte längre förlita sig på en enda delad procentsats. Varje kategori behövde sitt eget förhållande, och varje kostnad måste hänvisa både till projektets standard och kategorins anpassning. För att få detta att fungera, skrev jag om beräkningslogiken från grunden. Varje kostnad bär nu ett litet beslutsträd: "Har denna kategori sitt eget förhållande? Om ja, använd det. Om inte, använd projektförhållandet." Det låter enkelt när du förklarar det, men att hålla datamodellen konsekvent över hela appen — iOS-vyer, FastAPI backend och MariaDB-scheman — krävde mer noggrann justering än jag förväntade mig.

Varje uppdatering som rör serversidan måste hanteras med extrem försiktighet. Om du av misstag ändrar befintlig serverkod, kommer användare som fortfarande använder v1.4 omedelbart att stöta på buggar eller systemfel. Till exempel förväntar sig serverprogrammet för v1.5 att projektinställningarna ska inkludera förhållandedata, men v1.4-appen skickar projektinställningar utan några förhållanden alls. När dessa två versioner försöker kommunicera misslyckas begäran — bara för att de talar lite olika "språk". Utvecklare kan naturligtvis göra ändringar säkert i en testmiljö. Den svåra delen börjar efter att ha skickat in en ny version för Apples granskning medan befintliga användare fortfarande är på v1.4. Under hela perioden från inskickning till lansering måste servern stödja båda versionerna samtidigt så att Apple-recensenter kan testa v1.5 och befintliga användare kan fortsätta använda v1.4 utan avbrott.

Inom apputveckling är en "endpoint" helt enkelt platsen där appen skickar sina förfrågningar på servern — lite som en specifik disk på ett stadshus. En disk hanterar äktenskapsregistreringar, en annan hanterar folkbokföring och en annan hanterar pass. Appar fungerar på samma sätt: varje endpoint är ett dedikerat fönster där servern accepterar en specifik typ av förfrågan som inloggning, projekt skapande, kostnadsredigering, vänförfrågan etc. När Splync v1.4 skickar en förfrågan går det till det "gamla" fönstret som förstår det äldre formatet. Splync v1.5 skickar sin förfrågan till ett "nytt" fönster som förstår förhållandedata. Om servern stänger det gamla fönstret för tidigt, skulle v1.4-användare inte ha någonstans att "lämna in" sina data. Därför måste servern under en uppdatering hålla båda fönstren öppna — båda endpoints — tills alla användare säkert har gått över till den nyare versionen. För att vara ärlig, att hantera dessa två fönster samtidigt kändes som att tänka i en extra dimension.

Splync v1.5 kan anpassa delningar per projekt och per kategori, men ännu inte per kostnad. För att stödja delningsförhållanden per kostnad behöver vi ytterligare ett strukturellt lager — i grunden en djupare omskrivning av hur varje kostnad lagrar och beräknar sina andelar. Vi måste också vara försiktiga så att vi inte gör appens gränssnitt plötsligt komplicerat bara för att lägga till mer kraft. Det är en större uppgradering än det låter. Ge oss gärna lite mer tid att nå dit. Det är på vår horisont — och vi kommer att nå det. Fram till dess, låt oss utforska hur de nya förhållandena per projekt och per kategori redan gör delade kostnader mycket mer flexibla.