+1 for giving up
Still using Scrivener on Mac to complete my current project but I’ll be testing the competition for the next one, sorry.
FWIW this worked for me on an iPad Pro 9.7" with the latest iOS 13. Painstaking and slow, but copying each one at a time, waiting for dropbox then opening scrivener iOS, rinse and repeat and now all projects are synced and I don’t crash out wheen syncing after a desktop change
gcg’s suggestion seems to have worked for me 
This works fine for my smaller project ~50 Mbyte each, but not for my main projects, which are at about 450 … 500 Mbyte each. 
I have the same experience, small projects yes, large no.
I would also appreciate if L&L could share a bit about what they are doing to solve this quite a large problem. I think we users deserve some concrete info.
/Anders
I’m not sure what could be added that hasn’t already been said. The only new piece of information I think we can now say with certainty (though it was already a pretty certain conclusion) is that it has nothing to do with data. We’ve tested projects that cause a shutdown for others 100% of the time, and there is no shutdown.
As stated before, it remains unclear if there is anything we can do to solve it. It’s not really a crash, but the app being shut down by the OS externally for reasons it is not terribly forthcoming about.
Thank you Amber, but that is not really an acceptable response. That means that, barring convoluted workarounds, sync does not work anymore on Scrivener on iOS, making the app pretty much useless.
The problem has been dragging on for some time now, it can accepted that it takes time to solve, but throwing the towel is something else entirely.
Yes it does, for many users. I haven’t had the slightest problem.
There are also many of us who do not use sync at all, making claims of it being now “useless” a bit eyebrow raising.
But yes, the main problem is precisely that it doesn’t happen everywhere—to the point that we’ve never once seen it happen, despite extensive information provided on the contexts where it does. Nobody is throwing any towels anywhere, but there is only so much that can be done once the data you have has proved without use, but wait for more data.
Well, not everybody is as lucky as you are, and there seems to be “many” users on this thread for whom it does not work, or only after much fiddling.
@Amber: Yeah, I may have overreacted a bit on that one, my apologies. It’s just that we don’t see any progress on our end, and for us who depend on Scrivener for a living, we cannot rely on it on mobile scenarios. You feel powerless, yeah, but we as users feel powerless too.
It seems like SOMEONE in Wales could bring you a device that demonstrates the problem. That, or it’s EXCEEDINGLY rare.
Yeah, I kind of half jokingly thought of adding, “unless someone is willing to send us their device for a couple of weeks”, but seriously, I don’t think that’s a good idea, we’d have to draw up papers and stuff. 
If I were in this scenario myself, I’d try a factory reset and installed iOS 13 from scratch, then tested to see if the problem persists with Scrivener and little else if anything installed. If it didn’t change anything, I could just restore from backup and get back to where I was an hour or so later. If it worked, I’d roll with it and set up the device like it was new. If it stops working at some point, I’d have a much better idea of what changed, and thus what might be an external culprit, be it setting or app.
But that’s a lot to ask of anyone as a “troubleshooting step”, to say the least.
It turns out I never had this problem), but if I did … and if I were near … I’d sign those papers. Maybe I’d even mail you the phone from Texas.
I had a different problem instead, but I support a group where several users need a fix for this one.
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.