I’m also affected. Sync doesn’t work anymore, neither on my iPhone 11 with iOS 13.2.3, nor on my iPad Pro 3rd Gen 12.9 with iPadOS 13.2.3. It says “Downloading file list…” and then invariably crashes.
So I can’t use the mobile version anymore.
P.S. just updated both devices to 13.3, doesn’t change a thing.
I doubt Literature & Latte has any idea what % are affected.
Do you want to give up your device and your iCloud account? Because it’s likely some combination of device, OS, iCloud account, and project that triggers this bug…
What would an iCloud account have to do with an app that only syncs through Dropbox?
Yep - count me in the number effected! So annoying. I’ve tried all of the suggestions, and they don’t work, L&L need to get an update happening pronto to fix this issue… Because without the functionality of syncing - then the app is pointless…
Not really.
Some people write ONLY on iOS, no need to sync.
OR
You can sync manually with iCloud and the Files app:
Put the project in iCloud, wait for it to sync, find it in the iOS Files app, and open it from there.
To go the other way, click Edit on the home screen, select the project, and click the export (up-arrow) icon at bottom of the screen. Scrivener creates a zip file and iOS offers to Send it in various ways (like Airdrop, Dropbox, Messenger, and Files).
If you export the Zip file to Files (may have to Edit Actions to add that option), you can choose to put it in an iCloud folder.
That may be MORE RELIABLE than the usual method.
You don’t even need to zip it after working on it.
So I open a project from the Files App. It will ask me to copy to ‘On My iPad’. If you already have the file downloaded in the Files App, this will happen super quick, even for 10GB projects.
After working on it on the iPad, I open 2 Files-app windows in side by side. On are my Projects on iCloud. The other one is the folder On My iPad - Scrivener. There you can find the local projects. If you just drag and drop from there, you don’t even need to zip. It will ask you to replace the old project on your iCloud folder, if the old version is still there.
I’ve been using this method the past 3 months, and it has been reliable and quick, but it IS a manual process and not a sync.
The process you describe won’t be faster than syncing the zip file.
Can someone explain why iOS Scrivener can’t trigger a Dropbox update of the project all in one go … WITHOUT making a list of the files?
I think that’s how the Dropbox API is written, and that’s the one Scrivener relies on. Scrivener doesn’t have it’s own sync code, it uses the Dropbox API to let it take care of the syncing (if I understand correctly). The Dropbox API first makes a list of all the files, and that is what is taking abnormally long since the update to Scrivener 3 (which in turn created 2-2.5 the amounts of files internally in a project compared to the previous version).
And now we have the whole crash issue, but this is a weird one because some people have it on small projects, some on big projects, some have it on newer hardware but not on old hardware, with the same projects, so…
We still to this day, 3 months after reporting the problem, don’t know exactly what the problem is, and where it lies. Just (calculated) guesses.
Hunting around the Dropbox forums turns up a lot of posts with hangs related to downloading the file list, which seem quite similar to what we’re having here. I’m wondering if there’s been a change in the Dropbox API that’s made this problem manifest itself for Scrivener users.
There hasn’t been a fix for the problem, but it seems it’s related to the length of the path for a particular file being synced, and a few people have got around it by shortening filenames and shallowing hierarchies.
So, assuming that this hasn’t already been mentioned in the last 22 pages, has anyone tried the following:
I’m wondering if you get to a point where the project will eventually start to sync.
Have seen a report of same issue with some Ulysses users.
So seems it’s a Dropbox/Apple issue that developers may not have any way of getting around. No doubt they are all peppering Apple/Dropbox with WTF’s
How is it supposed to know what files have changed? Keeping in mind that there may be changes to both the local and the server versions, and users expect Dropbox to keep track.
Katherine
a) All pathnames in the project structure are the same length (within half a dozen characters).
b) We have NO control over pathnames. They’re unrelated to document names in the Binder.
Here you see typical documents:
I could ask, “How does Dropbox ever know what files have changed?”
However, I think I perceive the hidden context of your answer. Here’s a guess I gave users on a FB group I moderate:
"To your point about the API, I think the issue is how to make iOS transfer project files from Dropbox in the cloud to internal storage on the phone or iPad. If it were possible to simply pass a pointer to the project folder, and iOS would go through all the files and subfolders on its own, copying them to local storage if newer, copying the other way if older, things could be easy. That would require iOS to use Dropbox API calls in a complex way … and why would Apple want to take on that task?
Until the Files app came along in the past 6 months or so, it was well-nigh impossible to directly access files on iOS. Apps could do it, but they had an iOS API to deal with. Every API has limitations, and Apple doesn’t like making it easy to mess with file structures on their devices. There’s a reason Literature & Latte hired and fired three (I think) developers before Keith Blount took over developing the iOS app himself, and I’m sure there’s a reason he did it via Dropbox, not directly through iOS.
The Files app made things a bit simpler, but does FILES have an accessible API Scrivener can use? I doubt it. The solution I posted yesterday uses Files MANUALLY."
This is essentially what iOS Scrivener does: it downloads the file list from the server, compares it to the local list, then uploads/downloads as needed to make the two lists match. And yes, doing so involves deep entanglement with the Dropbox API.
The short answer to the perennial “why won’t iOS Scrivener use iCloud” question is that the iCloud API does not currently allow the level of access to individual files that Scrivener needs. The Files app is a step in that direction, but only a step.
Katherine
Very interesting info! Hierarchies and filenames—hmmm…
This makes sense as the Scriv 3 project structure added a layer of internal hierarchy as well as a LONG filename (a UUID) for each file in the Binder. If the bug is indeed related to filename length and hierarchy depth, then folks still using Scriv 2 Mac or Scriv 1 Win should see this problem less often. (No UUIDs, shorter hierarchy.)
I’d like to add this information:
99% of the filenames internal to the project are not under user control. The hierarchy internal to the project is not under user control either. (What you see in your Binder bears little resemblance to the on-drive structure).
You could rename each project (by using Save as…) to something very short. Don’t bother to rename anything in the Binder because those names aren’t used as filenames. Don’t bother to rearrange your Binder to shorten hierarchies as they don’t affect the structure Dropbox sees. You could also change your sync folder to a folder to a top-level Dropbox folder with a single-letter name (like “S”), thus shortening both pathname and hierarchy (as compared to /apps/Scrivener).
Hope this helps.
EDIT: I see @drmajorbob already provided most of this info, with illustration. 
But the shorter project name and top-level single-letter folder might still be of some help.
Hmmm…in my case & I think some others in this thread, the projects that crash actually originated in Scrivener 2 or 1.
If they’ve been converted to Scriv 3 format then origin Scriv version doesn’t matter. The conversion process would have added the hierarchy depth and the UUIDs as part of pathnames—if that’s truly the trigger.
Hmm.
What happens if you use the Import → Scrivener project command to import the converted project into a new, blank, Scrivener 3 project?
It shouldn’t matter. But this addresses the possibility that there’s some kind of artifact from the conversion contributing to the problem.
Katherine
