Is L&L checking though what is causing this bug? Or what it possibly is? I haven’t heard from the developers and I understand if it’s difficult to give answers or solutions, but just out of curiousity: are the developers looking into this?
Thanks in advance.
In the last message I got from tech support (on the 27th), they said they hadn’t yet been able to replicate the issue on their side, but they acknowledged that the crash causes a JetsamEvent crash log and asked me to send my crash log. It was also recommended up-thread that those log files be sent in to the support email address so they can look into it, but I haven’t seen an update here on any progress.
I tell you what—I’m about to roll back to 12.4.1. Just because my devices haven’t been affected yet by the 13.x.x bugs doesn’t mean that they won’t be. I’ll wait to re-upgrade when this thread finally calms down.
How do you roll back?
Good question. The first way I tried, restoring a backup from just before ios 13 release, didn’t work. Now I’m downloading an image of 12.4.1, to install with iMazing. I’ll let you know how it goes. Be aware, I’ve run across several warnings that Apple “unsigns” older iOS versions, (i.e., 12.4.0 will no longer work) so if this works for me and y’all want to do it, best do it soon. If it works, I’ll post full directions.
There’s no way I’m doing this. I hate to admit it, but I’ve transferred my projects to [a competitor] where I’ll work until this is sorted. I can’t afford to spend any more time trying to find a solution. The issue has been apparent for weeks, from the earliest beta versions of iPadOS. I rolled back once already and spent a day recovering work I hadn’t backed up (my fault, but it’s still a pain). After years of being faithful to Scrivener this is the first time I’ve looked at another woman. 
AmberV/Ioa is the head of support and is actively posting in this thread.
So yes, we’re aware and looking into it. It’s probably an Apple bug – programs other than Scrivener are also experiencing it – so it’s not yet clear what workaround we might be able to offer.
Katherine
For those who want to roll back:
I’ve posted a new topic in the Software and Development forum entitiled “How to Roll Back to a Previous iOS / iPadOS version using iMazing” [url]https://forum.literatureandlatte.com/t/how-to-roll-back-to-an-earlier-ios-ipados-version-using-imazing/47312/1]. I succeeded in rolling back both my iPhone 8+ and my iPad 6th Gen.
A quick summary: the currently “signed” iOS images are available on a site called ipsw.me. Backup any non-cloud resident critical data on your iOS device some way other than iTunes or iCloud backup. Download the correct image for 12.4.1 for your hardware, then revert your device by installing the image with the iMazing app. After reverting, your device will be in “came from the factory” condition; restore a backup from before iOS 13 if you have one, or rebuild your device by updating settings, re-downloading apps, restoring data from clouds/backups.
I highly recommend iMazing as well worth the $40 I paid for it. It’s been invaluable as a replacement for iTunes’ backup to my Mac, and it really helped me out here.
I put all my files in another folder and put them back one at the time and synced between the files and it worked.
But as I sync now ALL files are synced , not only the files I have worked with .
That’s great to hear!
I know some of us have had luck designating a new folder and doing the one-by-one move.
Just out of curiosity, what’s your largest .scriv project size?
Had a huge fright today and one I’m none too happy about: when I closed and reopened my project, I discovered by chance that for some reason Scrivener had reset several files to earlier versions, erasing days of work. I did notice Dropbox had become strangely overactive, syncing stuff in my projects while there was no real reason to, while I was testing in parallel if my iPad was finally able to download my project.
Thank god for Scrivener’s automatic backups, I was able to open earlier versions of the project and locate the changed files and restore what had unexplainably gone missing. But my trust in Scrivener is severely damaged at that stage and I not touching the iOS app anymore. I write for a living, often under tight deadlines, I need a reliable tool and that is why I have always preferred Scrivener over anything else. But as several others have alluded to in that thread, the severity of that bug seems underappreciated by support. It’s simply a show-stopper and for a pro app, we should not have to gingerly test if our files will break in the app or not.
Sorry for the harsh words but I feel like LitnLat is kind of taking things a little bit too lightly here… and I never thought I would do this, but I too have started considering “another woman” once my current big project is finished.
116MB here and one of 82MB. The disconnect, move and and move back one at a time worked. I also took the opportunity to clear the folder of a few ‘dead’ files.
To Killerwhale, it’s not a matter of L&L not taking it seriously. It seems this may be an Apple issue as some other apps are apparently having the same issue. L&L couldn’t recreate on their systems which makes it a difficult exercise. They did ask for logs which they are no doubt pouring over and chatting to Apple about. As for resetting to earlier versions of a file, I’d be looking outside of Scrivener as a possible cause.
Meanwhile there does seem a way around the problem without going through the exercise of rolling back to a previous iOS version…
No, there is NOT a way to work around this problem. Many of us have tried the work around and it did not work.
Someone please tell me what I can do to help L&L recreate the problem, because I really don’t want to try to convert my five novels in progress to another program…
mmm, I saw I think 2 who said they still had a problem with specific files, though every other post from those who had tried the process seemed success. So, yes there is a way to work around it, but not necessarily for everyone and every project.
They have received a number of log files and are working on them, don’t know if they need more.
I’m sure they are working on it, but a short „Hi we’re still working on it“ would be very reassuring.
I don’t blame the developers for the bug and I understand that it just might not have been possible to hunt it down yet. But on the other hand it looks like it’s related to the whole problem of the syncing process being complicated and tedious. I’ve always defended Scrivener and I’m a long and loyal user, but right now I’m just longing for a writing app where my files are just there and where switching between Mac and iOS works seamlessly (also in terms of features and user experience). I would have never believed I‘d say this and I don’t want to sound sulky, but I think I’ll have a look at an alternative app, at last until syncing gets better and the iOS app gets closer to the Mac app (which I’m sure one day will happen and then I’ll return. Or maybe earlier, when I start missing all the cool features Scrivener had and three others haven’t).
That is pretty much the gist of Katherine’s post late on 1 October. She also points out that it seems to be an Apple bug. So it might be better to light a fire under Apple instead of LitnLat. It seems that Apple broke it, so they will probably have to fix it.
Yeah, I have two projects that crash the app if I move them into the new folder I created. Maybe it has something to do with snapshots or a file type like PDF being present or some other feature - I thought it was due to the .scriv project size but others are clearly able to move large ≤ 110mb projects into a new folder and sync without issue. I am not.
This issue has to be a QA nightmare since every time we users think we stumble on the the perfect recipe for disaster (or ’steps to reproduce’ this issue with 100% accuracy) another user in these forums with the same scenario has no issues.
For myself, it feels pretty mind boggling:
• It appears new iPhone device with new OS report this issue 100%. Yet, I’m under the impression some new iPads have this issue and some new iPads don’t.
• Older devices with new OS appear to have no issue. (Why? Processor type?)
• Some users move to a new folder and move projects one by one to success. Both small and large ( ≤100 mb) projects.
• Some users move to a new folder with ‘some’ level of success, with smaller projects only. Bigger projects crash.
• Some users report moving to a new folder success is 0%, with either size project.
The issue is so inconsistent (except in its awfulness) that it’s a pain to nail down. If we had 100% repro steps I’m sure they’d have a fix already.
I know there was an OS beta before Apple rolled out iOS 13.x.x. I don’t have any visibility into what came from L&L’s, or other beta user testing during that phase, but it must’ve not set off any alarm bells.
I wish I could help more but I’m at a loss for what to do next. I just keep refreshing this post hoping someone has stumbled upon a universal absolute.
(edit: grammer)
JustAnotherWriter, that’s just about the size of it. From the usage angle there are no good useful patterns. Even the new vs old device and processor type clues, fruitful and interesting though they seemed at first, ended up being more indicative of averages that absolutes.
But the log files that some of you have taken the time to send in have at least shown some more concreteness in their similarities. They do very much seem to indicate a RAM issue that, while it only happens in some usage scenarios, at least cause very similar logging results. The question now is how to optimise this main sync loop, if that proves to be the problem, particularly if we can’t get the fault to happen in the first place. Could be general optimisation is good enough, we’ll have to see.
My very low-info guess at this point is that iOS 13 has tighter restrictions on per-process RAM usage, and that some combination of unknown factors causes that to become more prevalent.
@AmberV, has anyone come forward with such a folder? If not, then there’s still one thing that an affected user can do to help out.
For myself, I’ve implemented the “Alternative Method”, described in the Knowledge Base article “Using Scrivener with Cloud-Sync Services”, towards the bottom of the page, using zipped backups. For the iOS side, I access the backups via the Files app, and de-archive them using the Shortcuts app technique that @ThisHereIsPete described in his post, [url]External backup for Scrivener iOS files? - #12 by ThisHereIsPete], with the slight change that instead of the “Save File” step, I use “Open in” so that I can open the project directly into Scrivener iOS. When I’m done on iOS, I export a backup manually to the same folder. It’s not as fast as the built-in Scriv sync, but it’s sure and with zipped backups can be used on any cloud service that integrates with the iOS Files app.