Well, don’t get me wrong. I certainly appreciate to hear about workarounds that may help to keep on writing and syncing.
However, for me the main issue is: It worked perfectly before, even with 15 project files in the sync directory but with iOs 13 something has changed that is crashing the process. I still hope the developers find the issue since a manual transfer works fine but is painful. I was looking for a way to script the process, using the new “Shortcut” App but it seems it has no file transfer procedures. All I need is an iOs script that copies my project files from iCloud into the scrivener directory on the iPad and back. I keep on trying …
Not so much. “Works for me.” Doesn’t really add anything to solving the issue unless you can diagnose ‘why’ it works for you.
Essentially, you’re tone is saying it’s not an issue, which is false. In fact, this should be a priority 1 issue as it cripples the entire functionality of the app for the users experiencing it.
On a lighter note, I really like your username: Lunk. It’s a great character name. 
If it would help, I’d be willing to donate a project that won’t sync. It’s from an already published work.
If it works for 90% of the users and not for 10% the interesting part is what it is that differs between the groups. Initially it was suggested that older devices worked and newer didn’t. That turned out to be wrong, when owners of newer devices who did not have problems did report that.
Since a fix may tale a while, I have to move forward since my work cannot wait …
Although it is not recommended, I’m using iCloud to sync.
Choosing this way, it is important to watch the project files completing to sync on iCloud once updated on the mac.
Recently, the visibility if a project file has been synced completely has improved.
Still, copy files manual (by hand) from the iCloud into the Scrivener iPad directory and back, is a pain.
I was therefore using “Shortcuts” with help from Siri to automate the process and testing it right now, so it is experimental.
I figured out, if I chose shortcuts to copy a project file, which is not yet completely synced, icloud will first copy the project once completed. To prove that, I was choosing my largest project file (450 MByte) to test it out.
For those of you, who want to take a look how that works, I recorded a short VDO on my iPad.
The process starts with "Hey Siri … Projekt kopieren (copy project).
With only a fey interactions, I get the project synced,
A similar shortcut is required to copy it back to the iCloud.
If the file already exists, a dialog is showing the option to overwrite or to keep both files.
The VDO starts with an empty project list. At the end, the script is opening Scrivener again, rebuilds the search index (only once) and shows the project completed.
It’s not perfect and the user is still in charge to control the whole thing, but better than nothing for now …
https://youtu.be/O7F33XK-O0M
I am having this same Dropbox crash with Scrivener which started immediately after the first iOS 13 upgrade, BUT only on my 3rd generation iPad Pro 11”. The syncing continues to work without a hitch on my iPhone 6 Plus and my iPad Pro 12” second generation. I tried unlinking/relinking Dropbox; deleting/reinstalling Scrivener from the iPad Pro 11”; deleting Dropbox and Scrivener. The result is I cannot sync my iPad Pro 11” with either the iPhone or second generation iPad Pro 12” even though the iPhone and iPad Pro 12” continuing syncing with each other correctly.
I hope this information contributes a piece of the puzzle that helps solve this problem.
On my iPad Pro 9.7 inch with 256 GB, it works fine. On my iPhone Xs max, also with 256 gb, it doesn’t work even if i switch folders. It looks like its working, and then it doesn’t. I have decided simply not to use it on my iPhone until there is a fix. Not that crucial, although slightly annoying, that I give up on iPhone as long as my iPad continues to work.
Hi Thomas, thank you for your efforts. I’ve also been doing the whole copying through the Files app thing manually since it stopped working at the 3rd week of September. On one hand I think it’s really annoying that this has been going on now for a month and a half, on the other hand, it proves that the iCloud copying (it’s not the same as iCloud Sync) works reliably, quick and transparant. This was not the case in previous versions of iOS.
It makes me doubt about just doing that as my default and leaving Dropbox for what it is. BTW, my projects sometimes go to 1-10GB (10GB is the biggest one) and they all have been uploading quickly and reliably. Both from an iPhone 8 Plus and an iPad Pro 11", and a 2015 iMac.
What I wanted to ask is: you put on a command and it started copying a project. How did it know which project to copy? It just took the most recent one? I don’t think your shortcut is a good option, because my projects are now not all together in a Scrivener folder anymore on my iCloud Drive, which would make it more difficult to make an automated shortcut, but I’m curious. Thanks again!
Hi,
Well, the shortcut is not picking a project file by itself, it is user controlled. In other words, I select the project from the dialog and then the shortcut copies it into the Scrivener iPad directory. So it is not fully automated but just supposed to make the copy hassle a bit easier.
Greetings,
Thomas
I would here share an observation about this important bug.
Since the failure and in waiting for the fix, I choose a method to continue working on the go. When crashing, I delete the Dropbox’s file for sync my Scrivener project and create a new one. So I sync only the project in progress and one by one, I can wait three or four day after adding a new one in sync file. When crashing I repeat all the process.
I notice that :
– The project causing the crash not depending on his weight. The same project could causing the crash today and not the day after.
– The most remarkable thing is that, when crashing, on Mac, I slipping out my projects from the sync file and… On the IOS the sync doesn’t crash anymore and the project causing the crash is correctly sync. But of course it disappear at next sync because not more present in the cloud.
I started a new post as my issue seems slightly different, but perhaps connected to the same bug. But, I’m adding it here, too, hoping maybe they’ll get this fixed, or maybe someone following this thread would have some insight.
I am running iOS 13.2 on my iPad Pro 12.9 inch (from 2017, I think…).
When I tap the Scrivener app to open, I get the beginning screen (black with the Scrivener S) and then it shuts right off. I can’t even get Scrivener to start.
I’ve tried restarting my iPad a couple times, double checking the updates, but I’m not getting anything. My family has file sharing open, so even though Scrivener was purchased under my wife’s Apple ID, it should still work on my iPad (other apps purchased under her Apple ID still work fine).
Just letting everyone know that we are working on this behind the scenes. It’s fairly frustrating, though, in that we haven’t yet been able to find a clear reproduction case. It’s not project size or hardware-related: some people are fine with huge projects on older hardware, others get consistent crashes with moderately sized projects on Apple’s newest toys, and vice versa.
Reducing the number of synchronized projects does seem to help. But the issue seems to be related to the number of projects, not their size or contents.
Katherine
Thanks for the message, Katherine. To add a data point, I have 12 projects in my Dropbox folder. My smallest 4.5 MB (template), my biggest 10.27 GB and a total space taken by the 12 projects of 20.24 GB.
The issue I was having seems to be solved. I logged into the Apple ID we shared, deleted the app, and the downloaded it and synced. It seems to be working. I do have auto sync off. I have not typed anything or synced anything, so I don’t know if it’ll shut down on that yet. I’m leaving with this small moral victory over technology from a not so tech savvy person 
Does reducing the number of projects help?
Katherine
I haven’t tried troubleshooting and testing, so I can’t answer on that yet.
I had previously moved all my projects to a new folder, then moved them back one by one. One project caused the crash problem, so I moved it back out and continued moving my other projects. I was able to sync all my projects except the one “problem” project, so I assumed the problem lay with that project. Unfortunately, that project is my main WIP.
After reading this, I created a new folder and set up Scrivener to use it as the sync folder, but this time I moved the “problem” project first, and it synced. I then continued moving other projects and eventually, Scrivener started to crash again.
So I now have two Dropbox folders, one for active projects and one for inactive projects. Scrivener is only syncing the active projects and I can use it to work on my main WIP again.
Not ideal because I can’t access the inactive projects from my iPad right now, but it’s not as big of a showstopper as before.
It sounds to me as though it is not known that your device is capable of storing thousands of projects without syncing them (those of us that don’t use Dropbox at all would have a fun time using Scrivener otherwise!). Think of the sync area more along the lines of being strictly a transfer mechanism. It’s where you put the stuff that actively changes on a regular basis from multiple contexts, with the idea toward making it more convenient to keep these contexts in parity. In the old days, this would be your floppy disk you use to carry changes around, not the hard drive where you do your actual work.
Most folks will not require archives of projects that never change to be stored in an area that is designed entirely around using the Internet to aggressively monitor and modify each device for changes. It would be like keeping all of your store’s inventory in the truck you use to pick up the morning doughnuts for the staff. The sync code is having to trawl through likely tens of thousands of folders and files, all to work with a small dozen or so that change from one day to the next. Even aside from the actual bug itself that is causing crashing, if one can reduce their sync times from minutes to seconds, why not?
Instead, drag old projects below the Dropbox bar in the project management list, and now they are “offline”, but readily accessible. If for some reason in the course of working through something, you find one of these older projects requires an important revision, it is an extremely simple matter of dragging it back above the Dropbox line to push those edits to all devices. You could at that point then store them “offline” on those devices if that’s the end of it, or leave it active for a while. Why not—it’s not a big deal at this point, since the sync folder is not overloaded at all times—a little extra probably won’t push things over the edge.
It’s not going to work for everyone, some people really do need everything synced, but I think most people out there only work in one or two projects at once. So for them, this isn’t really a “solution” to the actual bug, obviously, it’s more along the lines of general advice—but it becomes relevant to this thread when one gets the feeling that we’re saying you should do without having access to your work!
I’m having a very bad day, so maybe I’m just misinterpreting your post. In fact, I deleted my first reply because it was pretty scathing, which may be other (unrelated) issues from today clouding my judgment. Let me just say this:
You seem to be saying that the way I’m using Dropbox and Scrivener is wrong, that I should only have current projects in the folder Scrivener for iOS is using. That goes against the whole point of storing your projects in the cloud: to access them any time from anywhere. It’s not unusual that I need to refer back to an “inactive” project for one reason or another. To suggest that people move all but their current projects out of the Dropbox folder Scrivener for iOS uses because the cloud is like a “floppy disk” is both condescending and ignorant of how some people need to work.
More to the point, it works in older versions of iOS and is broken for some in iOS 13 and needs to be fixed.