Do Nextcloud desktop client developers actually use the client themselves? In my case: not as much as you would expect, and there are reasons which are as surprising as they are boring.

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.