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. 