Splync v1.5 — Proporciones de Reparto Personalizables por Proyecto y Categoría

El 16 de septiembre de 2025, se lanzó Splync v1.5, solo cuatro días después de que nuestro matrimonio internacional fuera finalmente aceptado por la ciudad. Hasta esta actualización, Splync no podía personalizar proporciones de reparto; todos los gastos se dividían equitativamente por defecto. Con la v1.5, los usuarios ahora pueden configurar proporciones personalizadas tanto por proyecto como por categoría. Este cambio permite a parejas y amigos dividir sus costos compartidos de manera que reflejen mejor sus vidas reales, no solo un simple 50:50. Puedes iniciar un nuevo proyecto contable con un reparto 60:40 para los gastos diarios desde octubre, mientras mantienes el alquiler del apartamento en un justo 50:50 si eso parece equitativo para ambos. Y si la compra de alimentos se siente más equilibrada en 70:30 mientras que los servicios se ven mejor en 62:38, ahora puedes asignar esas proporciones por separado, categoría por categoría, dentro del mismo proyecto.

El cambio más visible en la v1.5 es la nueva sección de Miembros y Cuotas Predeterminadas, donde puedes agregar miembros al proyecto y asignar a cada persona una cuota predeterminada. Si un proyecto tiene dos miembros, la proporción podría ser 50:50, 40:60 o lo que se sienta adecuado. Con tres miembros, podría ser 33.33:33.33:33.34, 50:25:25 o cualquier combinación que prefieras. Esto se convierte en el reparto predeterminado del proyecto. Debajo de eso, puedes desplazarte para ajustar la cuota de cada categoría si deseas que difiera del predeterminado del proyecto. Cuando asignas una proporción personalizada a una categoría, su marca de proporción azul se vuelve naranja, una pequeña señal visual de que la categoría está usando su propia regla en lugar de la del proyecto. Si bien este cambio agrega mucha más flexibilidad a la configuración del proyecto, también hace que la vista de creación/edición del proyecto sea un poco más compleja. Para ayudar con esto, agregué botones de información a cada sección para que puedas tocarlos y ver pequeñas ayudas de preguntas y respuestas.

Implementar este cambio fue más complejo de lo que esperaba. Splync siempre había asumido un mundo limpio de 50:50: un solo número, aplicado en todas partes, y las cuentas estaban listas. Una vez que decidí admitir proporciones personalizadas, toda la estructura interna tuvo que ser replanteada. Un proyecto ya no podía depender de un solo porcentaje compartido. Cada categoría necesitaba su propia proporción, y cada gasto debía referirse tanto al predeterminado del proyecto como a la anulación a nivel de categoría. Para que esto funcionara, reescribí la lógica de cálculos desde la base. Cada gasto ahora lleva un pequeño árbol de decisiones: “¿Esta categoría tiene su propia proporción? Si sí, úsala. Si no, recurre a la proporción del proyecto.” Suena simple al explicarlo, pero mantener el modelo de datos consistente en toda la aplicación —vistas de iOS, backend de FastAPI y esquemas de MariaDB— requirió más ajustes cuidadosos de lo que esperaba.

Cualquier actualización que toque el lado del servidor debe manejarse con extremo cuidado. Si modificas accidentalmente el código existente del servidor, los usuarios que aún usan la v1.4 encontrarán inmediatamente errores o fallos del sistema. Por ejemplo, el programa del servidor para la v1.5 espera que la configuración del proyecto incluya datos de proporción, pero la aplicación v1.4 envía configuraciones de proyecto sin ninguna proporción. En el momento en que esas dos versiones intentan comunicarse, la solicitud falla, simplemente porque hablan “idiomas” ligeramente diferentes. Los desarrolladores pueden, por supuesto, hacer cambios de manera segura en un entorno de prueba. La parte complicada comienza después de enviar una nueva versión para la revisión de Apple mientras los usuarios existentes aún usan la v1.4. Durante todo el periodo desde el envío hasta el lanzamiento, el servidor debe soportar ambas versiones al mismo tiempo para que los revisores de Apple puedan probar la v1.5 y los usuarios existentes puedan continuar usando la v1.4 sin interrupciones.

En el desarrollo de aplicaciones, un “endpoint” es simplemente el lugar donde la aplicación envía sus solicitudes en el servidor, un poco como un mostrador específico en un ayuntamiento. Un mostrador maneja registros de matrimonio, otro maneja registros de residentes y otro maneja pasaportes. Las aplicaciones funcionan de la misma manera: cada endpoint es una ventana dedicada donde el servidor acepta un tipo específico de solicitud como inicio de sesión, creación de proyectos, edición de gastos, solicitud de amistad, etc. Cuando Splync v1.4 envía una solicitud, va a la “vieja” ventana que entiende el formato anterior. Splync v1.5 envía su solicitud a una “nueva” ventana que entiende datos de proporción. Si el servidor cierra la vieja ventana demasiado pronto, los usuarios de v1.4 no tendrían dónde “enviar” sus datos. Por eso, durante una actualización, el servidor necesita mantener ambas ventanas abiertas —ambos endpoints— hasta que todos los usuarios se hayan movido de forma segura a la versión más nueva. Para ser honesto, gestionar estas dos ventanas al mismo tiempo se sintió como pensar en una dimensión extra.

Splync v1.5 puede personalizar divisiones por proyecto y por categoría, pero aún no por gasto. Para admitir proporciones por gasto, necesitamos otra capa estructural, esencialmente una reescritura más profunda de cómo cada gasto almacena y calcula sus partes. También debemos tener cuidado de no complicar la interfaz de la aplicación solo por agregar más funciones. Es una actualización más grande de lo que parece. Por favor, danos un poco más de tiempo para lograrlo. Está en nuestro horizonte y llegaremos a ello. Hasta entonces, exploremos cómo las nuevas proporciones por proyecto y por categoría ya hacen que los gastos compartidos sean mucho más flexibles.