A lot of people are taking this as yet another example of Dropbox changing things for no reason, but I think it’s important to make clear that in this case Apple is forcing their hand. Dropbox is being told by Apple that apps must integrate with File Provider API[1] if they want to present files that don't exist on disk until they’re first opened.
This API is hamstrung and limiting, full of instabilities and quirks (designed to fit iCloud primarily but not necessarily everyone else).
Apple can’t (yet) stop you syncing a folder somewhere on the disk. Other services offer this feature - sync.com for example, which I switched to after Dropbox announced this change.
Dropbox wants to offer some features that are only available through Apple’s API. They want to be on the App Store. But they need to weigh that against what still is their primary feature, and literally how the product was described when sold. “A folder synchronized across all your devices.”
I am not a product manager, but I simply would not throw out my main feature and the thing that differentiates me in the market, in order to provide some features Apple wants, where the only difference between me and OneDrive is the icon.
I agree, but I think it’s important to point out: I believe the main feature they need is to sync the full file tree without having to download the actual files until needed. I don’t know how others do it, but I assume that you’d have to manually maintain mappings between a subtree in the cloud to one on disk, or alternatively run out of disk space if you want to have everything synced.
Non-techies will find it incredibly annoying to map individual subtrees leading to missing files, upfront sync costs when you need those, and running out of disk space. Dropbox cannot afford to simply throw their hands up and blame the users for not being technical enough.
That said, this hack (pretending your files are on disk) is arguably a fragile one, and perhaps shouldn’t exist in the first place (assuming it’s not a networked file system, which I believe it’s not). Or at the very least, they could have attempted to publish a standard. But if dropbox is just another proprietary piece of software running hacks, I can’t really blame Apple.
Why not? It's a very handy feature for a lot of users who don't have the disk space available to store their complete Dropbox folder. And it's much easier to understand and work with than manually managing selective sync.
Or at the very least, they could have attempted to publish a standard. But if dropbox is just another proprietary piece of software running hacks, I can’t really blame Apple.
Right. The issue is that you need to intercept file I/O to make transparent sync work. Dropbox did this before using a kernel extension, so that it can hook into the kernel kauth framework [1]. However, having third-party code running in kernel space is a huge liability, besides opening a huge possibility for state-sanctioned backdoors, it opens another venue for security vulnerabilities that give kernel-level access. So Apple decided that the kauth API should go (probably for other reasons), but more importantly that thirt-party kexts should go.
In general, I am very happy that Apple is on a mission to ban kexts, I don't want closed source third-party code to run in the kernel. However, it seems that Apple provides replacement userspace APIs, but is not really receptive to issues that developers have with them.
> In general, I am very happy that Apple is on a mission to ban kexts, I don't want closed source third-party code to run in the kernel
Will you still be able to run open-source or first party (for example, written by yourself) kernel extensions? Or will future macos versions require jailbreaks to get a real root permissions? Genuine question, I'm not too familiar with Apple products and I'm trying to understand why is this a good change. It looks like a limitation imposed on users.
FWIW, running code in the kernel is not "real root permissions", it's kernel-mode privledges, which are much different and arguably much more dangerous.
For my money, running custom kernel-mode code is not a concern. Apple is infatuated with remote device attestation for some reason though, so preventing OS modification is paramount for them right now. It's a limitation, but one that's hard to get mad about when Macbooks have a mostly-open bootloader.
To answer this question explicitly, it's currently possible to jump through some hoops to run kernel extensions, but Apple has been slowly tightening the requirements over the past few years. here's what Apple currently has to say about them.
> Kexts are no longer recommended for macOS. Kexts risk the integrity and reliability of the operating system. Users should prefer solutions that don’t require extending the kernel and use system extensions instead.
"System extensions", in this context, refers to extensions that the OS loads into userspace. Apple is developing userspace extension APIs to perform actions that were traditionally handled by popular kexts. The File Provider API is one of these system extensions. Dropbox used to rely on a kernel extension to intercept file access. File Providers allow them to do the same thing, but, as evidenced by this article, there are limitations as to where the files can live, and there are some bugs.
So if the File Provider API is so bad, and it's sill possible to load kexts, why doesn't Dropbox continue to use a kext?
- In 2015, Apple updated the OS to require that kexts be signed by a certificate in the Apple Developer program. This allows Apple to decide who can sign kernel extensions, and allows them to revoke the signing certificate for individual extensions.
- In 2017, Apple updated the OS to require a multi-step user confirmation before installing a kext. This initially caused some headaches for system administrators automating the deployment of multiple machines, but eventually solutions to this were implemented.
- In 2020, Apple started shipping ARM-based Macs, and by default, they don't allow the loading of any third-party extensions. Instead, users have to go through a process to enable them, and this process can be disabled on managed machines. Here's how Apple describes that process.
> Kext management by the user requires a restart to recoveryOS to downgrade security settings. The user must press and hold the power button to restart into recoveryOS and authenticate as an administrator. Only when recoveryOS is entered using the power button press will the Secure Enclave accept the change of policy. The user must then select the checkbox Reduced Security and the option “Allow user management of kernel extensions from identified developers” and restart the Mac.
All of these requirements can also be bypassed (if the machine is unmanaged or the sysadmin allows it) by turning off System Integrity Protection, which is a similar process as described above. However, disabling SIP disables a lot of security protections in the OS, and turning it off shows a lot of scary dialogues to dissuade users from doing it.
And for most users, SIP is a good tradeoff. It protects against a lot of things that malware can do. It prevents code injection, so dtrace doesn't work with SIP on, but if you're not using dtrace, there's little reason to turn it off.
Either way, the process is complicated enough that not enough users will do it in order to provide a mass market for Dropbox. Apple is also pushing Dropbox to use the File Provider API with the implicit threat of revoking Dropbox's signing certificate for their kext. Apple will not issue signing certificates for products that can be implemented using the userspace system extensions instead, and it's likely that they will continue to restrict the loading of kexts further in the future. Even if users can disable the signing requirement by disabling SIP now, there's no guarantee Apple will allow that to work in the future.
What I find surprising is that Dropbox is apparently willing to just fit in the narrow space Apple has carved out for them.
Especially now, when companies are cutting their spend, this is an extraordinary misstep. If I am already paying for iCloud, Google Apps, or Office 365, I can get exactly what Dropbox offers for free, and better integrated with the other productivity apps.
So why exactly would anyone use Dropbox now? There is nothing to differentiate them.
It’s hard to see this as anything other than the beginning of the end for Dropbox.
So why exactly would anyone use Dropbox now? There is nothing to differentiate them.
Their sync is just must faster and they actually do block-level sync, which the other major providers still haven't implemented yet after over ten years. I understand why people go to the competition, but I think it's a mistake. The FAANG offerings just provide enough (especially disk space) to lure people into their ecosystems, but they don't really care much about file sync, and therefore they are all quite miserable.
It is a bit like Microsoft Teams. Companies choose Teams because they have an Office365 subscription for Microsoft Office anyway and it is cheaper than Slack. On the surface, Slack does not seem to have much of a competitive advantage anymore. So, if you are simply bean counting, it's clear that you should switch to Teams. But in the meanwhile, everyone using Teams feels miserable to be trapped in it.
Because the rest of the company is on Dropbox already, and it's easier to stay there than migrate everybody. Single personal-use accounts aren't their bread and butter.
> I believe the main feature they need is to sync the full file tree without having to download the actual files until needed. I don’t know how others do it, but I assume that you’d have to manually maintain mappings between a subtree in the cloud to one on disk, or alternatively run out of disk space if you want to have everything synced
I thought the whole point of file syncing software was to sync all files. If I do not have internet access, then would I not be guaranteed to use all the files in my Dropbox folder?
I had frustrations with Dropbox about a lot of this when I realized they had made little public effort for Apple Silicon, but I think the fact that Dropbox is kind of stuck moving in this direction essentially highlights that Apple’s approach to cloud works for Apple … but not really anyone else.
I think for tools like like Box or even OneDrive, this move makes sense for, but Dropbox is intended to be a living backup of your primary folders, and that model just doesn’t fit with this.
This is almost bad enough to the point where the right play might be to have a machine on another platform, like Linux or Windows, manage your file sync, then to just access it on your local network. Apple really messed this up.
Well from a user and third party developer perpective it actually does make some sense for an OS to provide standardisation over cloud storage.
"If in folder X expect content to require fetching depending on application Y settings and act/manage exceptions accordingly. You can use that API if needed than standardize sync states across providers"
It is easier to exclude or target specifically for backup, easier to know you shouldn't store there for offline use, etc...
Being forced into OneDrive on Windows10 for corporate need since 10 month, I can tell you it's unbelievably easy to misconfigure OneDrive into a slugish unresponsive nightmare. Especially if you dare mix Organization OneDrive and Organization Sharepoint "mount points" in not exactly the good non obvious way. (never ever for hell's sake use the sync button in SharePoint website, use add to your OneDrive button)
> Well from a user and third party developer perpective it actually does make some sense for an OS to provide standardisation over cloud storage.
There’s standardization and there’s treating every cloud service like it should only work in one way.
Dropbox for years sold itself as being intended to work as your hard drive that could follow you as you switched devices. But now it’s working on a platform that actively discourages its use in that way, one that is operated by a company that is a direct competitor to Dropbox (albeit one that is not cross-platform). It feels like they’re getting crunched by standardization that is meant to disrupt their business model.
Now is that business model struggling for other reasons? Sure. But it shouldn’t be missed how this shift is arguably more disruptive to Dropbox than many of its competitors.
I’m not saying that standardization isn’t a good idea. But the API clearly was built without a lot of input from users of these services to understand why they want them to work in certain ways.
Not familiar enough was Dropbox was able to mount on "/" ???
As others and the suport page pointed you, you can still put a symlink at any available location you want.
It's still fully usable but it's now garanteed to not mess around with others contents. I personally am an iCloud Drive user at home because if I already chose to trust Apple for the OS and all, using their (contractually paid for) sync service doesn't require me to trust another party.
Standardization and sandboxing of cloud providers actually make me think about subscribing to a third party (for diversification let's say, or for separation of concerns when sharing on pro/other context). Because if standardized I can be assured by OS policy that theses sync services won't fuck around anywhere else than in their designated folder.
So yeah, maybe from now on you'd better go for rsync based tools that don't target App Store for pro use. But for 90% of the target audience this might actually be a desirable feature.
> Not familiar enough was Dropbox was able to mount on "/" ???
No, but what the OP meant was that Dropbox users think of it as a replacement for an external hard drive with all your projects. (Myself, I consider Dropbox, OneDrive, and iCloud Drive, to be the same thing with a different corporate overlord, and I migrated from Dropbox to OneDrive without any changes to my workflows…)
> It's still fully usable but it's now garanteed to not mess around with others contents.
How would it mess around before? Do you have any examples?
I can't point out a specific bug/vulnerability because I don't follow them that closely on platforms I don't use.
It's just that globally I'm not fond of background processes that run without being properly sandboxed through the OS. I'm less regarding when using FOSS software but for commercial closed source solution like dropbox I'd rather have them run with limited privileges.
These are two different arguments. You’re arguing for a level of security; I’m arguing that Apple’s implementation did not consider real-world use and leads to end-user compromises that lessen the experience.
In particular, I point to the move that you have to now keep the storage on the main drive, and the move to block access to the Mac’s photos library. Neither of these moves were necessary for sandboxing reasons. Both degrade the experience for Dropbox users that may have a folder far larger than the 256GB many base Macs come with.
Apple could have accounted for use cases of this nature to allow them to make sense for existing Dropbox users. They didn’t.
Sandboxing can be good in theory but completely suck in execution. That, I argue, is what happened here.
Leaving a third party Interfer with Photos library can easily lead to corrupted database and sync error if iCloud Photo library is enabled or worse if someone tried to access "Apple managed Photo library" from 2 different devices at the same time (the latter being a typical use case of dropbox). So this make a lot of sense, if you want to share a photos with drop box you should configure "Apple Photo library" to keep files in place instead of including them in database and sync that folder. Or you are even better using an other photo management app that support ACID database consistency accros dropbox file sharing (which is actually not an easy problem). Actually to share photos with dropbox you are maybe even better off syncing flat jpg files and use applications that don't rely on database at all on your different devices. A friend of mine do the latter and he's happy with that.
I can agree however on your last point, it could have been nice to allow cloud storage to be moved to an external HD. Maybe they should bring back this possibility in a futur update.
But for the managed photo library nothing currently prevent you from storing your database in an external drive, it's only cloud storage that is forbidden for the previously mentioned concurrency issues.
Please keep in mind that Cloud storage is not an external hard drive storage, it's not local, it's not a backup either (I personally backup regularly files on my cloud storage in 2 separates offline external HD and everyone should at least get one. Otherwise you actually have no backup).
> it's unbelievably easy to misconfigure OneDrive into a slugish unresponsive nightmare. Especially if you dare mix Organization OneDrive and Organization Sharepoint "mount points" in not exactly the good non obvious way. (never ever for hell's sake use the sync button in SharePoint website, use add to your OneDrive button)
I am using both of these, direct sync of SharePoint libraries (what you call Organization Sharepoint) as well as linking the libraries to the personal library (what you call Organization OneDrive) and have never had any issues. What are your problems with it?
The only thing one has to know is that it's not possible to do both at the same time for a given directory: a synced folder (and its children) can't be linked to personal and a linked folder (and its children) can't be synced. Note that "linking" also "syncs" it, just in a different location.
Well my organization current moto is to create hundred of different sharepoint sites that can contain multiple document libraries to compartmentalize (I personally think it's a really bad idea but i have to comply).
So when you happen to work with 10+ Sharepoint sites there is two way to operate if you must sync.
1. Click sync on the document library. Then each sync while need a configuration entry in One Drive and each sync will create it's own background worker. Prioritization between sync/mounts point must happen somehow but if you open 10+ I experienced lot's of sync error/delay. Sync parameters to each sharepoint have to be defined manually and independently on all your devices.
2.You can add a "shortcut" pointing to the sharepoint into your organization (personal) OneDrive. The configuration is then stored on your OneDrive profile, it's synchronized across all you device and the OneDrive webapp. You can move the shortcut around (inside your OneDrive) and rename the folder as you which. It only require one background worker that don't compete for system ressources with others.
I was initially configured using solution 1 and experienced many conflict/lag/bug. Since I implemented aolution 2 everything is (almost) flawless.
So the question remain why do they offer two concuring implementations one of which can lead to madness... legacy support I guess.
> the right play might be to have a machine on another platform, like Linux or Windows, manage your file sync, then to just access it on your local network.
I mean, the Internet has known for a long time that you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem…
I want all my Dropbox files to be actually present on disk at all times, so this change has only downsides for me. I’ve been with Dropbox for over a decade at this point, mostly out of inertia, but forcibly changing the location of the folder will likely push me to finally switch away.
It’s because their implementation of “files downloaded on demand when you click on them” required a kext, and kexts can’t be loaded on Apple Silicon without weakening (disabling?) system integrity protection. Google Drive and OneDrive had to wait a while before Apple had these APIs ready before they could make non-Rosetta versions, and I’m sure Dropbox was the same way, we’re just hearing about it now.
- Kext == Kernel Extension
- System Integrity Protection (or SIP) is a feature where various core operating system files around the boot process and kernel must be signed by Apple or the machine will not boot. It can be disabled, but this leaves your machine in a much more insecure state and can cause certain features to be disabled. I know for example I would get reamed by my companies InfoSec team I had SIP disabled on my corporate machine.
- Rosetta 2 is an transparent and efficient x86 -> to ARM64 translation layer on MacOS. It’s used on Macs with apples m series of processors to run old software that hasn’t been recompiled for the new architecture. It runs quite efficiently actually with ~15% performance overhead in my experience. Rosetta 1 was and older version of the same thing from the last Mac CPU architecture change (PowerPC -> x86)
A developer can sign their own kernel extensions, even on M1. It just requires you to initially set the machine into a specific mode that allows it.
The people this puts pressure on is not individuals trying to write or sign their own kernel extensions if they know what they are doing (essentially reboot into recovery and run some some shell commands).
It does prevent
- Unsuspecting or otherwise ignorant users from being tricked into installing a malicious kernel extension. - Prevent large companies from distributing custom kernel extensions for every day users
AFAIK loading custom kexts has become harder since the launch of TouchID on macs, but for an average user its better to live inside the secure world of Apple's tight security controls & encryption - allowing Apple to claim security & privacy as core selling points.
Dropbox currently uses API X to have files that are available online but still visible from the Finder and other apps and can be downloaded on-demand. Apple wants to retire API X and offers API Y (FileProvider) as a replacement. If Dropbox want to keep the download-on-demand feature, they must switch.
They can't force but they can't retract from the AppStore. You'd still be able to deliver outside the AppStore with a signed App on MacOS but with way less visibility.
I prefer installing things from App Store on my parents' computers cause it will handle automatic updates and provides certain guarantees (i.e. can rely on Apple not letting malware onto their App Store).
Wow, this is terrible. As a critic of their slowness, I can now see why they dragged their feet on Apple Silicon for so long—the File Provider API really just trashes the experience.
In a world where Apple no longer allows for internal storage upgrades, the fact that you can only store your Dropbox on your main drive is just such a joke. This is the degradation of the experience by a thousand API changes.
I moved to SyncThing/local syncing in response to Dropbox’s moves last year, and I gotta say I am not regretting it one bit.
I record audio at my studio into a dropbox folder on an external drive. I paid for a business plan (and the required 3 seats, only using one) so I could have unlimited storage.
This drive is always syncing to the cloud.
I go home (or travel) and can selectively sync specific projects, which still viewing the entire tree and keeping everything organized.
Neither internal drive is large enough to hold the files.
This workflow is so perfect Ive built my entire creative process around it. It’s completely broken by this change.
I’ve been a huge proponent of Dropbox and pay them over 1k a year as an individual just for this functionality.
The one thing that's kept me from SyncThing is the lack of iOS integration [1]. But the changes Apple has forced on Dropbox here is making me reconsider.
I switched from Syncthing, to Sync.com, and now finally to a combination of pCloud for archiving, and Syncthing for everyday files. I'm happy with this set up, and recommend it. EDIT: My motivation was wanting reliable end-to-end encryption.
The lack of iOS support isn't an issue for me either, since one of the reasons I avoided iPhones was precisely because I knew things like this would at some point be a blocker. 99% of the time, iPhones are fine, but that 1% of issues that Apple policy causes is dealbreakingly bad.
How has Apple forced them to do those changes? Apples APIs only allows it that way but Dropbox don’t have to use those APIs. There‘re other Cloud Sync clients that just work fine supporting all those features without using Apples APIs.
So Dropbox decided to switch to using Apples APIs knowing that it‘ll lack those features.
My first response was rage but on more careful reading, this doesn’t change much for me. I can probably symlink ~/Dropbox to ~/Library/CloudStorage/Dropbox and call it a day. Here’s why it doesn’t affect me much, which I mostly wrote to calm my own nerves…
- I have a bunch of scripts, aliases, crons, and other console things that rely on ~/Dropbox. A symlink should fix that and it looks like Dropbox will create one automatically when it moves the folder.
- I can create a new favorite to the new folder in Finder. I use a single subdirectory (my name) so, if I can only do this with a subdirectory, not the Dropbox root, that’s fine. I presume I can do it with root too though.
- I don’t store Dropbox files on an external drive. Seems like I could never get this to work right. I just use my internal. I guess I got lucky here.
- I don’t use many of Apples Proprietary tools that use flattened package files. I onky use Photo’s temporarily, and I don’t really use Pages, Numbers, or Keys. But, if I did, they only really work on Mac, so this seems like a sane change to me. I mostly use similar cross platform apps like Libre Office if I want it to be portable.
- I don’t search in Finder, I just use spotlight, which continues to work the same way.
- I might have 300k files, I’m not sure. I try to organize photos into folder annually to cut down the number. Lots of things have trouble with this many files. I already try to organize around similar limitations.
- I’m already on MacOS 13. MacOS 12 seems to have a handful of file issues that probably wouldn’t affect me anyways, but definitely won’t under 13.
- I don’t use LAN syncing.
- I keep almost all of my files in offline mode (on the local machine, taking up space, duplicates, etc).
> Files added to your Dropbox account from another device or that are shared by another user will default to online-only.
Correct me if I'm wrong, but this completely breaks the sync model if you use more than one computer. It used to be you could add a file on machine A, and without any user interaction, it would sync to machine B. Now that's broken unless I go and manually mark every top-level folder as offline. And don't ever add anything to the root of your Dropbox folder....
Could be true. In an act of luck, I created a folder for myself and that’s all I sync. So, if I can set this at the folder level, I just set that one folder to offline and I’m good. It’s just happen-stance that I set mine up this way years ago though.
IMO the other really big deal here is that ~/Library is a hidden folder by default. For most users Dropbox will only be exposed under the "Locations" section in finder sidebars. That feels like a huge regression to me — the whole idea of Dropbox was "a folder, that syncs." An invisible folder that syncs is much worse!
OK nice. A symlink will go a long way for the average user. The way I read the article it seemed like they would rely solely on the Locations list in finder sidebars.
If a user can't open or target a folder by typing in the location, it's useless for any meaningful file management. This feels like macOS is becoming more like iOS instead of the other way around. There is a setting to re-enable it, but it shouldn't need a setting.
That's a very low bar to set for "power user". By that standard even users wanting to install Dropbox and managing files themselves would be enough to count as a "power user". Recommending the use of a terminal is even more of a regression. It's not a far better choice, it's not even a good choice for file management. Basically everything is slower through a terminal interface.
I feel like if you're a power user you're generally going to reach for the terminal.
Although I do like the "Go To Server" thing in the menu bar when you're in Finder. Easier than remembering the ftp command to do whatever. Plus I can look at FTP directories as if they were just files on my local drive. But other than that... I can't think of 1 single other thing that I would rather do in Finder vs. a terminal of whatever flavor I'm feeling that moment (Alacritty, iTerm, VS Code builtin terminal*)
Mixed files and situations where I have to order by date or more complex filtering makes me hate dealing with terminals. If I want to pick and choose, let's say, the first, third, and sixth files orderd by size descending, it's unnecessarily annoying with just a terminal. I don't think that's a "power user" situation.
I admit that I am a power user, I use QTtabbar which gives me tabs in windows explorer, the same functionality is built in macOS finder. I also have keyboard shortcuts for, delete folder and move all contained files to parent folder, delete empty folders, and edit specific metadata, among other things. The single most useful "power user" shortcut that QTtabbar gives me is double click empty space to move view up to parent directory, macOS finder has a keyboard shortcut for that. Android is great for this kind of stuff too, but I have rooted my phone so no folders are hidden. I have termux set up too, the android terminal emulator, so I have grep and sed if I wanted to. I will absolutely everything I can to avoid having to do file management on iOS.
I don't know sure when the accepted definition of "power user" changed from the keyboard shortcut functions I'm describing to navigating view based on path. Knowing and navigating by path feels too basic, to me, to be a qualification for "power user".
What type of tasks do you usually do with a GUI file manager? Long time ago I've fully converted to a command line, and I don't even have any GUI file browser now (like explorer or nautilus). I find `cd`ing (with a good tab completion) faster than clicking folders, and if I navigate somewhere I probably want to execute a shell command anyway.
If I want a shell, I right click a folder location and open a terminal at location. I added the shortcut to the services menu on my macOS machine.
I move files based on size and extension and date ranges. One example would be moving 10 of the the largest video files of various formats, bigger than 150mb, created at least 2 weeks ago, that don't have digits in the name to my secondary hard drive. I am so much faster Ctrl/Command + click/drag instead of command line, especially when I don't know the exact names. In this case imagine the name format is YYYYMMDD[project][camera][resolution][description].[codec], which feels like a nightmare to manage with a terminal.
Windows explorer is set up with custom shortcuts for things like move all files to parent directory and delete folder, delete empty folders in directory, modify created date/other metadata to name some frequent operations. I use QTtabbar on windows for those. It also gives me the double click to move to parent directory shortcut, macOS has a keyboard shortcut for that built-in. Another valuable thing to me is the open with context menu that shows up. I know I can set up ailiases, but I have so many programs that I feel like it would be too many to remember. Tab completion doesn't work efficiently when tens to hundreds of files have the same prefix, for example dates when I'm working on a specific project.
I know I am a power user, but that's also why I feel comfortable asserting gui is better. I even have some nice macros setup using autohotkey for repetitive rename + sorting. Path strings are so useful for file redirecting and management with regex.
I was talking about dealing in path strings which most ordinary people are not normally exposed to. And in that situation Apple provides an easy and obvious method to navigate to it.
And would be very much disagree that everything is slower with a Terminal. In fact most things I do can't even done in the Finder UI.
In the context of Dropbox users, I expect the large majority to deal with things like path strings. The entire point of Dropbox was to create a user managed cloud service. Apple has a frustrating habit of shifting the goal post on what a "power user" is. Path strings are literally the same as urls. There's "path" strings on the Dropbox webpage as part of the header when looking at the location of folders, especially nested. I am not sure why you think most ordinary people aren't exposed to it.
I agree with you that the Terminal is faster for some things. But let's take an example of moving the last 10 largest files that I downloaded a week ago, but excluding any .mov files or files larger than 2gb. That's not a "power user" operation. With finder, that's 10 mouse clicks in detailed view. Regardless of how skilled you are with a terminal, it will be slower and more inefficient to do the same thing. For the most frequent file management operations, gui will always be better and faster than terminal.
When I was at Dropbox, one of the big threats to the business we talked about was OS's banning file sync applications and forcing them to use their own APIs for them instead. It looks like that's finally happening now, unfortunately.
It doesn't look like that's what's happening. This is only an issue because Dropbox isn't trying to be a file sync application any more, and is instead trying to be a userspace network filesystem driver.
The original Dropbox wasn't just simple to use, it was also simple to understand: you knew what it was doing and how it worked, well enough to have correct expectations about how it would behave in circumstances like having a slow or broken internet connection. I guess they now consider those circumstances to be so exceptionally rare that they can be ignored.
They painted themselves in to that corner by selling up to 3TB of storage on the idea that you could have access to all of it any time [you’re online] even on your <1TB laptop
On the contrary, they didn't ban it, they made it "first class".
So the tricks Dropbox did early on to show unique icons etc., now built in.
OneDrive personal and business use this fine, so can others, and then they all behave consistently with similar looking icons and affordances, whichever sync providers the users use.
Like many things HN devs complain about, devs forget they are not the main character, the user is.
This experience convergence is fantastic for users.
It’s interesting how Apple is making so many enemies in tech. When I was at Facebook it was the same, with mark encouraging people to get android phones. I see that amazon, twitter, and the gaming industry all have issues with apple too. It’s interesting to say the least. I just cancelled my twitter blue membership when I learned that I was going to pay more just because I subscribed through iOS, thinking I will resub from dekstop, but then never did. I also ended up buying a bunch of audiobooks and books through apple books because I never could do it through kindle and the amazon apps. I can’t imagine I’m the only one.
I'm slightly confused. I read through the entire list carefully, and there are multiple downsides for the changes. The only potential benefit is that files can "pretend" to be there, and be automatically fetched over the network when needed, which is something that I would consider a downside, as I'd much rather have a full copy of my entire tree locally, so that I'm certain it's there when I'm offline.
So why do it at all? Why not drop the feature of "pretend you're there" and just continue like before? The downsides seem massive to me.
Also, is there something that prevents me from just running Maestral and having access to my dropbox stuff just like before?
These days most of my important stuff gets synchronized using syncthing. It's much more performant, became extremely reliable over the years, doesn't hog my CPU like crazy, and doesn't show upsell banners and prompts. I would have dropped Dropbox a long time ago if it wasn't for synchronizing my PDF collection with PDF Reader on my iPad.
I imagine there’s a possible justification of libraries getting broken because Photos.app doesn’t know how to handle partial syncs gracefully. Many apps don’t.
(Though I also agree Apple really does need to clean up its own room before worrying about what third party software is doing.)
Doing an atomic-swap sync of a folder (which is what a photo library is) can result in momentary doubling of size-on-disk. For something as big as a photo library that may not be acceptable/possible.
The solution (differential syncs with atomic update and with support for the version being diffed against changing during the sync) are quite tricky to get working reliability, and they get less reliable the larger the atomic unit of data is.
All that is also assuming that there's a way for the sync program to interpret what units (files or folders) the user wants to be updated slowly/expensively/atomically, which is itself very hard to solve without adding friction or foot guns.
APFS has copy-on-write semantics. I regularly duplicate my entire photo library folder. Just duplicate a large folder in Finder and you'll notice (a) it's instantaneous (b) it doesn't cause the disk usage to increase appreciably.
I agree. There is a clear way that Dropbox hurts Apple's business interests. Many Apple devices don't have a lot of space. The current generation base Mac Mini and MacBook Pro both only have 256 GB of storage. The iPhone 14 Pro starts at 128 GB. So, many people in the Apple ecosystem rely on things like iCloud Drive not only for backup storage (like storing only important files) but also for the bulk of their storage (as the device space is so limited).
The 2TB iCloud Drive costs €10 a month or €120 a year. That is a lot of money over a device's lifetime - about €850 for an average MBP (which on average has a 7 year lifespan). And Apple users really feel the pressure to use these more expensive iCloud Drive plans. Unless there is a competing service targeting the same price point (and even a slightly lower one with an annual subscription).
So it makes clear business sense to kill the competition. Every other explanation is just a little bit more contrived than the straightforward business case.
Did they actually block it? The Dropbox blurb says
> Photos Library isn’t supported on Dropbox for macOS.
And links to this Apple support page [0]. That says:
> And to avoid possible data loss, don't store your library [...] on a device shared over your network or the internet, including over a cloud-based storage service.
So both don't explicitly say it's blocked, just "not supported". What does that even mean? That it won't work at all?
Apple is forcing companies to use their new interface for file syncing applications and Photo library is a perfect thing to sync with Dropbox, so I blame apple for not supporting it properly.
Feels like they don't want the files in the library to get out of sync which would corrupt the library pretty quickly if dropbox can't sync the thousands of files it contains as a single change.
You might check out Nextcloud. A hosted version of course, since self-hosting could not be called a Dropbox replacement. Hetzner + Nextcloud [1] replaced Dropbox for me last year.
Apple forces the use of this API if you want files to be downloaded on-demand to save disk space. Nextcloud seems to support this use-case on macOS only experimentally [0]. In the light of these changes, they might decide they don’t want this feature at all on macOS and sync everything the old way. (I don’t know what their plans are, just speculating.)
I actually tried this and wanted to like it but the problem is that they only have NextCloud-specific hosting in Germany at this time (unless that changed recently). That’s good if GDPR is a real concern for you, but it just kills the speed if you’re on the other side of the ocean.
I worked NextCloud into my setup locally though. I don’t love its syncing capabilities, but you can get around those if you set up SyncThing folders as external storage. That way you get the benefits of NextCloud (the customizable interface) while getting the fast syncing speeds of SyncThing.
Dropbox gets skeevier and skeevier every time I install it. It used to be a snap to install and get working, now it's more about their business needs than mine.
There is (still) room for competition in this space.
The trivial proof that Apple can't be forcing them is that other services continue to offer a synced folder. Dropbox has been extremely vague about what exactly they're trying to do and why they have to do it this way. It seems like they made an unpopular/dumb product decision, and they're just trying to shift the blame onto someone else.
Usually if you use apple devices you have to use apple apps. They tend to slowly kill the competition by improving things for themselves. So I would say iCloud is the way to go here.
What do you mean? I've got two Macs without iCloud account and aside from Finder & Mail I use almost zero Apple applications. Seems to work quite well including two Nextcloud accounts (aside from general system instability), though I've not been on Mac OS for long yet.
Apple has a bit of a history removing software features from the Mac. Nvidia driver support, 32-bit application support, OpenGL support and GNU support has all been dropped by Apple over the years. The longer I owned my Mac, the less capable it became.
It has a horrifically long initial sync for me (hours of silence and no apparent activity), but yep. I do not miss the official client in the slightest after switching - it has been significantly faster and better-behaved in every imaginable way.
In particular, I no longer have to stare at Dropbox and wonder why it hasn't uploaded my tiny plain text file change for several hours. Which I've had to do regularly for the past couple years. Maestral consistently uploads within seconds.
Gets an upvote for me. Maestral has been efficiently syncing my Mac for at least 2 years now, through the whole no available M1 arm client and other Dropbox turmoil.
I've been using it since shortly before the M1 Max came out and I quite prefer it. No nonsense and it makes Dropbox function like I want it to (just a folder that syncs). I wish it has some better activity reporting (when I'm waiting on a large file to sync that I want to share I'm in the dark) but for fire-and-forget storage it's great.
FFS. I haven't enjoyed Dropbox since they disallowed symlinks. For many years I kept my home directory stock and created symlinks within Dropbox for Music, Pictures, and Documents etc. Then for some reason they actively prevented symlinks, so I swapped it around and moved the directories into Dropbox and symlinked from my home directory. This broke icons in Finder sidebar with no way to fix. It also breaks navigation in Finder, eg go into ~/Pictures and go back up and you're in ~/Dropbox, not home. I hate it. Now, the path is going to get even worse and my real directory for Pictures will be something like "~/Library/CloudStorage/Dropbox/Pictures" instead of "~/Pictures".
I was excited when they announced Dropbox backup, I gave it a shot and it just did the exact same thing - it moved the real directories into an obscure location within ~/Dropbox and created symlinks in the home directory .
It is genuinely amazing how Dropbox worked better for me 10 years ago than it does today. But I've been scared to move off Dropbox because of how reliable it is. I tried Google Drive a while ago and it was extremely buggy, all my files got duplicated, and I had no trust in the service. Wouldn't go with Google for other reasons these days. I was considering Sync last year, think I'm going to bite the bullet and give it a go.
It does seem we went backward with Dropbox. I think part of it is the whole file sync thing where you save space by not having a perfect mirror and all your documents. Making it more dynamic and cloud based might be good for storage, but it ends up with a ton of trade offs.
All cloud file sync services on macOS are ultimately going to have similar issues unless Apple dramatically improves the API they're forcing everyone to use.
As a user of both a recent OSX and an M1, and using multiple other syncing services: nah. Others are doing just fine. Dropbox is likely being pig-headed about something, forcing them into this awful corner, and they're loudly blaming Apple for it (partially justifiably, partially "if it hurts when you do that, don't do that").
My guess is it's the transparently download when accessed files, due to losing a lot of kext abilities through the years. Apple hasn't blocked applications from changing files or using file notification events, so "normal" syncing things are still running just fine.
Dropbox claimed the same thing when they banned them, yet myself and hundreds of other people had symlinks in our Dropbox for years without any problems. In fact I never heard of a problem with symlinks in Dropbox.
Anyway, symlinks in Dropbox were banned years ago. So now Dropbox contains the real directories, and I have symlinks in my home directory. I don’t see how this could go wrong. Also, this is how Dropbox implements their own Computer backup feature.
Syncthing. It's amazing. I use it across my NixOS workstation, M1 Macbook, home lab server (acting as an "always on" folder to always fetch syncs), and my Steam Deck.
I personally found the entire syncthing process convoluted and over complicated to the point of giving up several times before I actually got it working. Am I remembering correctly that you need to allow every machine to sync to every other machine individually?
Convoluted and over-complicated, and prone to syncing issues and latency that are extremely difficult to resolve without a lot of context, yeah.
Much of it is that it's a truly distributed system, so each computer you connect is untrusted - it doesn't fit well with use-cases of people migrating from Dropbox. It can be made to work, without all that much trouble, but it's based on a very different set of assumptions and it shows.
(I say this as a mostly very happy user of it, and I do recommend it. But you're not going to be successful in migrating your non-tech-enthusiast friends or family)
No. I don't know whether my setup is typical, but I have one machine that new machines have designated as an "introducer," so each machine eventually learns about the existence of the others. As for syncing itself, it just works. I have a $4/month virtual server running Syncthing, so every machine that's online always has at least one to connect to. Changes typically propagate through that one. But before I went that route, data eventually got where it needed to go.
I do the same thing and have bash scripts that run on my server to ingest data I find useful. I use org-roam and org-daily to keep a journal in Emacs, and text from across the web or my life just arrives that is important for that day.
Examples: my likes on Twitter, highlights on the web (highlight something, right click "Import to Readwise", it downloads into Emacs via syncthing), calendar events, etc. I'm always collecting stuff that I can reference later without much effort after the initial setup. It just works.
It keeps multiple copies of your data on whatever machine is running syncthing. So if you lose data on one machine, it's still safe on another.
Sure if all machines go at once, you're screwed. But I'm not too worried about that, personally. If you have something you absolutely can't lose just stick it in a Backblaze bucket and use syncthing for the rest.
Backblaze is cheap and has both an API and web interface.
Yeah, I agree with this. For the lay person it's not going to work for backup, you need something else to checkpoint the files. Versions, ZFS snapshots (what I do), git, bash scripts + Backblaze, whatever. Lots of people don't want to mess with this, which is what Dropbox used to solve for. Now you're constantly barraged with whatever new methods they are experimenting with to monetize. But we know that, so I regress.
For those who don't mind a little extra work (I argue Backblaze is almost no work using their Web UI), syncthing is a really great solution.
> Backblaze is cheap and has both an API and web interface.
Yep I think Backblaze for backup paired with SyncThing for syncing is probably about as good as it gets. Admittedly my needs for syncing aren't crazy but it's worked well for me.
Having a third machine in the mix is pretty great, I can move from my office upstairs to my laptop downstairs and pick up right where I left off. Sharing Nix configuration between the two machines means that is always in sync too.
Sync.com is basically Dropbox but with e2e encryption, and about the same price. I switched to it about a year ago and I’ve had no problems at all. I don’t understand why I almost never hear about it on HN.
Syncthing might work for some but it’s not a drop-in replacement for Dropbox at all, you have to come up with your own cloud storage. I tried it for a couple of months but I found it a bit confusing and unpredictable. Felt like I could easily permanently lose data by messing with the config when my brain isn’t 100%. The peace of mind just wasn’t there for me. It felt like a cluster of footguns.
Do we know anything about trustworthiness/security audits/etc? Would just like to get a general feeling of trust, especially since I haven't heard of it before
They’re moving to a modern API. Where the files are stored makes little difference to the user. The only problem I see is that they’re dropping support for files stored on external drives: that should have been the title.
> Where the files are stored makes little difference to the user.
I beg to differ. A common use case for dropbox is to sync files used by other programs, and you can't always change the storage location that they use. This breaks that use case.
I don't really understand why Apple have done this. Seems like a big regression in functionality to me.
If I remember right, the Dropbox folder is originally ~/Dropbox anyway, right? You can't just sync arbitrary stuff in your home folder using it without getting into symlinks in the first place.
Dropbox used to work perfectly fine with symlinks. But they sent me an email in December 2019 titled "Dropbox is changing how we work with symlinks" which is a euphemism for Dropbox no longer supporting symlinks. That's when I stopped using it.
God I hate this particular headlining strategy. Can't use any negative words whatsoever. Always have to pretend it's just "a change". But new features are always given top billing on the headline. So now I just assume any vaguely worded headline is to be interpreted in the worst possible light.
Directory hard links are unusual and Apple only implemented it for Time Machine. It was never really well supported on macOS to begin with. Apple removed it from APFS.
It works, and I used to have a script to rsync certain directories into the Dropbox folder as hardlinks (I can exclude shit like node_modules that way). Not directory hardlinks, but rsync’s --link-dest, so that each individual file is a hardlink.
Anyway, I stopped using Dropbox long ago.
Edit: Parent is talking about directory hardlinks, so no.
For a less technically-savvy user there's a big difference between "my spreadsheet is in the Dropbox folder" vs. "my spreadsheet is in Library/CloudStorage". Especially when the "~/Library" folder is hidden by default.
That’s right. I think people forget now Dropbox works. It mentions this in the linked document, it explicitly says you have to recreate the links. But no, downvote the people who know how to read instead.
> I don't really understand why Apple have done this.
There was no official File Provider API or API to show sync icons in Finder when Dropbox started. You use FSEvents/kqueue to monitor filesystem changes and do whatever. Some Finder hacks were required to display sync icons. Then official APIs were unveiled, with restrictions.
Given that Dropbox competitors still work outside ~/Library just fine on macOS 13, I’d say it’s Dropbox choosing a restricted API for whatever reason (easier development?).
You can still use FSEvents/kqueue and Finder APIs to implement a file synchronization daemon. But Dropbox hasn't done that for a while. A few years ago they moved to a kernel extension that exposes your Dropbox as virtual files that are downloaded on demand when you open them. They called this Project Infinite: https://blog.dropbox.com/topics/company/announcing-project-i...
Right. To clarify your point, dropping support for external drives is for some users a massive and very disappointing change for some users. I am one of those affected.
I don’t want dummy files that only download when I want to use them. I work with a lot of 100-500mb files and I will be really annoyed if I have a 30second delay every time I open one of these or even worse not be able to access them because the internet is down wherever I am. I’ve already moved to Nextcloud but if I hadn’t this would push me to.
I dropped Dropbox years ago when it had the gall to assert that MP3s that I'd ripped from my own CDs were "pirated". I won't use a system that snoops on the files I store with it. I suggest looking at Sync.com as an alternative. They don't hold the master encryption password for your files.
Most cloud services do it. Microsoft has been scanning all uploaded pictures for their visual contents for years, Google had this famous case last year where they reported a Drive user for an uploaded picture.
It's E2E encrypted or they have full access and make use of it, simple as that.
I’m sooo annoyed with our Dropbox for education account, insisting to name the folder as ‘Dropbox (UniName)’? (I think this also applies to enterprise accounts…) This is a Dropbox problem as my org can only influence the name inside the parentheses.
There are two bad things with this folder naming… the parentheses and the space. I still use software the does not work well with spaces and parentheses in folder names. There is an open issue about this with 100s of complaints, and Dropbox just ignores the problem.
PS: symlinking doesn’t always solve the problem.
And this new scheme to put it in Library/CloudStorage will make path names even longer… (sometimes my terminal prompt resolves the full path instead of the symlink; never took the time to figure out why)
Anyone that have solutions to these issues, I would love to hear about it.
Sure. But it is sometimes hard to debug… (even to identify this as the culprit). For example, for a while one of the vscode plugins that I use just stopped working and it took quite a while for me to figure out why it had stopped working. There were no errors reported in the log. Only once I suspected what the problem was, did I move my project out of Dropbox to a local folder without space to confirm my suspicions. But the fact that several 100s of other people experienced similar or worse problems made this naming scheme a bad choice imo. A simple Dropbox-UniName would’ve avoided the problem for lots of people… That said, I don’t even see the reason to force a specific naming scheme for people’s local Dropbox folder. They should allow me to name the folder X or D on my drive. But maybe it’s just me that don’t like long path names…
This was the final straw which prompted me to move off Dropbox. Initially, dropbox was wonderful, super simple and did ONE thing amazingly well. Then... the thing morphed into a monster with all sorts of "corporate america" features which I never cared for. Fine, they need to make money, I get it. Besides storing and syncing files, the dropbox app on iOS was amazing to take quick scans of receipts on the phone and sync them to the Mac and auto-process them there (via the receipts.app; great 3rd party app). Anyway, in 2023, iCloud Drive with the native Files.app on iOS does the same thing for me. Just as good, just as reliable. For free, without the bulky corporate app stuff.
But … icloud benefits from being part of the OS. Dropbox is probably technically unable to build a service that works as smoothly as icloud. It seems unfair to ding dropbox for that situation.
Having said that, I use icloud as well, together with syncthing.
This is about the same kind of experience I currently have with OneDrive, "thanks" to the File Provider APIs.
One thing that I am especially annoyed about is that Spotlight in Ventura now refuses to do something as simple as launching document files from a file provider, or to open their containing folder (which is a Ventura/Spotlight bug and definitely not a OneDrive one).
Does anyone have recommendations for a Spotlight replacement (that doesn’t use spotlight under the hood)?
Different but related issue: Spotlight breaks for me constantly (there’s a corrupted file somewhere in the TBs and while it breaks the index, the logs are an unhelpful firehose). Last time I looked, all the replacements were just using the Spotlight index.
Sounds like it’s time for the community to show how bloated and restrictive Spotlight has become.
The community can't really match what Spotlight can do under the hood, I'm afraid. There is a huge amount of engineering effort that went into the indexing, data extraction and filesystem integrations that you can't just go and reimplement from scratch.
Regardless, I went and filed feedback #FB11980196 today, in the hope that Apple actually looks at these things (but I've been around since the Radar days, so I have little hope).
No I’m sure that no one can match what Spotlight does under the hood (I assume most of the necessary APIs are locked down), however I and many others could replace spotlight with something that goes oldschool: search folder/filenames.
It would allow us to launch applications quickly, open calendar if we need to search for an event, open contacts if we need to search for contact info, and find files that we’ve saved to the local disk. Bonus points if it also does math and currency conversion, but at least for me: entirely optional.
The only reason I’ve remained on the Dropbox free plan for a decade is because in the early years I was able to boost the free space to 25GB through referrals and contests. I use it as a quick way to sync files and access them from mobile devices (I have separate online backups not dependent on this). I’m not interested in buying yet another cloud storage plan from the major providers just for this.
From this article, it seems like support for macOS Big Sur (and prior releases) will be dropped in the coming months. That plus the dropping of LAN Sync, which was great when it worked, means I’d have to consider dropping Dropbox.
I’ve tried Maestral (https://maestral.app/) once last year and it made a mess of the files while the official Dropbox client was being used by another user (not at the same time). So I switched back to the official client. If there are good clients that would continue to work (don’t know what the Dropbox server side changes are), I could continue using it.
What's the motivation for needing to use the FileSync API?
Surely users with Dropboxes that take up undesirable or larger-than-free-space amounts of space are a minority. Is there something about that minority that makes it likely to grow? Is it as simple as "Dropbox will add features to serve customers on paid plans even if those features cripple the experience for users on free (read: small) plans"?
I don't understand why Dropbox has to do all this. Can't they just manage all files by themselves? Just open and close files like any program. No need to use whatever new bs API apple is pushing. This is macos, not iOS. You can still run any turing complete software. Or am I mistaken with that assumption?
Prior to 2016, the dropbox app managed which files were synced with your filesystem, and you could always go into the Dropbox app to see the files that weren't synced.
As of 2016, dropbox started to intercept calls to open/move/delete files at the kernel level – https://dropbox.tech/infrastructure/going-deeper-with-projec... – this allowed them to create proxies for all the files that weren’t synced, and to then download them whenever something tried to open them.
The API they used for that was always intended for Antivirus and similar programs, but it worked. Apple replaced that API with a new one which is a lot more narrowly targeted to Antivirus, and dropbox couldn’t use it.
Dropbox could try and do things without any API, but they’d get themselves kicked off the App Store, they’d need to convince users to turn off 'System Integrity Protection' which would try to keep the OS kernel unmodified, and their implementation would be prone to breaking at any time.
Just managing the files by themselves would essentially be going back to the pre-2016 approach, and the file provider API is better than that.
It seems like Dropbox of today is trying to be a completely different tool than what Dropbox originally was. Their goal is no longer to sync files that reside on a folder on your machines, but instead to store files primarily in the cloud and present the illusion that they reside on your machine. Apparently the Apple API for doing the latter comes with restrictions that make it more obvious that Dropbox has abandoned its original purpose.
Personally, I like the idea of forcing files that don't really exist on my machine to be presented through a different UI and namespace than files that are actually locally available. A complicated overlay mount of a network filesystem and a local caching layer is not something that should be shoehorned into an unsuspecting user's home directory. It's trying to present an abstraction that has too many pitfalls.
Rclone is a FOSS alternative interface (CLI) to many cloud storage providers and provides some neat extra functionality. It has been working very well for me with OneDrive and S3, but of course use at your own risk.
I mostly don’t use it much anymore but is dropbox going to convert all my files to download on demand without me explicitly asking it to? Is it possible to have it keep all files synced by default or do i have to configure this for every file?
You have reversed it. I used to reverse it all the time until I came up with a simple way to remember it. Just think of the mv or cp command, the first argument is always the original thing that exists already. It's the same with ln. The first argument is the existing path you want to make a link to.
I don’t think so, unless you are able to create a symlink from the Library/CloudStorage folder to an external drive. I suspect there are some limitations related to this. But I haven’t tried this specific case. But on advice from Dropbox support I did try to symlink from Dropbox to ‘Dropbox (UniName)’ to avoid the space and parentheses in the folder name. This seemingly worked, but after weeks of syncing problems I capitulated and instead link in the other direction… (this isn’t solving the problem of space in the folder name that some software doesn’t like, but syncing now works at least)
Man.. I really miss Steve. He never would have let this bastardization of the desktop machine operating system happen. The only thing consistent with every new macOS release at this point is the removal of more features I heavily relied on and the addition of ever more iOS transplants that make zero sense in the context of a desktop computer.
Tbf he was willing to break things and not provide backward compatibility forever, which I think is great if you want to keep innovating and keep improving things at your layer. It works as long as the layers above keep adapting, which so far they have done
It’s not 2007 anymore and Dropbox isn’t a plain “rsync GUI” anymore. It’s been obvious for years now that they don’t care about technical users so we should not use it anymore. I probably moved on in 2017.
Agreed. I use Syncthing[1] and it's great. It just sits in the background and works like Dropbox used to. If you have a NAS or some other always-on machine it acts as a good master for syncing things.
This API is hamstrung and limiting, full of instabilities and quirks (designed to fit iCloud primarily but not necessarily everyone else).
In my opinion, the fault lies with Apple here.
[1] https://developer.apple.com/documentation/fileprovider
(Full disclosure: I interned at Dropbox for 3 months 8 years ago.)