Splync v1.5 — Customizable Split Ratios per Project and Category

On September 16, 2025, Splync v1.5 was released — just four days after our international marriage was finally accepted by the city. Until this update, Splync couldn’t customize split ratios at all; every expense was divided evenly by default. With v1.5, users can now set custom ratios both per project and per category. This change allows couples and friends to split their shared costs in ways that better reflect their real lives, not just a simple 50:50. You can start a new accounting project with a 60:40 split for day-to-day expenses from October, while keeping your apartment rent at an even 50:50 if that feels fair for both of you. And if groceries feel more balanced at 70:30 while utilities feel better at 62:38, you can now assign those ratios separately — category by category — within the same project.

The most visible change in v1.5 is the new Member & Default Shares section, where you can add project members and assign each person a default share. If a project has two members, the ratio could be 50:50, 40:60, or whatever feels right. With three members, it could be 33.33:33.33:33.34, 50:25:25, or any combination you prefer. This becomes the project’s default split. Below that, you can scroll down to adjust each category’s share if you want it to differ from the project’s default. When you assign a custom ratio to a category, its blue ratio mark turns orange — a small visual cue that the category is using its own rule rather than the project-wide one. While this change adds much more flexibility to project settings, it also makes the create/edit project view a bit more complex. To help with this, I added information buttons to each section so you can tap them to see small Q&A helpers.

Implementing this change was more complex than I expected. Splync had always assumed a clean 50:50 world — one number, applied everywhere, and the math was done. Once I decided to support custom ratios, the entire internal structure had to be rethought. A project could no longer rely on a single shared percentage. Each category needed its own ratio, and every expense had to reference both the project-level default and the category-level override. To make this work, I rewrote the calculation logic from the foundation. Each expense now carries a small decision tree: “Does this category have its own ratio? If yes, use that. If not, fall back to the project ratio.” It sounds simple when you explain it, but keeping the data model consistent across the app — iOS views, FastAPI backend, and MariaDB schemas — required more careful tuning than I expected.

Any update that touches the server side has to be handled with extreme care. If you accidentally modify existing server code, users still on v1.4 will immediately run into bugs or system errors. For example, the server program for v1.5 expects project settings to include ratio data, but the v1.4 app sends project settings without any ratios at all. The moment those two versions try to communicate, the request fails — simply because they speak slightly different “languages.” Developers can, of course, make changes safely in a test environment. The tricky part begins after submitting a new version for Apple’s review while existing users are still on v1.4. During the entire period from submission to release, the server must support both versions at the same time so that Apple reviewers can test v1.5 and existing users can continue using v1.4 without interruptions.

In app development, an “endpoint” is simply the place where the app sends its requests on the server — a bit like a specific counter at a city hall. One counter handles marriage registrations, another handles resident records, and another handles passports. Apps work the same way: each endpoint is a dedicated window where the server accepts a specific type of request like login, project creation, expense editing, friend request, etc. When Splync v1.4 sends a request, it goes to the “old” window that understands the older format. Splync v1.5 sends its request to a “new” window that understands ratio data. If the server closed the old window too early, v1.4 users would have nowhere to “submit” their data. That’s why, during an update, the server needs to keep both windows open — both endpoints — until every user has safely moved to the newer version. To be honest, managing these two windows at the same time felt like thinking in an extra dimension.

Splync v1.5 can customize splits per project and per category, but not yet per expense. To support per-expense ratios, we need another structural layer — essentially a deeper rewrite of how each expense stores and calculates its shares. We also have to be careful not to make the app’s interface suddenly complicated just for the sake of adding more power. It’s a bigger upgrade than it sounds. Please give us a little more time to get there. It’s on our horizon — and we’ll reach it. Until then, let’s explore how the new per-project and per-category ratios already make shared expenses much more flexible.