Splync v1.5 — Taxas 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 personalizava taxas de divisão; cada despesa era dividida igualmente por padrão. Com a v1.5, os usuários agora podem definir taxas personalizadas tanto por projeto quanto por categoria. Essa mudança permite que casais e amigos dividam seus custos compartilhados de maneira que reflita melhor suas vidas reais, não apenas uma simples divisão 50:50. Você pode começar um novo projeto de contabilidade com uma divisão de 60:40 para despesas do dia a dia a partir de outubro, enquanto mantém o aluguel do apartamento em 50:50 se isso parecer justo para vocês. E se as compras de supermercado ficarem mais equilibradas em 70:30 enquanto as contas de serviços públicos se ajustam melhor em 62:38, agora você pode atribuir essas taxas separadamente — categoria por categoria — dentro do mesmo projeto.

A mudança mais visível na v1.5 é a nova seção de Membros & Partilhas Padrão, onde você pode adicionar membros do projeto e atribuir a cada pessoa uma participação padrão. Se um projeto tem dois membros, a proporção pode ser 50:50, 40:60, ou como acharem melhor. 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 ajustar a participação de cada categoria se quiser que ela difira do padrão do projeto. Quando você atribui uma taxa personalizada a uma categoria, sua marca de proporção azul fica laranja — uma pequena dica visual de que a categoria está usando sua própria regra em vez da do projeto. Embora essa mudança adicione muito mais flexibilidade às configurações do projeto, também torna a visualização de criar/editar projeto um pouco mais complexa. Para ajudar nisso, adicionei botões de informação em cada seção para que você possa tocá-los e ver pequenos auxílios de perguntas e respostas.

Implementar essa mudança foi mais complexo do que eu esperava. O Splync sempre presumiu um mundo limpo de 50:50 — um número, aplicado em toda parte, e a matemática estava feita. Quando decidi apoiar taxas personalizadas, toda a estrutura interna teve que ser repensada. Um projeto não poderia mais depender de uma única porcentagem compartilhada. Cada categoria precisava de sua própria taxa, e cada despesa tinha que se referir tanto ao padrão do projeto quanto à substituição da categoria. Para fazer isso funcionar, reescrevi a lógica de cálculo desde a base. Cada despesa agora carrega uma pequena árvore de decisões: "Esta categoria tem sua própria taxa? Se sim, use-a. Se não, use a taxa do projeto." Parece simples quando explicamos, mas manter o modelo de dados consistente em todo o aplicativo — visualizações do iOS, backend do FastAPI e esquemas do MariaDB — exigiu mais ajustes cuidadosos do que eu esperava.

Qualquer atualização que toque o 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 terão imediatamente problemas ou erros no sistema. Por exemplo, o programa do servidor para v1.5 espera que as configurações do projeto incluam dados de taxa, mas o aplicativo v1.4 envia configurações de projeto sem qualquer taxa. 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 a avaliação da Apple, enquanto usuários existentes ainda estão na v1.4. Durante todo o período de submissão até o 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 aplicativos, um "endpoint" é simplesmente o local onde o aplicativo envia suas solicitações no servidor — um pouco como um balcão específico em um cartório. Um balcão lida com registros de casamento, outro com registros de residentes e outro com passaportes. Os aplicativos funcionam da mesma forma: 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 despesas, 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 taxa. Se o servidor fechasse a janela antiga cedo demais, os usuários da v1.4 não teriam onde "submeter" seus dados. Por isso, durante uma atualização, o servidor precisa manter ambas as janelas abertas — ambos os endpoints — até que todos os usuários tenham migrado 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 oferecer suporte às taxas por despesa, precisamos de outra camada estrutural — essencialmente uma reescrita mais profunda de como cada despesa armazena e calcula suas partes. Também precisamos ter cuidado para não complicar repentinamente a interface do aplicativo apenas por adicionar mais poder. É uma atualização maior do que parece. Por favor, nos dê um pouco mais de tempo para chegar lá. Está em nosso horizonte — e vamos alcançá-lo. Até lá, vamos explorar como as novas taxas por projeto e por categoria já tornam as despesas compartilhadas muito mais flexíveis.