About
Why this exists.
A question worth answering properly: if Apple built lightweight native apps for Nextcloud Talk — on the Mac and on the iPhone — what would they feel like?
Self-hosting solves the part of messaging that is about ownership. It rarely solves the part that is about craft. You get your data back and hand over your afternoon to an interface that is technically fine and never quite pleasant.
kvidr is an attempt to have both. Nextcloud supplies the backend and the protocol — documented HTTP APIs, a proper long poll, a server you control. The apps supply everything above that line, and take their cues from Apple’s Messages rather than from Talk’s web UI. The Mac came first; the iPhone is next.
What that rules out
The list of things kvidr is not turned out to be as useful as the list of things it is. It is not Electron. It is not a wrapper around the Talk web app. It is not a WKWebView rendering chat content — no remote HTML, no remote JavaScript, anywhere in the message pipeline. It is not a port of Talk’s web sidebar, and not a Slack or Teams visual clone.
Constraints like these are easy to write down and awkward to keep. They are the reason the app is small.
How it was built
Most of kvidr was written without a macOS SDK to hand. The non-UI half is a Swift package that builds and tests on Linux, which is what keeps the layering honest. The UI half is type-checked by a tool that stands in modules named SwiftUI, AppKit and SwiftData and runs the real sources through the Swift 6 type checker against them — all of it in CI.
That catches a great deal, and there are things it cannot catch: SwiftData’s macros, the Keychain, and how Liquid Glass actually renders. Those wait for a Mac.
Open source, all of it
Everything is open on GitHub under the MIT licence — the app, the architecture notes, the API audit and the implementation plan. Anyone with a Mac and an Apple developer account can build kvidr, sign it and run it without paying anything.
None of it has launched yet. When it does, there will be a signed build for everyone who would rather press a button than open Xcode — and nothing held back from people who build it themselves.
What is next
An iPhone app. Keeping everything below the interface in a separate Swift package is what makes that realistic: a second interface on the same foundations, rather than a second app written from scratch.