I just started using Scrivener a couple weeks ago and it is fantastic. Prior to using it though, I did research that syncing issues with iCloud and so on. I am in the Apple ecosystem so this is a concern for me.
But I am in the trial phase so far (although I will purchase Scrivener - it’s great) and I tested it out with iCloud.
Here is the thing: the forums here suggested to use Dropbox as a sync. I thought, why not use iCloud Drive. It is essentially the same as Dropbox. It is not iCloud syncing - as used by other apps, notably Pages, Numbers, etc. Rather, I use iCloud drive to sync the Scrivener file.
This way I have been able to successfully “share” the file between my iMac and MacBook Air. I can work on either device and save.
The one key, and it is absolutely critical, is that I close the Project on whatever device I am working on.
I don’t think iCould sync is a necessary investment for the developer (KB I think). iCloud Drive works just fine.
Make sure the project is closed and fully synchronized on system A before attempting to open it on system B.
Avoid all forms of “smart” or “optimized” synchronization. The entire contents of the project should be stored locally on the system where Scrivener is running.
Thank you for your response. I understand. I was simply trying to add some more experience to Scrivener / sync with Mac OS. Because before I bought Scrivener, this sync issue was not clear anywhere I looked. I just want to ensure that people know that Scrivener can sync with iCloud Drive (in the same way that Dropbox works).
If I had seen something like that on message boards, etc., a lot of confusion could have been avoided for me.
There is a distinction between iCloud Sync and iCloud Drive. That is all that I was trying to address.
I recall a post in the last week, by the Scrivener folks, which explains how they exploit features of Dropbox that do not exist in other third party cloud syncing services, e.g. Apple’s, Google’s, etc.
If Apple’s syncing works for you, great, but hopefully you’ll be able to detect the errors when and if they happen.
Me… I prefer to spend my time thinking and writing (in that order, preferably) and stick with what Scrivener recommends and is designed for. Just me.
I have been using iCloud drive (to sync between a macbook and an iMac) for years, without problems.
I have found the “auto-close project” setting super useful for this, otherwise sometimes forget to close the project and that’s trouble. But have never run into any difficulty with it.
Again, this observation is only relevant to iOS Scrivener, which uses the Dropbox API directly. With Mac or Windows, Scrivener simply saves to the local file system and is not aware of Dropbox at all.
I’m not sure what that was in reference to, but it was probably iOS-specific: as in the Dropbox API is extensive enough to make it possible to build a mini-client of sorts, which is what is needed for larger scale directory tree syncing. This capability was either absent or essentially too difficult to be feasible, in other systems.
They are not at all relevant to normal usage of the sync client on desktop systems. Scrivener is entirely oblivious to any of that (as it should be), Desktop syncing works by keeping the local file system up to date between systems, and that’s it. How software reads the local system is identical to how it reads from any other folder.
As for iCloud Drive, we have no evidence that it is particularly unsafe to use, and in fact most sync services work just fine. Any other considerations between services largely have to do with unrelated reliability and speed factors, i.e. stuff the impacts everything, not just Scrivener.
Me… I prefer to spend my time thinking and writing (in that order, preferably) and stick with what Scrivener recommends and is designed for.
This is also a bit of a myth that keeps getting spread around. We don’t “recommend Dropbox” as a statement that excludes or demotes other services.
By looking at the Scrivener project itself. Does the .scrivx file match the actual contents of the project? Is there more than one file associated with a given document ID? Etc. Scrivener doesn’t know (or care) how the conflict was created, just that it exists.
Now, Dropbox knows when it has created a conflict. Which it defines as “both the local file and the file on the server have been edited since they last matched.” It then flags the conflict by keeping both versions and renaming the affected file(s).
Scrivener, in turn, says, “there are two versions of this file,” and flags them for the user.
But this analysis takes place entirely by looking at what is stored in the file system. There’s nothing Dropbox-specific about it. Other services that flag their conflicts in a similar way will be handled the same way by Scrivener.
Conversely, if you had a service that purported to resolve conflicts itself, and left only one version of the file, Scrivener would have no way to detect the error.
(And since the thread has meandered on for a bit, I want to re-emphasize that I’m talking strictly about Mac/Windows Scrivener, not iOS Scrivener.)
To be fair, L&L sends out a diverse range of signals that could be interpreted in multiple ways. E.g. “pro” Dropbox:
“There are many cloud-sync services available but one that works well with Scrivener is Dropbox.” Source
in combination with “contra” Google Drive (in this case):
“Google Drive cannot be trusted with live Scrivener projects. While it is unlikely to be contributing to this specific issue, it is known to cause unrecoverable data loss in some situations. Please choose an alternative service.” Source
If I had to recommend one of the big players (Dropbox, Google Drive, iCloud, OneDrive), that is the least likely one to cause trouble with out of the box settings – which one might it be?
If I had to recommend one of the big players (Dropbox, Google Drive, iCloud, OneDrive), that is the least likely one to cause trouble with out of the box settings – which one might it be?
I wouldn’t say it’s necessarily clear-cut, Google Drive aside for obvious reasons. The best answer would depend upon a variety of factors. Dropbox is a good choice if you intend to use iOS and live syncing is something important to you. Otherwise I wouldn’t say there is a strong reason to choose it. The other two have the advantage of already being installed (and rather impossible to uninstall), so there is that.
Myself I wouldn’t choose any of them though. I think there are better choices for those willing to look into them.
I’m another user who has synced Scrivener across numerous Mac devices using iCloud Drive for years without issue.
If you’re a Mac-only user who already has iCloud Drive running, it makes sense to use it, doesn’t it? If you add another cloud provider unnecessarily, that’s another service using computing and networking resources that might cause conflicts, sluggishness and crashes.
The fewer calls on the device the better, as far as I can tell. Think multiple sync services can easily trip each other up. If @btrivedi1012 is a Mac-only user and is happy with how iCloud Drive works, there’s no need to add another sync service for Scrivener.
I think in most cases you should be pretty safe from that. Most sync services create their own user folder level area for syncing, rather than putting it into an area that even those using the more expansive iCloud Drive options would bump into. Plus, all of this assumes one has enabled the opt-in iCloud Drive stuff to begin with. I don’t know how well Apple shuts down the internal mechanisms if no logged in user isn’t actually using it, but if you aren’t using it, then the overhead should be very minimal, leaving plenty of resources for whatever else you want. If you aren’t keen on using iCloud, you shouldn’t have it enabled it anyway.
But yeah, specifics aside, that’s all part of why I think there is reason to consider other options.
My thinking and experience jumbles through:
← → more apps running
← → more processing power and threads being used
← → more memory being used
← → more home-network resources being used
← → more ISP resources being used
← → more electricity being used
← → more ports open or being used by more services
← → more companies getting access to my Macs
← → more snooping by the above
← → more heat coming out of the Intels
← → more the fans spin up
← → more distractions from the noise of the fans
← → more competition between the apps
← → more drain and strain along the chain
← → more risks of conflicts and crashes
← → more risks of data being lost (Dropbox in particular, from my experience)
← → and more risks of user error
← → all possibly leading to less performance and productivity.
For me, the fewer apps (and the fewer sync services) the better. Less is more.
I think a lot of Mac users use iCloud because of its ubiquitousness throughout the OS. Enabling iCloud Drive seems to be pretty normal, so if it’s already running and working well, why would anyone want to add another cloud service into the mix unless it brings something radically different to the table?
A free tier of service still involves all of the issues mentioned above. And in many cases, another sync service leads to additional subscription fees.
Think it is good for people to have choice, and think the OP has made a good choice if iCloud suits their needs.
Maybe because it’s not always working well. I don’t even like Dropbox and for all the good reasons you’ve listed would rather sooner than later — well, drop it. But it “just works”. iCloud Drive on the other hand… too often acts like a diva.
I think we’re talking at cross purposes here. That entire checklist pretty much applies to iCloud Drive as well, if you choose to enable it. If you don’t, then you move that checklist over to another set of processes—which may very well end up being more efficient at doing what it does than Apple’s system. For instance, I found Resilio Sync to be one of the most efficient (in resource usage terms) ways to keep file systems in parity, and in particular it allows you to sync whatever you want, wherever it is, rather than having to move (or symlink) everything into one mammoth central folder.
