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.

When attaching Xcode to the file provider extension process of the Nextcloud desktop client, the debugger connected just fine — but every single breakpoint was displayed hollow and in dashes which means Xcode cannot associate the position with a line of code on disk. Tracking down the root cause turned into quite the adventure.

A question I encounter regularly from users is why the Nextcloud Desktop Client is so large. After all, it’s “just” a file synchronization app, right? Let me explain what’s actually inside that 945 MB application bundle by inspecting the 4.0.6 release with file provider extension for macOS.

A snippet to quickly open a bash session as www-data in a Nextcloud Docker container.

Having one semantic data model but two different types for implementation to separate domains and architecture layers brings up the question: where to put the conversion code?

If you’re shipping apps for both iOS and macOS, you’ve probably noticed that registering bundle identifiers with your developer team is necessary for iOS only.

I frequently have to install different builds of the same app, including the latest App Store release. With an iOS shortcut workflow it is reduced to two taps.

I figured out how I can run Ubuntu 24.04 Noble Numbat (LTS) on an Apple Silicon Mac for free with UTM Virtual Machines while also having hardware accelerated graphics.

While opening a pull request to fix a minor issue in the localization process of the Nextcloud Notes app for iOS I learned why de localizations must be overwritten with de_DE.

Frequently I need a clean throwaway deployment of Nextcloud to quickly reproduce bugs or have an isolated back end for client development and automated testing. This is the next level.