So I have recently been using scrivener on my Mac and I love it. It’s great to have templates for all of the various things I write in one place. However, I’m hesitant to buy the iOS app because I’ve heard about all the syncing hell with Dropbox and I’ve personally just never been a fan of it. However I’m wondering if I just open projects from my Files folder in iOS, if I’ll still be able to work on projects on different devices. Have anyone tried this? Has it worked? Would just really like to make sure I’m not going to lose work before I drop $20 on the app.
There is no syncing hell with Dropbox. Set up per L&L recommendations it is reliable and robust. Apart from Apple breaking syncing for a short while on iOS13, every syncing issue I’ve seen has been user or their system issue. A free DB account is sufficient for many large projects.
There are ways to bodgie a work-around, but frankly not worth the trouble and wasted time. Drop the $ on the app, setup a DB account and just get on with writing.
2 Likes
The recommended alternative to Dropbox is Apple file sharing. More information can be found here:
support.apple.com/en-us/HT210598
Katherine
Is… is this a joke? An application that works on macOS, iOS and iPadOS and doesn’t support saving to iCloud? Are you for real? I bought Scrivener for macOS just a few days ago and fell in love with it instantly. Scrapped Pages/Google Docs/etc in favor of Scrivener just because of all the features and I can pick up right where I left off between my iMac and both MacBooks.
So, I wanted to works while on the go without a laptop and bought the iOS version… imagine my surprise when in 2020/2021 an iOS app doesn’t support iCloud, but forces you to use an inferior third-party solution for something that should just work.
Like, the iOS application is perfectly capable of opening Scrivener files from iCloud via the Files app on iOS. You’ve just disabled saving to iCloud. What the…? This feels like a kick in the knee and laughing afterwards.
I would have expected this from an Android and/or PC application… But the PC application can use iCloud without any problems, the ONLY version that doesn’t work with iCloud is the iOS one. What in the world is this?
I was so ready to praise it more and be happy to be able to work regardless of device I have with me, but… I haven’t been this disappointed in awhile. Requested refund right afterwards, this is a complete dealbreaker for me. I will not spoil my perfectly working automatic sync with everything else just to have the “opportunity” to move to manual Dropbox-sync.
The whole idea sounds so absurd I had to search the web first because I didn’t believe my own eyes.
I’ll re-buy this instantly once it can work seamlessly with iCloud like it should have in the first place, but for now, this is definitely not for me.
1 Like
You don’t know very much about Scrivener? What looks like a file in Finder is actually a folder with sub-folders and potentially thousands of files in it. That’s what makes it possible to collect research material in Scrivener, to use scrivenings mode when viewing the text, etc. It’s what makes Scrivener what it is. Adapting that to iOS is difficult, and iCloud Drive in iOS just can’t handle that. Dropbox can, because Dropbox has provided an API for developers to let them write the necessary code. Apple hasn’t.
So be angry, but at Apple! Not at L&L
3 Likes
You… you do know that’s how Apple’s applications have worked since at least Mac OS X 10.0? the blah.app file is just a folder with a bunch of files in it. Scrivener’s data is nothing special. iCloud has worked with that since before it was called iCloud. Also macOS-iCloud-iOS syncing (or at least reading/writing to iCloud) works with a plethora of other applications, and they seem to have no problems using it.
Like, I’m not even asking for a full-time automatic sync (though I was expecting that), I’d be okay just loading/saving from/to iCloud. It’s perfectly plausible to do with the Files functionality in modern iOS/iPadOS.
Though I now use Bear for iOS-to-Mac syncing through iCloud, I found this also worked…
https://forum.literatureandlatte.com/t/a-faster-ios-to-macos-and-back-again-solution/51113/1
Hoping for iCloud syncing in Scrivener one day. Cannot come soon enough.
At the App Store, L&L does include that Scrivener does not use iCloud sync:
[attachment=0]B52B5987-A588-44A9-86C3-4B70984DE7D5.jpeg[/attachment]
You can transfer using Files app. Step by step instruction here:
https://forum.literatureandlatte.com/t/a-faster-ios-to-macos-and-back-again-solution/51113/1
You can transfer using zip files stored via Files app. Step by step instruction here:
https://forum.literatureandlatte.com/t/no-desktop-no-laptop/93137/21
You can transfer using Apple file sharing as mentioned upthread or by using AirDrop, although AirDrop has been inconsistent (at best) for me with any App or anything else. I stopped using it. I’ve been using file sharing and/or transferring via zipped files. The methods to accomplish the transfer might vary slightly depending upon which OS versions you’re on, which cloud service you prefer, etc, but I’ve never used Dropbox and have been fine.
The developer’s technical explanation as to why no iCloud is here:
https://forum.literatureandlatte.com/t/icloud-sync/38238/14
And here:
scrivener.tenderapp.com/help/kb … automatic-
(Edit to fix error/link)
@AnnaV, ©Lunk wasn’t referring to the application itself, but to the project format. Each Scrivener project is a package with many files and folders within, unlike most other applications’ documents. An application whose documents are single files has no problem using iCloud sync, but Scrivener’s projects, with their complex internal structure, are chewed to bits by it (pun not intended.)
1 Like
It’s interesting that you appear to approve of Scrivener’s development decisions in virtually every other respect, yet somehow assume this specific decision was made out of malice or stupidity, rather than due to technical limitations.
I won’t bore you with the technical details, which Scshrugged has already linked. I’ll just point out that this has been the single most requested feature since iOS Scrivener was created. The developer has had extensive discussions with Apple’s developer support team – which, by the way, costs actual money to do – to try to figure out a way to support iCloud sync without losing other important parts of Scrivener’s functionality. If there were a way to do it, we would.
Katherine
2 Likes
It’s because it seems your going at it arse-backwards. You single-mindedness of wanting to keep the project as individual files is getting in your way needlessly - specifically because a solution to that problem has existed for decades: packages.
Doom’s .wad files were nothing but renamed .zip files. A gazillion other projects have taken the same approach: package the smaller files into a bigger one.
You could easily just zip/tar the .scriv project and save/load that one. It wouldn’t change anything to the end user, except better and more features without needles complexity. And no, it wouldn’t slow it down in any significant way. You can read/write individual files in/out of both tar and zip files. The Dropbox sync is already so slow using a zip file would probably just speed it up.
Your locking the whole project anyway, it’s not like you can open Scrivener on computer A and work on scene I and then open Scrivener on computer B and work on scene II - the whole project is locked once it’s open. Using a package wouldn’t affect that functionality at all.
Scrivener projects are relatively small, you wouldn’t need to apply compression at all, just archive. A 2011 MacBook Pro unzips a 100Mb non-compressed zip file in 3 seconds flat. Speed is not an issue here.
No need for (expensive) consultation with Apple, users get commonly requested features, backup becomes easier. Zip files even have the capability of including ECC and CRC, so it would be more safe and better to deal with data errors.
You got to have some serious advantage from keeping the format in multiple files for it to weigh more than just going for a package.
I can understand having started with the multiple-file format back in the day when computers did have surplus of extra power to toss on to handling zip files. But Scrivener 3 requires macOS 10.12. There is no supported device in existence that would take more than a few seconds handling even bigger .scriv projects if they were .tars or .zips.
Sorry, I don’t mean to sound condescending, I just genuinely can’t understand the want to stay in multiple-file formats, while not harnessing the obvious advantages of it in the first place (being able to work on different parts of the same project at the same time with multiple computers).
Yours might be small, but there are users with projects that are several Gb, not Mb. Would your solution work as well for those?
Your Scrivener projects are relatively small. Scrivener supports, and users routinely create, projects well into the gigabyte range.
If a project were treated as a single ZIP file, every single operation – synchronization, backup, even routine saving – would require uncompressing and recompressing the entire thing or, in the case of synchronization, transferring the whole thing across the internet. Again, this might not affect your projects, but it would cause an unacceptable performance burden for many of our users. Including users with older hardware and users with less-than-speedy internet connections.
Katherine
1 Like
It seems pretty obvious to me that a 1000 word text file takes less time to upload than a 3 GB ZIP file, but you’re welcome to run the benchmark yourself.
Katherine
2 Likes
I thought the whole point was not Mac OS, but iOS Scrivener, which will run on many devices that would find large ZIP files problematic.
Katherine
1 Like
you can insert/extract individual files from a zip archive without uncompressing and recompressing the whole thing - this has been possible for ages
You know what, nevermind. I’ll just enjoy macOS scrivener and try to forget about anything else.
Scrivenings mode require that several files are opened and edited, simultaneously, and simultaneosly changing the size of several files in a zip archive is not a simple task. It is prome to error, which could corrupt the whole project. It is also recommended that if a zip archive is edited that way, the metadata about the archive should not be part of the archive.
For this specific use case – to facilitate synchronization – you would also have to change files inside the ZIP archive across multiple physical devices, with potentially unstable network connections in between. That seems … risky.
Katherine
I guarantee you, somewhere in the background, hidden away from the user, there is a process that is doing exactly that.
How do I know?
Back when Microsoft first introduced the new Office document formats (.docx, .pptx, .xlsx, etc.) I was working for a company that did a lot of work with the Microsoft Exchange and Office teams. One of the fun things I got to do was write demos. And one of the demos I got to write was showing that using basic Java libraries (and no special library that knew about the new document structre), the average programmer could quickly and easily programmatically crack open the .docx file and modify the contents.
This was possible because the new Office file formats are simply a renamed .ZIP archive that contains a bunch of related files, just like you’re advocating for Scrivener to do. If you take a .docx file and rename to *.zip, you can unarchive the file and examine the contents. However, if you are adding files to that archive, or even modifying existing files, in the background, you have to regenerate the entire ZIP file. There are routines in place to do this for you, but they all involve creating a new temporary ZIP file, then re-pointing the open file handle to the newly created ZIP file, renaming it, and updating the necessary pointers. Even the libraries that provide a memory-mapped interface to your ZIP archive do this in the back end. This would be a performance nightmare for a large subset of the Scrivener users who use it for larger files – the performance hit would be quite noticeable and you wouldn’t even have to get into the GB range before users started being adversely affected.
This is (as a non-employee looking in from the outside via the forums) one of the most consistently requested fixes for Scrivener that I have seen over my years as a Scrivener customer, especially since the introduction of the iOS version – that Scrivener be made compatible with iCloud syncing. It has to be causing a significant amount of time and energy for L&L to deal with these requests. I am positive that KB in particular has researched every potential way to make the Scrivener file format more iCloud-friendly without having to sacrifice the other key design principles that have driven the design of Scrivener’s project format and if they haven’t made the changes necessary, there are valid (if disappointing to us) reasons why.
I must say, after years of staying away of scrivener because exactly the lack of icloud sync support, moving to ulysses despite liking scrivener much better, no coming back in 2025 learning that still only Dropbox sync is available - which is Bloatware since years - makes me sad. Was ready to give it another shot - even to buy an upgrade, but no avail. This is a massive blocker given that so much people use Ipad now as writing tools, or even write together at the same text, see Pages, MS365 Apps, its even realtime collab over different devices…Sad…
1 Like