I will break with what appears to be the predominate opinion over which is the best way, or whether anything else is a kludge, and say that AirDrop (or WiFi file management from the Mac) is pretty much the only way I have ever used the iOS version of Scrivener, and have never found it to be unwieldy or difficult to keep track of. And if you have any doubts about it being fully supported, don’t worry—direct file access was an important part of its design from the very start (in fact, before sync was even considered at all in the early stages of development).
It is also, in essence, the method I use to transfer copies of a project between regular computers as well. In terms of involved technology, it is far safer to work this way as the moving parts are extremely simple in comparison to copying whole folder hierarchies, never mind the complexity that is two-way synchronisation. I would agree, to a certain extent, that there is an element of potential for human error in that procedure (or a similar one adapted for iOS), but honestly that’s always going to be the case, and you can just look around these forums to see that syncing with Dropbox is not without its weak spots in terms of human error—nor is that unique to our software’s implementation of sync or Dropbox, as you will find pretty much any forum or review board for any kind of software at all shows evidence of poor human management of technology, no matter how “seamless” it appears to be on the surface.
So, you’re always going to have risk—the question is what we can do to mitigate it, and the procedure I outlined in that link above makes it very hard to lose work. With date-stamped .zip files it’s almost impossible to mess up—and if you take cloud technology out of the equation and use local WiFi access to the devices or AirDrop, then the largest minor risk (forgetting to let the latest .zip fully upload before putting a device to sleep) is gone.
If you want a recommended procedure there is one given in the Mac user manual, under §14.2.1, Basic Usage, subheading, Using AirDrop to Transfer Projects. Do note the yellow tip box in that section: Apple periodically breaks AirDrop’s support of folder format detection, meaning Scrivener won’t be suggested as a tool you can open a .scriv with, even though Scrivener tells the system it can. As noted there, you can just route it to Files, wherein you can choose Scrivener’s storage folder directly. It’s just an extra step toward the same result. As I mentioned above, I actually prefer to AirDrop the backup zip rather than dragging the original project, keep those in a folder on the iPad, and decompress and drag the .scriv into Scrivener’s storage to update and get to work. You keep redundant copies and backups of your work on both devices that way, and it’s hard to argue against the safety benefits of that—but that’s just me being extra careful with data.
I would simply drop the file on the iPad in the morning via Airdrop and vice versa at the end of the day. The worst that can happen is losing one day’s work, right?
Yeah, and hopefully by this point you can see that it would take an extraordinary level of error to even get to that point. You’d have to accidentally delete the latest .zip you sent to the Mac and the project that is on the iPad that you generated the .zip from, to actually lose the work you did that day—and if you .zip to a local folder in Files and do your back and forth transfer from there, as I recommend, you’d really need to somehow accidentally delete three copies on two different devices.
Does the iPad version also has the correction mode?
I’m not sure what is in reference to, Revision Mode? If so, then no it doesn’t have that. It’s a lot more basic than the Mac version in many ways.