Splync v1.5 — настроювані коефіцієнти розподілу за проєктом і категорією

16 вересня 2025 року вийшло Splync v1.5 — лише через чотири дні після того, як наше міжнародне одруження нарешті було визнано містом. До цього оновлення Splync не міг налаштовувати коефіцієнти розподілу; всі витрати ділилися порівну за замовчуванням. З v1.5 користувачі можуть встановлювати власні коефіцієнти як для проєктів, так і для категорій. Це дає змогу парам і друзям ділити витрати так, щоб це краще відображало їхнє реальне життя, а не просто 50:50. Ви можете почати новий проєкт з 60:40 для щоденних витрат з жовтня, зберігаючи оплату оренди квартири порівну, якщо це справедливо для вас обох. І якщо продукти харчування краще розподіляти 70:30, а комунальні послуги — 62:38, ви тепер можете призначати ці коефіцієнти окремо — категорія за категорією — в рамках одного проєкту.

Найпомітніша зміна в v1.5 — новий розділ «Учасники та частки за замовчуванням», де ви можете додати учасників проєкту та призначити кожному частку за замовчуванням. Якщо в проєкті двоє учасників, коефіцієнт може бути 50:50, 40:60 або будь-який інший. З трьома учасниками це може бути 33.33:33.33:33.34, 50:25:25 або будь-яка інша комбінація. Це стає загальним коефіцієнтом проєкту. Нижче ви можете прокрутити, щоб відрегулювати частку кожної категорії, якщо хочете, щоб вона відрізнялася від загальної. Коли ви призначаєте власний коефіцієнт категорії, її синя позначка коефіцієнта стає помаранчевою — невелика візуальна підказка, що категорія використовує власне правило, а не загально проєктне. Хоча це додає більше гнучкості налаштуванням проєкту, також ускладнює перегляд створення/редагування проєкту. Щоб допомогти, я додав інформаційні кнопки до кожного розділу, щоб ви могли торкнутися їх і побачити невеликі підказки Q&A.

Реалізація цієї зміни виявилася складнішою, ніж я очікував. Splync завжди припускав чистий світ 50:50 — одне число, застосоване всюди, і математика завершена. Після того, як я вирішив підтримувати власні коефіцієнти, внутрішню структуру довелося переосмислити. Проєкт більше не міг покладатися на один спільний відсоток. Кожна категорія потребувала власного коефіцієнта, і кожна витрата мала відсилатися як до загального, так і до категорійного. Щоб це працювало, я переписав логіку обчислень з основи. Кожна витрата тепер має невелике дерево рішень: «Чи має ця категорія власний коефіцієнт? Якщо так, використовуйте його. Якщо ні, поверніться до загального коефіцієнта проєкту». Це звучить просто, коли ви це пояснюєте, але підтримання відповідності моделі даних у додатку — в iOS, на бекенді FastAPI і в схемах MariaDB — вимагало більше налаштувань, ніж я очікував.

Будь-яке оновлення, яке стосується серверної сторони, має виконуватися з надзвичайною обережністю. Якщо випадково змінити існуючий код сервера, користувачі, які все ще використовують v1.4, одразу зіткнуться з багами або системними помилками. Наприклад, серверна програма для v1.5 очікує, що налаштування проєкту міститимуть дані коефіцієнтів, але додаток v1.4 відправляє налаштування без жодних коефіцієнтів. У той момент, коли ці дві версії намагаються спілкуватися, запит не вдається — просто тому, що вони говорять трохи різними «мовами». Розробники можуть, звичайно, безпечно вносити зміни в тестовому середовищі. Проблеми починаються після надсилання нової версії на огляд Apple, тоді як існуючі користувачі все ще використовують v1.4. Протягом усього періоду від подачі до випуску сервер має підтримувати обидві версії одночасно, щоб рецензенти Apple могли протестувати v1.5, а існуючі користувачі могли продовжувати використовувати v1.4 без перешкод.

У розробці додатків «кінцева точка» — це місце, де додаток надсилає свої запити на сервер — трохи схоже на конкретну стійку в міській адміністрації. Один стіл обробляє реєстрації шлюбів, інший — записи про місце проживання, ще інший — паспорти. Додатки працюють так само: кожна кінцева точка — це спеціальне вікно, через яке сервер приймає певний тип запитів, таких як вхід, створення проєкту, редагування витрат, запит на дружбу тощо. Коли Splync v1.4 надсилає запит, він потрапляє до «старого» вікна, яке розуміє старий формат. Splync v1.5 надсилає свій запит до «нового» вікна, яке розуміє дані коефіцієнтів. Якщо сервер зачинить старе вікно занадто рано, користувачі v1.4 залишаться без можливості «подати» свої дані. Ось чому під час оновлення сервер має підтримувати обидва вікна відкритими — обидві кінцеві точки — поки кожен користувач безпечно не перейде на новішу версію. Чесно кажучи, керувати цими двома вікнами одночасно відчувалося, як думати в додатковому вимірі.

Splync v1.5 може налаштовувати поділ за проєктом та категорією, але ще не за витратами. Щоб підтримувати коефіцієнти за витратами, нам потрібен ще один структурний рівень — по суті, глибше переписування того, як кожна витрата зберігає та обчислює свої частки. Також потрібно бути обережними, щоб не зробити інтерфейс додатку раптом складним лише заради додаткової потужності. Це більше оновлення, ніж здається. Будь ласка, дайте нам трохи більше часу, щоб дістатися туди. Це на нашому горизонті — і ми досягнемо його. Поки що давайте досліджувати, як нові коефіцієнти за проєктом і категорією вже роблять розподіл витрат більш гнучким.