Thanks Amber for the update.
What I read was that L&L has no idea about what happens and is not working closely with Apple to solve this unknown problem for us unfortunate customers.
This was unfortunate news for an otherwise lovely app.
/A
Amber,
I have been corresponding with Pascal on this issue a bit. I have two iPhones, one two years old and one brand new, both experiencing the issues described in this thread. Scrivener runs fine on my iPad Pro.
I would be willing to show you what is happening in a Zoom session, using screen sharing, and to walk through troubleshooting steps, if it would help to arrive at a solution.
Thanks for your continued diligence at solving these issues. I know how frustrating it can be working with operating system upgrades.
Seth Thomson
Thanks for the offer, Seth! Unfortunately I don’t think that would help us, since we pretty much have a good idea of what it looks like on the surface, and the kind of data the OS produces beneath that. These two aspects can provide clues as to the nature of the problem, but very rarely will they provide precise information on what happens—for that you basically need a live case physically plugged into the Mac that has Xcode and the source code for Scrivener running in debugging mode. Sometimes you can find problems in the simulator as well, so you don’t need the physical setup, but as I say, we have yet to see it happen under any conditions.
And that’s even assuming debugging can pinpoint the problem—in a case like this it has every indication of an OS memory bug or flaw causing it to erroneously shut down Scrivener. We can detect no out of the ordinary memory usage under normal circumstances, even with the exact same data used to trigger the problem elsewhere.
So without that, there is no debugging. All we have is a relatively simple loop that has worked flawlessly for nearly four years, until suddenly iOS 13 comes out (to be very generous, I’m still calling it a beta) and now some, but not all, devices mysteriously don’t have enough RAM to finish doing something an iPhone 4 running iOS 9 had no trouble doing. 
This is exactly where I am on the issue. I have given up sync on my iphone XR running 13.2.3. It is not worth the time, stress and frustration to keep returning to this issue. Scrivener syncs fine on my newer and older Macbooks, and on my iPad. As these are the devices I use to actually write, I decided I could live without the ability to access projects on a phone.
So I think you are right. Silence means people have moved on, not that the issue is fixed.
David
“Working closely with Apple” is rather more difficult to actually do than to write. They are not the most responsive company in the world, even for developers.
As Ioa notes, though, the first step toward solving the problem is reproducible test case. So far, we don’t have one.
Katherine
Are you sure the issue is RAM? I’ve been having this issue on my iPhone 11 Pro, but not on my two-year-old iPad Pro. I’ve tried a series of troubleshooting steps, but nothing has yielded any promising leads. I tried the create-a-new-Dropbox-folder-and-slowly-add-back-the-projects-like-a-Scrivener-soulfé method. But it has not worked for me–it has worked in part, but eventually I add in a project that causes the sync to crash the app again (seemingly no rhyme or reason as to which project). At first I thought the problem was because, in my Scrivener sync folder, I have some legacy non-scrivener files. But removing them did not ultimately eliminate the sync error.
The only thing that I have observed consistently–and this may be something you are already aware of–is that the actual syncing does not seem to be the problem. The app hangs during the sync phase where it is “downloading file list” from Dropbox. If it gets past that phase, I’ve never experienced a crash. That made me think it’s something other than a RAM issue (how much RAM can a file list take?), but I’m no developer so take this diagnosis with a grain or so of salt.
The other thing I’ve observed that may be related has to do with Scrivener’s settings from the iOS settings app. If I go into those settings and try to toggle a setting, it crashes the settings app. If I re-open settings and go back to the Scrivener settings, it does appear that the toggle I adjusted was correctly set despite the settings app-crash. Maybe that means something to you?
Hope this is of some help in diagnosing the problem. I’m happy to try other troubleshooting methods. I would offer to do the settings reset, but I had to do that recently for another problem.
I know this must be frustrating for you – a problem you haven’t experienced and cannot effectively recreate and test coupled with very vocal and upset users. Scrivener is an exceedingly well-engineered app because its development team is diligent, disciplined, and very attentive to detail. I have no doubt you want this problem fixed as badly as we users do. I am grateful for your efforts and look forward to having sync working reliably again.
Yes, that is all a known part of the pattern. It’s probably a few pages back in this thread at this point.
Well, there is quite a lot to unpack in there. One can write an horrifically inefficient loop that copies the entire hard drive list over and over in its attempts to map the territory. But it should go without saying that we haven’t done that, and the loop that has built this list for years now is pretty much the same loop that was optimised to work on very old hardware—so it’s pretty efficient. The problem is almost certainly not with the loop.
The joke then (which to be clear is all it was) is that iOS produces a memory use threshold error log when shutting down Scrivener, on devices that have way more RAM.
So to say it’s not a RAM problem is… well, it’s more complicated I think. It’s not, obviously a matter of the size of one’s chips—that is mathematically true and self-evident—but to say it isn’t a memory problem because of this (or inversely that the process should be small) probably isn’t a safe assertion. It may be that the memory problem is false, that iOS thinks it is running out of RAM when it isn’t, but even so that is still kind of a memory problem, or at least a problem in the infrastructure of the device that deals with memory.
This has confused the topic at hand. I’ve split it off to a new thread.
No improvement. Installed 13.3. iPad Pro (11 inch) still crashes.
Hello all,
I just upgraded my iPad to iPadOs version 13.3. At the same time an update for the Dropbox arrived today. Unfortunately the problem persists and Scrivener says goodbye while the app downloads the file list. The actual synchronization process hasn’t even started yet when it crashes.
If I empty the dropbox directory on my Mac and synchronize an empty directory without project files, the synchronization will run without a crash. It doesn’t help me, but shows that the crash is actually related to loading or synchronizing the directory content.
I still hope that this problem can be solved. If we, the users, can help the developers in any way to identify the cause, please feel free to ask.
Greetings,
Thomas
Sorry, but that’s not really true. There has been the problem of the „downloading file list“ taking extremely long after upgrading to Scrivener 2, which as far as I followed up was never really resolved or explained. I hate to say it, because I really love Scrivener, but my impression is that the database just isn’t made for syncing and the workaround you found is just to complicated to work „flawlessly“. The software is great on the Mac, but it doesn’t seem to evolve with the trend to switch devices seamlessly.
Let’s try to keep this thread focussed on the actual bug at hand here. It just makes things confusing when completely unrelated topics are brought up.
The explanation might have been lost in a long thread about it, but the source of the problem was indeed pinned down and reported to Dropbox some time ago. Since then I’ve heard that performance has improved marginally, and they even communicated with us that it is something they are aware of and wish to improve. The technical explanation has to do with how their API has a lot of overhead when trawling a folder hierarchy. The more folders you have, the longer it takes to build a file list.
I know in my recent testing it did seem to be a lot better than it used to be. I ran some tests with over 10,000 folders to be synced, and while it took a while to build the file list, it wasn’t anything like it used to be.
Again, this is not in any way relevant to this current problem, which is all I was speaking of.
An interesting theory, but no. For one thing, it’s not a database, and the format itself was designed from the ground up for syncing. So scratch all of that. Secondly, what we’re talking about is a simple request for a full file list from a folder. This is the first thing you must get from the server when syncing files: a list of files. That is not a workaround, that is how you work. It is also not complicated—it is a request for files from a file system. That the server takes forever to produce this list does not speak to “flaws” in the system.
Okay, sorry if I made stupid technical assumptions. But it remains true that syncing is tedious, even without the bug. Maybe you just can’t have both: the greatness of Scrivener and an easy, seamless user experience when switching devices.
The way I work involves many short writing episodes during the day on whichever device I‘m just at. My phone is useless for some time now. Maybe I just have to accept that Scrivener isn’t made for my use case.
Syncing is tedious… for some users, not all.
I have had a ”seamless user experience” since day one. So how come it works for me and not for you?
Lunk, would you have the kindness of not dismissing other’s bad experiences nor imply that it may somehow be their fault, please?
I’m not dismissing it and the question is a question.
If some have problems and some don’t, the differences between our use cases should be of interest in trying to find the cause.
Several users have reported problems, but if a majority of the users had problems L&L would be drowning in complaints, and they’re not. So far the reactions in here suggest that a minority of users have problems, so the important question should be “in what way do their set up differ from those that don’t have problems?”
If it is total number of files in the synced folder, then it should be interesting to know if there is some kind of breaking point and/or if that changes depending on device, or depending on connection speed with the Db server, etc.
In my case, I have lots and lots of Scrivener projects, but only 6 in the folder I sync with my iDevices. The total size is usually less than 50 Mb (only text no images) and the total number of files usually below 1500. No syncing problems.
Killerwhale, what does your scenario look like?
I also had problems. We are trying for months to get answers and solutions but nobody has them.
This is the issue though. Not all of us can or do work this way. I have three projects on the go, so theoretically I could limit my sync folder to these projects only (And I do). But two of them require research, copy and maps/pix from previous projects. To access those projects on my iPad I need to sync to another folder containing my library of projects, which of course crashes Scrivener. However, even before the crash problem, sync was slow and clunky, as others have said. And yes, the ‘problem’ is that my projects are large. But that shouldn’t be my problem. I’ve used Scrivener for years because it was a solution to that problem. Currently, it isn’t. You’re lucky that you can work around the limitations of the app/s, but in my case it’s not possible and it’s impacted my ability to work on the road and in cafes etc.
There’s some truth to this, in that the complexity of synchronization is directly related to the complexity of the Scrivener project format, which in turn is essential for what Scrivener does.
Katherine
@lunk : My scenario had gone badly from day 1 with the Scrivener sync. For a long time I wasn’t able to use the iOS app, had to reimport all files in a new project that then worked for a while. Since iOS 13, Scrivener has not worked on any of my devices and I have decided that sometime next year I will certainly trade, with regret, Scrivener’s power features for a reliable sync on another app.
@lunk : Hey, you made your point. You don’t have the issue, we got it. We’re all glad to know what your seamless sync implies in terms of projects, and what device you use, That’s precious debugging intel. But now, the thing is : what are you still doing here ? We understood your situation the first time, why do you keep hammering other people that have the issue with the fact that you don’t ? Are you the kind of people that goes into hospitals to tell sick people that you are healthy ? Because that’s what you’ve been doing here for months now. Again : why do you still follow this topic if you’re not directly concerned by the issue ?
Now that being said, I’ve also been having the issue for a while. I’ve just been following things silently for now but I thought I’d bring my situation in as well :
iPad pro 2019, 11’’, latest OS version and latest app version (eagerly updated as soon as possible as you can all imagine). I’ve been having the same issue as stated before, sync for all my current projects doesn’t work. I’d like to spot that the app doesn’t seem to crash for real, as it’s still open in the background and doesn’t need to load back up, but the sync is aborted anyways. I’ve been trying swapping projects a bit, but it seems that my bigger projects sync without issue until I add the smaller ones as well (and I need them too). I never tried the smaller ones on their own, since my biggest project is the priority for me and I want it safe on my dropbox.
When I say “biggest”, I mean 2.29Gb. While the smaller ones are 36Mo and 130,7Mo respectively. This is what doesn’t make sense for me at this point.
I also noticed that if I remove the files from my dropbox and ask my tablet to upload them all back as they are on it (not up to date to my current progress), it works. However, when I go check them on my computer, the scrivener file icon seems to be different from the one used for the files created from the said computer, which is also super weird. And if I try modifying them, even the slightest, they won’t sync back to the tablet. I have no idea what’s going on there.
Reading this topic, it also seems to that the issue is more or less device-bound ; some devices are more likely to have the issue while others never will. I don’t get it.
And, please, no need to tell me that I have to remove the smaller projects if my main project works and stop complaining. As I said, I need them too. And as many other people already said here, we purchased this app several times to have a seamless experience between devices and a sync that could take all our projects, which has perfectly worked until recently. There’s no point arguing on that part.