Nextcloud File Provider and Remote Changes

This article is about how and why the Nextcloud file provider extension for macOS learns about changes on servers without Apple’s centralized push notification service.

The way Apple designed the file provider framework expects file provider extensions to learn about changes on the server through push notifications. There are two major arguments for this:

1. It enables the file provider extension to work and integrate into the system autonomously, more efficiently and more simplified from its shipping app.
2. This is highly efficient, especially for mobile devices on cellular connections, metered connections or cloud servers with thousands of clients. It avoids keeping unnecessary connections alive or polling. With the convergent strategy and multi-platform design of the framework spanning from iOS to macOS, this is important.

However, it also introduces an undesired dependency on the centralized Apple push notification service. This becomes a hurdle especially in the case of decentralized services like Nextcloud. Many large institutions but also private enthusiasts use and operate Nextcloud worldwide. Because of my past knowledge of working with file providers for commercial service providers and branded apps for them, I know the hassle of setting up brand-specific identities and push notification infrastructure.

So the first special requirement in case of the Nextcloud client is the sacrifice of the convenience provided by the Apple push notification service. But this is not the only unusual constraint to work with.

Lifecycle of Apps and Extensions

I focus on our desktop client for macOS and leave out our iOS app which technically is a completely different product and implementation, only built on the same APIs on iOS.

In general, the user is on top of the control hierarchy. A user interacts with a computer by the help of the operating system and uses applications to do… whatever.

On macOS, users launch and quit apps on demand. The lifecycle usually is controlled explicitly and exclusively by user interaction. It is different for extensions shipped by apps, though. Those extensions are launched and terminated by macOS, only indirectly, based on user interaction and necessity.

A specific example: Assume you have a folder called “Contracts” in your “Nextcloud” location in Finder which is a file provider domain set up by the Nextcloud client. After the user opened the folder the first time in Finder, listing its content, macOS will not launch our extension at all again on the next time the user opens the folder because macOS already knows about the content. The file provider extension is only invoked in case of still missing folder content listing or the need of updating the current local folder information. That so called signaling is the only way to tell macOS to invoke the file provider extension again to enumerate changes which might have happened on the server meanwile.

What does that mean for learning about the remote changes? We cannot rely on push notifications due to the decentralized technology, we can also not keep a web socket open or even poll for changes on the server because our extension is not running most of the time. macOS will terminate its process due to lack of need and relevant activity.

App Dependency

At the moment, with our freshly released client version 33.0.0, we already have a dependency on the running main app anyway, so we can also rely on it to learn about remote updates. For historic reasons, it does check for those anyway because it still is a classic synchronization client, too, having the same challenges to overcome anyway.

When the main app learns about changes on the server, it signals the system to ask the file provider extension for changes. Then the file provider extension can become active to fetch the latest state from the server and derive the changes since its last synchronization.

So, this is how it works for the Nextcloud desktop client. There it is fine. The dependency on a main app running in the background on macOS is a feasible compromise. On iOS however, this is unfeasible because apps usually are not allowed to run permanently, especially not in the background to limit their resource usage and retain an overall great user experience with the device.