Splync v1.5 — Konfigurowalne proporcje podziału na projekt i kategorię

16 września 2025 roku wydano Splync v1.5 — zaledwie cztery dni po tym, jak nasze międzynarodowe małżeństwo zostało w końcu zaakceptowane przez miasto. Do tego momentu Splync nie umożliwiało w ogóle konfigurowania proporcji podziału; każdy wydatek był dzielony równo domyślnie. Dzięki v1.5 użytkownicy mogą teraz ustawiać niestandardowe proporcje zarówno dla projektów, jak i kategorii. Ta zmiana pozwala parom i przyjaciołom dzielić wspólne koszty w sposób, który lepiej odzwierciedla ich rzeczywiste życie, a nie tylko prosty podział 50:50. Możesz rozpocząć nowy projekt księgowy z podziałem 60:40 na codzienne wydatki od października, zachowując równy 50:50 na czynsz za mieszkanie, jeśli to wydaje się sprawiedliwe dla obu stron. A jeśli zakupy wydają się bardziej zrównoważone w proporcji 70:30, a media w 62:38, teraz możesz przypisać te proporcje osobno — kategoria po kategorii — w ramach tego samego projektu.

Najbardziej widoczną zmianą w v1.5 jest nowa sekcja Członkowie & Domyślne Udziały, w której można dodawać członków projektu i przypisywać każdej osobie domyślny udział. Jeśli projekt ma dwóch członków, proporcja może wynosić 50:50, 40:60 lub jakakolwiek inna, która wydaje się odpowiednia. W przypadku trzech członków, może to być 33.33:33.33:33.34, 50:25:25 lub dowolna inna kombinacja. To staje się domyślnym podziałem projektu. Poniżej możesz przewinąć, aby dostosować udział każdej kategorii, jeśli chcesz, aby różnił się od domyślnego projektu. Kiedy przypisujesz niestandardową proporcję do kategorii, jej niebieski znacznik proporcji zmienia się na pomarańczowy — mały wizualny sygnał, że kategoria używa własnej zasady zamiast ogólnej projektu. Choć ta zmiana dodaje więcej elastyczności do ustawień projektu, czyni również widok tworzenia/edycji projektu nieco bardziej skomplikowanym. Aby to ułatwić, dodałem przyciski informacyjne do każdej sekcji, aby można było je kliknąć i zobaczyć małe pomocniki Q&A.

Wdrożenie tej zmiany było bardziej skomplikowane, niż się spodziewałem. Splync zawsze zakładało czysty świat 50:50 — jedna liczba, stosowana wszędzie, i matematyka była załatwiona. Kiedy zdecydowałem się wesprzeć niestandardowe proporcje, cała wewnętrzna struktura musiała zostać przemyślana. Projekt nie mógł już opierać się na jednym wspólnym procencie. Każda kategoria potrzebowała własnej proporcji, a każdy wydatek musiał odnosić się zarówno do domyślnego poziomu projektowego, jak i nadrzędnych proporcji kategorii. Aby to działało, przepisałem logikę obliczeń od podstaw. Każdy wydatek teraz zawiera małe drzewo decyzji: „Czy ta kategoria ma własną proporcję? Jeśli tak, użyj jej. Jeśli nie, wróć do proporcji projektu.” Brzmi to prosto, gdy się to wyjaśnia, ale utrzymanie spójnego modelu danych w całej aplikacji — widoki iOS, backend FastAPI, i schematy MariaDB — wymagało więcej starannej regulacji, niż się spodziewałem.

Każda aktualizacja, która dotyka strony serwera, musi być przeprowadzana z najwyższą ostrożnością. Jeśli przypadkowo zmodyfikujesz istniejący kod serwera, użytkownicy wciąż korzystający z v1.4 natychmiast napotkają błędy lub problemy systemowe. Na przykład, program serwera dla v1.5 oczekuje, że ustawienia projektu będą zawierały dane o proporcjach, ale aplikacja v1.4 wysyła ustawienia projektu bez żadnych proporcji. W momencie, gdy te dwie wersje próbują się komunikować, żądanie zawodzi — po prostu dlatego, że „mówią” nieco innymi „językami”. Programiści mogą oczywiście wprowadzać zmiany bezpiecznie w środowisku testowym. Trudności zaczynają się po złożeniu nowej wersji do recenzji przez Apple, gdy istniejący użytkownicy wciąż korzystają z v1.4. Przez cały okres od zgłoszenia do wydania, serwer musi obsługiwać obie wersje jednocześnie, aby recenzenci Apple mogli testować v1.5, a obecni użytkownicy mogli nadal korzystać z v1.4 bez przerw.

W rozwoju aplikacji „endpoint” to po prostu miejsce, gdzie aplikacja wysyła swoje żądania na serwerze — trochę jak określone okienko w urzędzie miasta. Jedno okienko obsługuje rejestracje małżeństw, inne rekordy mieszkańców, a jeszcze inne paszporty. Aplikacje działają podobnie: każdy endpoint to dedykowane okno, w którym serwer akceptuje określony typ żądania, jak logowanie, tworzenie projektów, edycja wydatków, zaproszenia znajomych itd. Kiedy Splync v1.4 wysyła żądanie, trafia do „starego” okna, które rozumie starszy format. Splync v1.5 wysyła swoje żądanie do „nowego” okna, które rozumie dane o proporcjach. Jeśli serwer zamknąłby stare okno zbyt wcześnie, użytkownicy v1.4 nie mieliby gdzie „składać” swoich danych. Dlatego podczas aktualizacji serwer musi mieć otwarte oba okna — oba endpointy — aż wszyscy użytkownicy bezpiecznie przejdą na nowszą wersję. Szczerze mówiąc, zarządzanie tymi dwoma oknami jednocześnie wydawało się jak myślenie w dodatkowym wymiarze.

Splync v1.5 pozwala na konfigurowanie podziałów na projekt i kategorię, ale jeszcze nie na wydatek. Aby obsługiwać proporcje na wydatek, potrzebujemy kolejnej warstwy strukturalnej — zasadniczo głębszego przepisania sposobu, w jaki każdy wydatek przechowuje i oblicza swoje udziały. Musimy także uważać, aby nie skomplikować interfejsu aplikacji tylko po to, by dodać więcej funkcjonalności. To większa aktualizacja, niż się wydaje. Proszę, dajcie nam trochę więcej czasu, aby to osiągnąć. To już na naszym horyzoncie — i osiągniemy to. Do tego czasu, przyjrzyjmy się, jak nowe proporcje na projekt i kategorię już czynią wspólne wydatki znacznie bardziej elastycznymi.