Splync v1.5 — Razões de Divisão Personalizáveis por Projeto e Categoria

Em 16 de setembro de 2025, o Splync v1.5 foi lançado — apenas quatro dias após nosso casamento internacional ser finalmente aceito pela cidade. Até essa atualização, o Splync não podia personalizar razões de divisão; toda despesa era dividida igualmente por padrão. Com a v1.5, os usuários agora podem definir razões personalizadas tanto por projeto quanto por categoria. Essa mudança permite que casais e amigos dividam seus custos compartilhados de maneiras que reflitam melhor suas vidas reais, não apenas um simples 50:50. Você pode iniciar um novo projeto contábil com uma divisão de 60:40 para despesas do dia a dia a partir de outubro, enquanto mantém o aluguel de seu apartamento em um equilíbrio de 50:50 se isso parecer justo para vocês dois. E se as compras parecerem mais equilibradas em 70:30 enquanto as contas de serviços públicos ficarem melhores em 62:38, agora você pode atribuir essas razões separadamente — categoria por categoria — dentro do mesmo projeto.

A mudança mais visível na v1.5 é a nova seção Membros e Participações Padrão, onde você pode adicionar membros do projeto e atribuir a cada pessoa uma participação padrão. Se um projeto tiver dois membros, a divisão pode ser 50:50, 40:60, ou o que parecer certo. Com três membros, pode ser 33.33:33.33:33.34, 50:25:25, ou qualquer combinação que você preferir. Isso se torna a divisão padrão do projeto. Abaixo disso, você pode rolar para ajustar a divisão de cada categoria se quiser que ela seja diferente do padrão do projeto. Quando você atribui uma razão personalizada a uma categoria, seu marcador azul de razão fica laranja — uma pequena dica visual de que a categoria está usando sua própria regra em vez da regra geral do projeto. Embora essa mudança traga muito mais flexibilidade às configurações do projeto, ela também torna a visualização de criação/edição do projeto um pouco mais complexa. Para ajudar com isso, adicionei botões de informação a cada seção, para que você possa tocá-los para ver pequenas ajudas de perguntas e respostas.

Implementar essa mudança foi mais complexo do que eu esperava. O Splync sempre assumiu um mundo limpo de 50:50 — um número aplicado em todos os lugares, e pronto, a matemática era feita. Quando decidi suportar razões personalizadas, toda a estrutura interna teve que ser repensada. Um projeto não podia mais depender de uma única porcentagem compartilhada. Cada categoria precisava de sua própria razão, e cada despesa tinha que referenciar tanto o padrão de nível de projeto quanto a substituição de nível de categoria. Para fazer isso funcionar, reescrevi a lógica de cálculo desde a base. Cada despesa agora carrega uma pequena árvore de decisão: “Esta categoria tem sua própria razão? Se sim, use-a. Se não, volte para a razão do projeto.” Parece simples ao explicar, mas manter o modelo de dados consistente em todo o aplicativo — visualizações iOS, backend FastAPI e esquemas MariaDB — exigiu um ajuste mais cuidadoso do que eu esperava.

Qualquer atualização que toque no lado do servidor deve ser tratada com extremo cuidado. Se você modificar acidentalmente o código do servidor existente, usuários que ainda estão na v1.4 vão enfrentar imediatamente bugs ou erros do sistema. Por exemplo, o programa do servidor para a v1.5 espera que as configurações do projeto incluam dados de razões, mas o app v1.4 envia configurações de projeto sem quaisquer razões. No momento em que essas duas versões tentam se comunicar, a solicitação falha — simplesmente porque falam “línguas” ligeiramente diferentes. Os desenvolvedores podem, claro, fazer alterações com segurança em um ambiente de teste. A parte complicada começa após enviar uma nova versão para revisão da Apple, enquanto os usuários existentes ainda estão na v1.4. Durante todo o período de submissão ao lançamento, o servidor deve suportar ambas as versões ao mesmo tempo para que os revisores da Apple possam testar a v1.5 e os usuários existentes possam continuar usando a v1.4 sem interrupções.

No desenvolvimento de apps, um “endpoint” é simplesmente o local onde o app envia suas solicitações no servidor — um pouco como um balcão específico em uma prefeitura. Um balcão cuida de registros de casamento, outro de registros de residentes, e outro de passaportes. Os apps funcionam da mesma maneira: cada endpoint é uma janela dedicada onde o servidor aceita um tipo específico de solicitação como login, criação de projeto, edição de despesa, solicitação de amizade, etc. Quando o Splync v1.4 envia uma solicitação, ela vai para a “janela antiga” que entende o formato mais antigo. O Splync v1.5 envia sua solicitação para uma “nova janela” que entende dados de razões. Se o servidor fechasse a janela antiga muito cedo, os usuários da v1.4 não teriam onde “enviar” seus dados. É por isso que, durante uma atualização, o servidor precisa manter ambas as janelas abertas — ambos os endpoints — até que todos os usuários tenham se movido com segurança para a versão mais recente. Para ser honesto, gerenciar essas duas janelas ao mesmo tempo parecia pensar em uma dimensão extra.

O Splync v1.5 pode personalizar divisões por projeto e por categoria, mas ainda não por despesa. Para suportar razões por despesa, precisamos de outra camada estrutural — essencialmente, uma reescrita mais profunda de como cada despesa armazena e calcula suas participações. Também temos que ter cuidado para não complicar a interface do aplicativo apenas por adicionar mais recursos. É uma atualização maior do que parece. Por favor, nos dê um pouco mais de tempo para chegarmos lá. Está em nosso horizonte — e vamos alcançá-lo. Até lá, vamos explorar como as novas razões por projeto e por categoria já tornam as despesas compartilhadas muito mais flexíveis.