The goal is simple: make it impossible to ship a client that has drifted from your API.

I built Kizuna for the products and projects our team ships. Every change to the API meant editing the same shapes in several places, and sooner or later you miss one. It drifts until something breaks in front of a user.

On Swift that happened to us more than once, where one renamed field or one new enum value fails the whole decode, and a client that does not handle that failure crashes.

ts-rest solved the TypeScript half properly. Routes first, declared once, typed on both sides. The research and most of the syntax started there, which is why if you know ts-rest you already know most of Kizuna.

It stopped at the edge of TypeScript. That is the part Kizuna adds: Swift and Kotlin clients generated from the same routes, where an endpoint deprecated once in TypeScript arrives as @available in Xcode and @Deprecated in Android Studio.

The name comes from 絆 (kizuna), a Japanese word for a deep, enduring bond between people. The hard part is keeping everything you built standing as the API underneath it changes. One declaration, bound to everything that depends on it, is what keeps it standing.

It solved a real problem for us. I hope it does the same for you, and there is a lot more coming.