Splync v1.5 — Aangepaste Verhoudingen per Project en Categorie

Op 16 september 2025 werd Splync v1.5 uitgebracht — slechts vier dagen nadat ons internationale huwelijk eindelijk door de stad werd geaccepteerd. Tot deze update kon Splync geen verhoudingen aanpassen; elke uitgave werd standaard gelijk verdeeld. Met v1.5 kunnen gebruikers nu aangepaste verhoudingen instellen, zowel per project als per categorie. Deze verandering stelt stellen en vrienden in staat om hun gedeelde kosten te verdelen op een manier die beter hun echte leven weerspiegelt, niet slechts een simpele 50:50 verdeling. Je kunt vanaf oktober een nieuw boekhoudproject starten met een 60:40 verdeling voor dagelijkse uitgaven, terwijl je je appartementshuur op een eerlijke 50:50 houdt als dat voor jullie eerlijk voelt. En als boodschappen beter in balans zijn bij 70:30 terwijl nutsvoorzieningen beter voelen bij 62:38, kun je die verhoudingen nu apart toewijzen — categorie per categorie — binnen hetzelfde project.

De meest zichtbare verandering in v1.5 is de nieuwe sectie Leden & Standaard Aandelen, waar je projectleden kunt toevoegen en elk persoon een standaard aandeel kunt toewijzen. Als een project twee leden heeft, kan de verhouding 50:50, 40:60, of wat goed voelt zijn. Met drie leden kan het 33.33:33.33:33.34, 50:25:25, of elke gewenste combinatie zijn. Dit wordt de standaardverdeling van het project. Daaronder kun je naar beneden scrollen om het aandeel van elke categorie aan te passen als je dit wilt laten afwijken van de standaard van het project. Wanneer je een aangepaste verhouding aan een categorie toewijst, verandert het blauwe verhoudingsmarkering in oranje — een kleine visuele hint dat de categorie zijn eigen regel gebruikt in plaats van de projectbrede. Hoewel deze wijziging veel meer flexibiliteit toevoegt aan projectinstellingen, maakt het de weergave voor het maken/bewerken van projecten ook iets complexer. Om hierbij te helpen, heb ik informatienoppen toegevoegd aan elke sectie zodat je erop kunt tikken om kleine Q&A-hulpmiddelen te zien.

Het implementeren van deze verandering was complexer dan ik had verwacht. Splync ging altijd uit van een heldere 50:50 wereld — één nummer, overal toegepast, en de berekening was klaar. Toen ik besloot aangepaste verhoudingen te ondersteunen, moest de hele interne structuur worden herzien. Een project kon niet langer op een enkel gedeeld percentage vertrouwen. Elke categorie had zijn eigen verhouding nodig, en elke uitgave moest zowel de standaard van het project als de categorie-specifieke aanpassing refereren. Om dit te laten werken, heb ik de berekeningslogica vanaf de basis herschreven. Elke uitgave heeft nu een kleine beslisboom: “Heeft deze categorie zijn eigen verhouding? Zo ja, gebruik die. Zo niet, val terug op de projectverhouding.” Het klinkt eenvoudig als je het uitlegt, maar het consistent houden van het datamodel in de app — iOS-weergaven, FastAPI-backend en MariaDB-schema's — vereiste meer zorgvuldige afstemming dan ik had verwacht.

Elke update die de serverkant raakt, moet met uiterste zorg worden behandeld. Als je per ongeluk bestaande servercode wijzigt, krijgen gebruikers die nog op v1.4 zitten onmiddellijk bugs of systeemfouten. Bijvoorbeeld, het serverprogramma voor v1.5 verwacht dat projectinstellingen verhoudingsgegevens bevatten, maar de v1.4 app stuurt projectinstellingen zonder enige verhoudingen. Op het moment dat die twee versies proberen te communiceren, mislukt het verzoek — simpelweg omdat ze net iets andere 'talen' spreken. Ontwikkelaars kunnen uiteraard veilig wijzigingen aanbrengen in een testomgeving. Het lastige deel begint na het indienen van een nieuwe versie voor Apple’s beoordeling terwijl bestaande gebruikers nog op v1.4 zitten. Gedurende de hele periode van indiening tot release moet de server beide versies tegelijkertijd ondersteunen zodat Apple- beoordelaars v1.5 kunnen testen en bestaande gebruikers v1.4 zonder onderbrekingen kunnen blijven gebruiken.

In app-ontwikkeling is een “eindpunt” gewoon de plek waar de app zijn verzoeken op de server indient — een beetje zoals een specifieke balie bij het stadhuis. Eén balie handelt huwelijksregistraties af, een andere behandelt inwonersregistraties, en weer een andere paspoorten. Apps werken op dezelfde manier: elk eindpunt is een toegewijd loket waar de server een specifiek type verzoek accepteert, zoals inloggen, projectcreatie, uitgaven bewerken, vriendschapsverzoek, etc. Wanneer Splync v1.4 een verzoek verstuurt, gaat het naar het “oude” loket dat het oudere formaat begrijpt. Splync v1.5 stuurt zijn verzoek naar een “nieuw” loket dat verhoudingsgegevens begrijpt. Als de server het oude loket te vroeg sluit, zouden v1.4-gebruikers nergens hun gegevens kunnen “indienen”. Daarom moet de server tijdens een update beide loketten openhouden — beide eindpunten — totdat elke gebruiker veilig is overgestapt naar de nieuwe versie. Om eerlijk te zijn, het beheren van deze twee loketten tegelijkertijd voelde als denken in een extra dimensie.

Splync v1.5 kan verdelingen aanpassen per project en per categorie, maar nog niet per uitgave. Om verhoudingen per uitgave te ondersteunen, hebben we een andere structurele laag nodig — in wezen een diepere herschrijving van hoe elke uitgave zijn aandelen opslaat en berekent. We moeten er ook voor zorgen dat de interface van de app niet ineens gecompliceerd wordt, alleen maar om meer kracht toe te voegen. Het is een grotere upgrade dan het lijkt. Geef ons alsjeblieft nog wat tijd om daar te komen. Het is op onze horizon — en we zullen het bereiken. Tot dan, laten we verkennen hoe de nieuwe per-project en per-categorie verhoudingen gedeelde uitgaven al veel flexibeler maken.