Thoughts on Native Nextcloud Clients

Since publishing Cirruscope, I frequently thought about the ideas of having native user interface clients for various Nextcloud server apps on macOS.

Let us focus solely on Nextcloud Files for a moment. Let us assume we have written an app in Swift based on first party technologies like SwiftUI. Let us leave out the devils in the details like push notifications for discovery of remote changes. Let us focus on macOS for now, despite the app also supporting iOS and iPadOS without much additional effort due to SwiftUI. It is structured like the Nextcloud Files user interface in the web but translated onto the Human Interface Guidelines by Apple and platform conventions.

The key question is: what would we gain beyond Liquid Glass aesthetics and a slightly snappier and solid feeling? Where is the additional value delivered by such an app? Hardly any can be found. A fancy firework without much of an impact. It does not even offer integration like the official Nextcloud Files desktop client does with its sync folders or File Provider extension.

The demand for “a native app” is popping up occasionally in the community, but it rarely comes with a precise definition of what native is even supposed to mean beyond the request itself. Nobody has actually been pressed for specifics here. Naturally, I focus solely on the Apple platforms in this article. This is an unfounded assumption of my own, a gut feeling that it usually reduces to a preference for the AppKit or SwiftUI feeling and the platform conventions that come with it: the fonts, the spacing, the window behavior, the animations. That is a legitimate preference, but it is an aesthetic one, and it says nothing about a capability the web interface is actually missing. A useful test for any “we need a native app” request is to ask what the app would be able to do that the web interface structurally cannot. In most cases the honest answer is that nothing changes except how it looks and feels while doing the same thing.

We would basically replicate the server web user interface in an adapted way. The development would always be a catch-up with the changes in the server user interface. Also, it would increase the risk of users being exposed to bugs because additional code is involved which is subject to much less testing and exposure than the web user interface. The web UI ships in lockstep with the server, so both are exercised together and caught by the same people on the same release, while a separate native client tracking the same OCS and WebDAV surface runs on its own release train, decoupled from the server’s release cycle. The OCS and WebDAV APIs are meant to be stable for third party consumption, but that does not close the gap. New capabilities the server exposes still need to be explicitly implemented on the client side before they become available there, and the native client does not benefit from the same day to day testing exposure the web frontend gets simply by being what the server team already exercises on every release.

There is also a more fundamental point specific to Nextcloud Files. Once a File Provider extension is properly implemented, Finder itself already is the native front end for browsing remote files. Search, Quick Look, tags, drag and drop, “Get Info”, column view, all of that comes for free and is available system wide rather than siloed inside one bespoke window. A second SwiftUI app reproducing “Files” as a browsable list would be competing with an OS surface that the desktop client already owns or could own more fully. The eye candy would not just be superfluous, it would be redundant with something better that already exists, and with what users are already used to for the same tasks since ever.

The same reasoning applies beyond Files. Calendar and Tasks already have a native counterpart in Calendar.app and Reminders through CalDAV, and Mail already has one in Mail.app through IMAP. None of them need a bespoke SwiftUI reimplementation of the corresponding server web interface, since the connection to a native, first party macOS app already exists, complete with offline capability, in much the same way the File Provider extension already gives Files a native front end in Finder. A separate native Calendar or Mail app for Nextcloud would replicate something that already has a well integrated native alternative on the same machine. Talk is a different case. A chat and calling app depends on being online to be useful in the first place, so the offline argument that speaks against reinventing Calendar or Mail does not carry the same weight there, and the case for a purpose built native app is comparatively easier to make for something like Talk.

There is a middle path worth naming here. Instead of reimplementing the Files interface in SwiftUI, an app can embed the existing web interface inside a native WebKit shell and build the native layer around it rather than instead of it. This is the approach Cirruscope takes. The web UI is not treated as a fallback to be replaced. It is treated as the asset. It already carries the interaction design, the accessibility work, the localization, and the years of daily testing exposure that a parallel SwiftUI reimplementation would need a long time to reach and would then need to maintain forever.

Wrapping the web UI removes the two costs raised above. The interface no longer needs to chase every server side UI change, since it simply renders whatever the server currently ships. And no second, less tested code path is introduced for anything the web UI already covers. The bug surface stays where it already is: the one place under the most scrutiny.

What remains for the native layer, then, is exactly the part a browser tab on its own does not offer: a proper application identity in the Dock and menu bar, window and tab handling that follows platform convention, native notifications, Share Extension and Quick Look hooks, Keychain backed credential storage, and distribution through the App Store or MDM. None of that requires rebuilding Files in SwiftUI. It only requires a thin, well behaved native shell around a web view, plus a handful of small extensions attached to it. That split, a web view for the interface that already works well, native code reserved for the integration points a web view structurally cannot reach, is a more defensible allocation of effort than a full rewrite chasing Liquid Glass.

It is fine to whip up a project like that full reimplementation as a spare time experiment, but the endurance of enthusiasm required to maintain it in the long run is unlikely to hold, since sooner or later the question of meaning will slowly start to bother more and more. A thin native shell around the interface that already works well asks for a much smaller, much more sustainable amount of ongoing work, and it puts the effort exactly where a web view structurally cannot reach.

Do not get me wrong: I would love to have native apps on iOS, iPad OS and macOS for every Nextcloud server app which feel like they are carefully crafted exclusively for their platforms while abiding all conventions and guidelines. Though, I also think that it is unreasonable to pursue as off now.