Is a SQLite database readable by standard text editing tools? One of the key aspects of the Scrivener project format is that your data is not “trapped:” it’s possible (though admittedly tedious) to extract all of your data even if you completely lose access to Scrivener.
Katherine
Not as such, but the database file format has a well-documented spec and there is a command-line tool freely available for many operating systems (it ships with Mac and Linux) that can provide full access to the database, including dumping all content to a text file.
There’s also plenty of GUI tools for accessing SQLite databases; these require one to know SQL, but this is a pretty common skillset. I have no doubt plenty of people will be able to create workflows for working with Scrivener-in-SQLite files, if this format were adopted.
I would classify this type of file format as equally “possible, though perhaps tedious” to extract text.
Remember that Scrivener users are writers, not programmers or database designers. A “well-documented spec” and a “command line tool” are not the same as “can open with any text editor on any computer.”
Katherine
That’s true, but it’s something the average writer could accomplish given step-by-step directions from a website or something. Obviously only worth considering if the SQLite format would be a net benefit; I think it would be, but I am not an expert on Apple development.
You must know different average writers than I do.
As someone with direct knowledge of the Scrivener support queue, I have less confidence in the “average writer” than you do.
On what basis do you believe the SQLite format would offer a net benefit? (Keeping in mind that the costs include throwing out and rewriting a significant chunk of Scrivener’s existing code base in order to work with the new format.) Your posts so far compare SQLite to a ZIP file, but Scrivener does not currently use a ZIP format and has no plans to do so.
Katherine
I was under the impression a ZIP file or similar method of bundling multiple files into one actual file was being considered, as part of allowing Scrivener to work with iOS’s Files support.
I guess I was wrong.
Such a thing has been suggested by some users. It is not under serious consideration by the development team.
Katherine
This works for me, thanks.
For everybody else interested in this, keep in mind that this is a one-way-import, not a sync. The Scrivener project will be copied into Scriveners container on iOS and the project in iCloud Drive will not see the changes made on iOS. It is possible to manually export the project from iOS, though and save it back into iCloud Drive (as a ZIP file).
This sound bad 
Sorry to resurrect an older post, but are there still plans to fully support the Files app, including opening and saving files in place (in locations other than Dropbox or local storage)?
Keith and the team,
Greetings. It’s been a long while since my original posting about melding scrivener with the Files.app – how is the “open in place (without copying)” implemention coming along? Is it still on you radar screen?
Thank you!
I, too, would be interested in hearing about where this might be up to. I’ve taken the step of purchasing Scrivener iOS, but it’s difficult for me to use it as I would like until there is full Files in-place editing (basically iCloud Drive). If the feature is a long way off that’s cool, just curious to know
I’m curious about this myself. I mean, given how iCloud works with iOS devices now, wouldn’t it be better than Dropbox? Would’t it have better sync if the os is doing the syncing insted of having to call the Dropbox api every time you want a file sync?
I haven’t coded anything like that, so I’m just guessing, but I’ve been using RichTexture for iOS to manage cloud rtfs, and it seems iCloud Drive syncing is the best option for iOS when you want to keep your files up to date on all devices all the time.
Limitations of iCloud and the reasons why Scrivener uses Dropbox instead are discussed here:
Katherine
Thanks. I tried this for the first time yesterday—it works really well and adds workflow possibilities/flexibility.
(As always, have a solid backup strategy and follow other best use practices.)
What I find anoying about dropbox is that it doesn’t sync in the backgroud.
Let’s say I want to quickly type something in my phone… I have to wait for it to sync… and it syncs a lot of files.
Then I write something. And I have to actively tell it to sync… and wait…
I don’t know if it’s possible to sync in the background every time you close a document, but it would be great.
iOS does not support true multitasking, and therefore does not support background synchronization.
Note that you don’t have to synchronize all of your projects to all of your devices. I keep a small notetaking project in the Dropbox/Apps/Scrivener/Notes folder, and synchronize only that folder to my phone. My larger projects, which I want on my iPad, are one level up, in Dropbox/Apps/Scrivener.
Katherine
I love this idea. As a longtime Mac and Scrivener user, this would improve the overall user experience and stability. While Dropbox works Intel Macs but it has been a nightmare on my M1. It would also save me money.
Thank you so much, Keith. I do appreciate all of your hard work and dedication. As to the Packages in the Files app, It occurs to me that Apple may have eliminated that issue. I say that since I also use Apple’s Logic Pro X, which, along with FinalCut Pro is now fully functional on the iPad. My Logic Files are packages and I can seamlessly sync between my M1 MacBook Pro and my iPad.
It is not unusual for operating system vendors to use tools in their own applications that are not accessible to third-party developers.