For context, let me first say I’m a long-time user of DEVONthink, and have gone through a number of iterations of trying different configurations. On a daily basis I use a phone, an ipad, and (just recently) a high-end MacBook with multiple external monitors; previously I also used two iMacs and another “emergency” old MacBook, all of which which I tried to keep sync’ed [1][2]. I have a couple of databases in the 20-30 GB range, and a couple of others that are smaller.
For a time, I used one of the iMacs at home as a sync store, and used WebDAV for sync’ing the other devices to it, without a cloud-based sync store. This worked until one day I was at a doctor’s office with only my ipad and wanted to pull up some recent records and couldn’t, because while I remembered to sync my main computer to the sync store, I forgot to follow that with also sync’ing the ipad before leaving the house. This convinced me that I needed a cloud-based sync store.
I then used Dropbox for some years, paying their high price for far more storage than I needed because of their pricing scheme. A couple of years ago, I stopped that for multiple reasons and switched to using the iCloud (CloudKit) solution provided in DEVONthink. I have been happy enough with iCloud sync. I pay for Apple’s 200 GB plan to have enough space to put all the databases there. The main downsides to iCloud for me have been:
- Inability to get meaningful diagnostics or status updates about what is happening with transfers over iCloud. (This was mentioned upthread.) Sometimes you wonder why something hasn’t sync’ed yet, or when it might finish, and there’s nothing you can do except wait it out.
- Seemingly slow transfer speeds. I can’t be sure if iCloud can be blamed because I can’t do a proper head-to-head comparison with anything else; maybe Dropbox was that slow too and I’ve forgotten. It just seems really slow sometimes. This was mentioned by other people upthread too (e.g., here).
- On 2-3 occasions, it has happened that the databases on the ipad and iphone stopped sync’ing properly; the symptom is that I could see documents that should or shouldn’t be there, despite leaving plenty of time to account for point #2. I ended up having to blow away (“clean”) my sync store contents, re-upload from my main computer, and re-download all databases to the other devices. It’s not completely clear where the blame lies (iCloud/CloudKit or DEVONthink) but I mention it in this context because the problem can happen with this combination. Thankfully, the solution of cleaning the sync store has always worked, so this problem is mainly an inconvenience (albeit a big one).
Whatever approach you choose, I would encourage doing the following:
- Work through, on paper, the scenarios you want to support. This can be surprisingly challenging. Let the initial plan sit and revisit it after a few days to look at it with a fresher perspective.
- Create test databases, and test your candidate approach(es) – don’t assume they will work as envisioned.
- Use realistic database sizes in your tests (even if you have to fill them with random junk), not just a couple of documents or something like that, so that you get a proper test. Some things look fine when you have a database with 10 documents in it but become problematic when you have 10,000’s of documents.
Finally, as has been mentioned countless times in this forum, having a sync store – of any kind – is not the same as having backups. I use both Time Machine (for hourly snapshots of my whole computer) and Arq (for daily off-site backups to an old Linux computer I set up as an SFTP destination elsewhere). So, when planning the mix of computers and devices and sync approaches, it’s worth thinking about which device will be the one getting backed up.
Footnotes
[1] This required multiple DEVONthink licenses, not just 1.
[2] No longer using one of the iMacs because the new laptop is so powerful that it has become as my main workhorse computer. As for the emergency mac and the extra iMac, some further analysis of use cases and emergency scenarios made me decide they were not worth the maintenance time required.