There are, from how you describe things, better ways to do what you are currently doing, in my opinion. Most of the techniques that I’ve refined for that process are written up in this FAQ post. That’s going to go into much more procedural detail than the user manual. To be clear, this is the method I use for all project syncing, not just mobile (I rarely use mobile).
This method is rock solid safe, works with any technology no matter how poorly designed, comes with no advisories or disclaimers or checklists that you have to keep in your head all of time to “sync safely”—it is very resistant to user error, even allowing you to make mistakes and forget to keep yourself up to date, retroactively fixing them.
The article is largely framed around using two standard computers, not mobile, but the principle is the same. The main difference is that the iOS version has no automatic backup, so that part is manually done. That’s not as big of a problem as you might be thinking though.
So the main advantages of that method over what it sounds like you are doing:
-
When set up right, all standard computers automatically update the “latest project” pool, or the backup store. That part you don’t have to remember to do.
-
Backups are date and time stamped. There is little ambiguity about over which is latest. Your “transfer stack” is kept tidy for you.
-
This includes iOS backups, so long as you save them from the project manager. It will use a different naming convention, but that isn’t generally an issue.
The best way to do this is to tap the Edit button in the project manager screen, select the project, and then tap the Share icon to send a copy to your preferred sync service, or to Files.app in general. That’s it, a few taps. You can also do this from Files.app as well, as it can compress to zip and you can drag things around, but that’s way more labour intensive.
-
If do make a mistake, it’s not the end of the world. More on that below.
I can use a file server, but then I have to remember to close the document on computer A before opening it on computer B and vice versa (right?). I’m not that perfect and not that disciplined. That sounds scary.
I mean, you’d have to do that anyway. Synchronisation is not magic that solves design limitations in all software, it’s just another kind of file server, a really slow one. It works by keeping multiple machines in disk parity with one another, mitigating local access speeds, but everything about the state that is shared between computers is the same as if they are all sharing the same physical storage medium directly.
Local file sharing between devices is what I use for many things, it works fine! If you forget and leave the project open, you’ll get a warning, no big deal.
The main argument for using a third-party to store your data for you is so that you can roam. So that you can leave the house with your laptop without having to remember to fetch the most recent copy from the other computer. If you aren’t roaming, there is no reason to use an intermediary. I use the alternative sync method for roaming and file sharing when I’m home.
I can manually copy my documents into iCloud Drive (from local storage) and back. That works, but again I need to remember to open and close things with discipline. It’s also annoying.
The technique is actually very good at bouncing back from making mistakes like this. It’s one of the safest approaches not only because of its simplicity at the technological level, not only because most of the stuff to remember is automated, but also because it is resilient to us making mistakes. And for me anyway, that’s the far bigger concern (I am a space cadet; one reason I do not use live sync!).
With live sync, if you make a mistake the mistakes all go back to the same central storage spot, and that can be catastrophic in some scenarios.
Say you make that exact kind of mistake using the “backup stack” approach. You get home, make some coffee and sit down to your desk, fire up the desktop and think of some things to add to your project. One thing leads to another, and 30 minutes later you realise you didn’t update this project before opening it. Maybe it’s even still open on the sleeping laptop.
Built into Scrivener is an internal sync system that compares two copies of the same project and reconciles their differences. It’s based on the same sync engine principles that keep the iOS edits in parity with the desktop project. In the above scenario, you’d simply grab the latest copy of the project that came from the laptop, open that project on your desktop, and select and merge your divergent copy on the desktop into it. You can then discard the copy you accidentally edited before updating. Easy.
This scenario is meant to convey the peace of mind and lack of stress you can achieve when working this way. In my experience, this workflow becomes a habit rather quickly and you won’t be recovery much from mistakes. I still do, to be sure, but it doesn’t really matter, because we can hardly think of them as mistakes when there is an dedicated feature set for merging divergent projects back together. This feature is robust enough to allow you to distribute copies of a project to six or so collaborators, with everyone working simultaneously, gather their work, and merge all of them back into a master project safely. It’s designed for that very workflow we call a “mistake”.
It can take your 30-minute oops-session. I wouldn’t want to depend upon it as my primary workflow. It has more steps involved, more complexity, but I don’t feel I’m in a dangerous place if I mess up.
So in case it isn’t clear: while it is true you cannot open the same exact project more than once—you effectively can work on that same data simultaneously, safely, so long as each instance is a separate physical copy of the project (which is something that happens naturally if you aren’t live syncing).
See how this is safer than live syncing, even setting aside the complexities of technology? The mistakes you can easily make with syncing can be catastrophic because every device is manipulating the same data. That same human error with physically different copies isn’t even a mistake: it’s a workflow that other people use for routine collaboration.
Scrivener already knows how to carry history inside its documents - that’s how Dropbox sync works, right? Why can’t it take a transferred copy (say, something I airdropped over) and say, “Ah, I see these are two versions of the same document, let me unify them for you, okay?” and do the same thing it does to Dropbox-synced files? You know, the “here’s what got changed elsewhere” and “I’m going to rebuild the index now” routines?
So there you go. It’s not quite like how you describe it; Scrivener doesn’t “store a history” as you put, but it gets to the point you’re looking for. Here’s the details: §5.3.2, under subheading, Merging Projects Together, and the following section on Merging Changes from One Project into Another.
I don’t want to rehash the “why can’t we sync through iCloud Drive” discussion…
That isn’t true, wherever you heard that from. But there may be some confusion over the difference between “iCloud” and “iCloud Drive”, specifically with regards to iOS users looking for something in Scrivener itself. For everyone else though, use iCloud Drive if you want, including iOS users if they use the alternative sync method.
There’s the mysterious “external sync folder” thing that I’m strongly told is not right for me. So I’ve never looked into it deeply. Should I?
You’ve heard correctly. That tool is for integrating Scrivener with other software, whether on your local machine or remotely. There isn’t enough information in it to sync project data, and the way in which it addresses data is project-specific. Therefore two or more projects trying to share one folder would damage each other. So don’t even try it. You will get dire warnings if you do. Use this if you want to use a text editor on the go, like Obsidian, rather than Scrivener.
So that’s my thoughts on the matter. Are we trading convenience for safety? Absolutely. Nobody is going to argue that copying is more convenient than syncing. But I would like to close with one last statement to that effect: if the convenience is for you a “deal breaker”, if you simply cannot stomach living without convenience, then Dropbox does not need to be part of your question. Lots of sync services are safe—most of them are. Some need care in setting them up correctly, but if your main question is “what can I use other than Dropbox”, this whole alternative sync approach is most certainly not the only answer. That’s a personal workflow choice—one that I would make even if I were to use Dropbox.
While I don’t do it myself, for all of the reasons I’ve given above, I could very safely use Tresorit, which is my preferred sync provider. I’ve tested it, and it handles live project syncing flawlessly, under heavy usage. Just keep an eye on the cloud sync section of our FAQ for any advisories and avoid those services we advise avoiding (really only Google Drive is on the do-not-ever-use list).
