I’ve played with Scrivener on Windows a bit over the years, but never made the commitment. Now I’m on Mac - Windows, with its current privacy-invading practices, is no longer my OS of choice - and am making the jump to Scrivener for all my longform writing. (Scrivener looks better on Mac, too.)
As I also have an iPad, I looked into the syncing situation. Did the Dropbox thing as per the instructions, found it trouble-prone, gave up on it. I read all the L&L articles on sync, esp about iCloud. I’ve switched my sync process to iCloud, making certain to check the “Keep downloaded” option on both iPad and Mac. I also use the Scrivener backup function to back up my files to Proton Drive. Sadly, Proton Drive does not currently integrate with iPad OS, or I’d be using that. (As you might understand, already having two cloud services, I wasn’t looking to add a third with Dropbox. Too, Dropbox does not have end-to-end encryption unless you’re on a teams account, which means anyone at DB or with access can view your files. Being a US-based company, this is a concern that I’d prefer not to undertake.)
I go one step further, just in case iCloud hoses something: on iPad, I don’t work directly with the .scriv file in iCloud - I make a copy of the version on iCloud, and paste it into my working Scrivener folder “On My iPad”. I.e. local copy. When I finish, and if everything looks okay, I copy the local file back to iCloud.
This is my long-winded way of getting to my point delineated in my post title: will there ever be a native sync function in Scrivener? I’d gladly pay a few dollars a month for such a feature. What I’m thinking of is something like how native sync works in Obsidian - I’ve used Obsidian Sync for a year now in that app, and it has worked flawlessly. Something like that for Scrivener, perhaps? I know it’s probably pie in the sky, but I figured it was worth a shot to ask. Thanks.
I believe there is an irreconcilable conflict between Scrivener projects (.scriv) and the way Apple’s current Cloud services handles synchronization. Apple synchronizes everything incrementally in slices, whereas Scrivener projects require the complete synchronization of every file inside the .scriv project at the same time. I don’t know how this should be resolved; perhaps L&L support can provide an answer. Personally, I have decided to use Scrivener locally and avoid placing projects in any folder that syncs to the Cloud. If I need to move projects, I do so via an external drive or a zip backup file. Just my opinion.
Actually, the problem is that iOS/iPadOS is totally sandboxed, so an app can only work on data within its own sandbox; MacOS (and presumably Windows, etc.) is not sandboxed to the same extent.
This means that the desktop OSes can work with pretty much any cloud service. By contrast, iOS/iPadOS can only do full synchronisation with a cloud service that provides the developer with an API that will copy data backwards and forwards between the app’s sandbox and the cloud service folder.
To date, as I understand it, only Dropbox provides the necessary API. You can do the same manually, by copying the project back and forth between the Scrivener sandbox (“On My iPhone/iPad”) and iCloud/Sync/Box/whatever in the Files app, but it’s down to you to manage versions.
I believe there is an irreconcilable conflict between Scrivener projects (.scriv) and the way Apple’s current Cloud services handles synchronization.
It depends more on the service than the concept, you could find better. I’ve never had a single problem with the one I use (Tresorit). But then again it actually syncs files between systems normally. It has none of the dubious “smart sync” stuff that causes such a mess overall, nor Apple’s weirdly over-engineered local storage approach (which other mainstream options use, and suffer for it).
There is a lot of unnecessary mystery in how people think of Scrivener projects. I am not sure if that is what you are implying, but the simple fact of the matter is that a project is no more complicated or difficult for something to sync than any other folder with text files in it. As I have long said, if your sync service struggles with that then ditch it, it’s useless junk.
As for inventing our own sync service from scratch and hosting other people’s work, we’ve stated many, many times at this point that we have zero interest in that field of development. Please search the forum if you need more of an answer than that. We just want to make writing software. Pair it with a decent sync service and you should be fine. This tech was invented specifically so that every single developer did not have to reinvent the wheel.
Yes, a Scrivener project is a file package that can contain thousands of text files. It can be located anywhere—locally on a Mac hard drive or, for instance, in a folder that synchronizes with a cloud service. Perhaps I shouldn’t be writing about this, as I don’t know how Scrivener is built up, but as I understand it, Scrivener has no way to programmatically verify the project’s up-to-dateness, since the project can reside anywhere. Consequently, it is entirely possible that a specific file within the Scrivener project has not updated by the time Scrivener opens the project, leading to mismatch issues. This problem cannot be resolved as long as the project is not located on a service that allows Scrivener to programmatically verify that every file passing through the cloud service has been updated. Just my thoughts; hopefully I’m wrong.
Just out of curiosity, is the method by which iCloud syncs things like Apple Notes and other apps’ data not somehow adaptable to Scrivener, or vice versa? It does seem like a completely different structure in that there is no readily accessible local file for one to open, copy, etc with apps that use that sort of iCloud sync. And many apps use it simply to sync settings across devices. Is that sort of sync not available to Scrivener?
The thing is, none of those apps are like Scrivener with its network of interlinked files where, in my experience, making changes to a single text document can result in changes to half a dozen other linked documents. And since they are saved every time you pause for however long you set, those files have to be updated on the server.
That’s fine on non-strictly sandboxed desktop OSes, but is a problem for iOS.
Scrivener works fine with services that do incremental sync. Indeed, the whole point of our “package” format, rather than a ZIP format, is to allow individual file updates.
Currently, the vast majority of sync issues that we see are related to “smart” synchronization, in which the service stores a file or files exclusively on their server.
You can see issues if the .scrivx file used to build the Binder does not match the actual contents of the project. However, this is (1) rare with modern internet connections and (2) something that Scrivener 3’s error checking can identify and fix. The vast majority of the problem reports we are currently seeing do NOT involve this error.
I suspected that would be the case, and totally understandable.
I realize the iPad version has not been updated for a while. When next it is, might there be an option on the sync screen to link with services other than Dropbox? For whatever reason - and I tried a lot of troubleshooting, including multiple uninstalls and reinstalls of DB - every time I opened Scriv on iPad, the app complained that it had to relink to DB. Additionally, DB in the iPad “Files” sidebar continually showed a sync circle with an exclamation mark in it. I tried all the troubleshooting remedies, to no avail. That, coupled with DB’s lack of E2EE, chased me away from using it.
I did not intend that meaning. I may have been slightly unclear before, since I did not claim cloud services cannot sync individual files inside a Scrivener project; they can handle that. My point was that the entire Scrivener project—every file inside it—must be downloaded and up to date when Scrivener opens it from a cloud-synced folder. As a result, changing even one letter in the writing requires every file in the project available locally. This can cause problems because a Scrivener project may hold thousands of text files, and a cloud service might be slow to refresh them, even with the “keep always on this device” setting turned on. For this reason, I use Scrivener solely with projects kept on local storage. Thus, managing a Scrivener project differs in a basic way from how some other applications treat documents, but that is all for now. Wishing the Scrivener team continued success and well-being.
FYI, I find that with small changes in Scrivener, even Dropbox (which has worked well for me for years and years) goes very quick.
Can’t say for other third party sync services.
If you can’t over-come the lack of encryption with the “free” Dropbox account, perhaps use another writing tool on computer or not for those projects that you need to try to hide.
This is why, whatever your cloud service, you need to set Scrivener projects to be available offline. Do that and your biggest problem will be “pilot error” of putting your computer to sleep or shutting it down too quickly after a Scrivener session, resulting in the cloud service not having time to sync fully, in particular not deleting the user.lock—the last operation.
iCloud, from my experience is slow to erratic in it’s sync’ing, and further has the disadvantage vis-à-vis Dropbox or Sync—I don’t know about Tresorit or any others; I use Box, but not for .scriv—of not having a menu-bar icon making it easy to observe if sync’ing is complete. You have to have the relevant folder open in Finder to see the status.
If you are worried about Dropbox or Box and security, try Sync.com. I’ve been using it for years… based in Canada, end-to-end and fully encrypted so they can’t access your data.
Thank you for the details. I use Scrivener only for local projects on one Mac, and I am content with that setup. When I write elsewhere, I rely on other lightweight writing apps and later merge the changes into the Scrivener projects. I do not fully grasp why people strongly desire to sync full Scrivener projects between laptops and desktops, as I have no such need. If I wish to review my work, I typically export it as a PDF, annotate notes with an iPad and Apple Pencil, and transfer them into Scrivener manually. That approach may be less efficient, but I prefer it because I have never faced problems this way with Scrivener or other writing apps.
I once had a paid 2TB Dropbox subscription and used it to sync Scrivener projects, too, but I found little use for it; in truth, I did not need Scrivener across multiple locations. I still retain 2TB of iCloud, 1TB of OneDrive, and 2TB of Adobe Cloud. Those three services remain on my two Macs, and I need at least OneDrive and Adobe Cloud. I have got the OneDrive through the Microsoft 365 Subscription. I store final drafts there, need it for my employer, too, and it works well with MS365 because it is optimized for Microsoft documents. I might reduce the number of cloud services, but removing the OneDrive and Adobe Cloud is difficult.
The only time I have had an issue with Tresorit and Scrivener is when I have committed, as you put “pilot error”. I passively use it for all kinds of projects, simply because I have it uploading most of my user folder in the data and configuration areas. So in some ways, my use of it is similar to yours AnotherGuy, where I mainly just use it from one machine as a third level “backup” (on top of two different locally created daily backups).
In fact, Tresorit on Mac does indeed have File Provider support (the basis of much ills it seems, of late), though interestingly it seems to handle it much, much better than others like Dropbox—in part because it doesn’t even try to do the smart sync thing. Once you download a project it stays fully downloaded always. What I saw about it that I don’t think others do is that when you double-click on a project, it waits until the whole thing is downloaded, before opening it. It seems from reports around here, Dropbox just fetches the outer folder, and maybe the .scrivx, and falters on the rest unless you specially configure it to be “offline” first.
So this is why I say, to a degree, that I don’t feel it is a problem with Scrivener or its format. It should be considered up to the sync service to provide your files when you request them, and on a Mac that means providing the entire folder from top to bottom when the top level folder (as a “package”) is requested. The matter of a partial download shouldn’t even be a concern if the service is good, outside of again “pilot error” where you stop syncing manually somehow (sleep, etc.)
For me, the real issue is that I collaborate with a friend on Chinese <–>English translation, so both of us need to have access to the complete .scriv (furthermore until recently she was a Windows-user but has moved onto a MacBook Air). We use Sync, because DropBox is blocked in China.
For my own stuff, I take my MBA when I’m on the move. I tried using Sync with external folder, but found I much prefer having the whole project for working on.
Mark
P.S.
A further “advantage” with Sync, is it doesn’t use File Provider, just uses its own dedicated folder wherever you put it—default in your Home folder.
Yes, that’s the default way Tresorit works as well—or sort of. If you’ve ever used Resilio Sync, it’s a bit like that. It goes a step further in that you can select any folder to sync with (either fully or selective), and have multiple such sync folders. So I can set it to sync Application Support, for example, into one “tresor” as they call it, and my archive folder to another, working folder to another, and so on—and then on another system I can subscribe to these individual sync folders and link them to local folders there. Thus my Scrivener folder in Application Support on the Mac can be wired to the Scrivener folder in the AppData location in my Linux Wine (or Windows) installation, making my templates, compile formats and other settings available everywhere.
Of course if you wanted something simpler, you could just make one sync folder and attach all of your systems to it, giving you the classic cloud folder sync experience. But I’m going to take complexity like the above if I can, because the alternative in other systems usually meant a mess of symbolic links pointing to the things I actually wanted to sync from outside of the monolithic sync folder.
The File Provider support it provides is a toggle you can turn on, which (on top of the above rather than as a replacement) mirrors all your sync tresors in an “offline until loaded” fashion, and places it in the Finder sidebar like other FP-oriented services do. So it’s really more supplemental to the core syncing.
Quite a nice service, especially if one is interested in Linux as the client for it is quite good there as well (it doesn’t have File Provider of course, but it uses a similar kind of technology on Linux to provide that supplemental all-access super folder that doesn’t take up drive space, if you wish it).
Yes, the one thing I miss is having separate folders on my Mac sync’ed to the server. That’s what I’ve missed since the demise of Cubby.
But I’m set up now with Sync. If I remember rightly, I have 2TB space for roughly what Tresorit charges for 1TB; Sync have changed their pricing so new sign-ups can choose 1TB for $6/month or 5TB for $14… I’ll only know for sure when my account comes up for renewal in February!
Essentially, for me, my Sync folder is really my Documents folder… I hardly use the latter at all. So I don’t feel the need to change service for that one feature.
Mark
Yes, of course, thank you for the reminder, Mark. I was simply curious about project file format options. As the problem with iOS/iPadOS sync comes up so often with those updates to files within the package not being ‘picked up’, might it not be possible to find an alternate package format that avoids that issue on all the various sync services? I’m merely curious about the possibility. All of these things are being done for the first time; we don’t have the benefit of 500 years of programmers’ experience behind us all during which a best format for this use case was invented and refined and became widely recognized as best.
The solution is for the sync services to figure out how to synchronize folders correctly.
It’s really as simple as that. The services with the worst results are the ones that try to offer “added value” beyond the basic task of sharing data between Computer A and Computer B.
Using a ZIP format has been discussed in the past, and was even tested in some early internal versions of Scrivener 3. Giving that a Scrivener project can be well into the GB range, though, that approach turns out to be disastrous for performance.
