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.