KALYIX V2
KALYIX is not just being pushed forward. I am rebuilding the path itself: away from an HTML- and webview-centered app and toward a modular Rust application with its own shell, its own core, and runtimes that only run when they are actually needed.
V1 stays visible as a legacy build. V2 is the path KALYIX is actually moving forward on now.
Why KALYIX is changing
Tauri and HTML made complete sense for the first product stage. The limits only show up once editor, runtime, output, and long-term extensibility need to work together cleanly. That is exactly why V2 is now being built as a new app with its own shell.
The current state works, but the hot path depends too heavily on webview and HTML logic. That is fine for an early build. For the real editor, runtime, and output path, it becomes too tight over time.
V2 separates UI, runtime, integrations, and output more clearly. That makes KALYIX more modular and lets it activate only the parts that are actually needed for the current profile.
For end users, the result should become clearer, not more complicated: fewer technical workarounds, a stronger editor, and a cleaner path from editing to live use.
Two versions, two roles
I want to show both versions openly, but I do not want to pretend they matter equally. V1 is the current state. V2 is the direction KALYIX is actually taking, both technically and in content.
V1 legacy
V1 remains available as a Windows build. It shows the previous approach, but it is no longer the architecture path KALYIX will continue to grow on. The app itself is available in German only.
If you want to try the previous state, this is the right entry point. New core development no longer happens there.
V2 active
V2 rebuilds KALYIX: editor first, runtime at the core, clear module boundaries, and later its own output path that does not stay tied to OBS forever.
OBS remains important at first, but in V2 it becomes an integration instead of the technical center of the product.
The new path
The direction is pretty simple in the end: first a strong editor with its own runtime base, then a clean path into OBS, and once that foundation is stable, KALYIX can later move toward its own output and encoder path.
Step 1
V2 starts with the base: editor, internal document model, local preview, and the runtime everything else will later build on. Twitch and triggers come before deep OBS coupling.
Step 2
Then comes the practical hybrid mode. Alerts, overlays, and OBS integration run from the same runtime. OBS stays important, but it no longer defines the architecture.
Step 3
In the long run, KALYIX should open the path away from OBS. That means own output, its own encoder path, and direct pushing toward Twitch.
What becomes possible later
The first focus stays on Windows and Twitch. But the modular runtime structure lays the groundwork for distributing parts later, moving load elsewhere, or letting multiple people work on one setup.
The desktop experience and the main user value come first on Windows, because that is where the streaming focus is strongest and the product path is the clearest.
Individual runtimes can also run on Linux. That matters mainly for later services, event tracking, or offloaded processes.
That also opens the door to external control later: server operation, load distribution, multi-access, or scene changes by other people without removing the local control point.
Stay in the loop
If you want to follow how KALYIX develops, sign up for updates. That is where I send new builds, direction changes, and important project milestones. No spam, no ads, no pointless noise.
No newsletter? Discord gives you the direct line to new builds and project changes.
Go to Discord