Mac OS and iOS options

Scrivener Scrivener for iOS
1

Hello there.

I’ve been using Scrivener for Mac for many years and love the new version. My mac is a desktop, and currently I have a harding writing from home.

I felt like buying a macbook would be redundant, so I traded my old iPad mini for a iPad Pro (fantastic, but expensive).

My questions: if I get Scrivener for iPad, can I simply drag and drop my project through the files app without using dropbox?
Does the iPad version also has the correction mode?

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?

2

before some talk about kludges (some already discussed previously in this forum), for what reasons are you against using Dropbox? Synching is complicated and Dropbox provided the Scrivener folks the technology to make it work. it just works. using kludge do not necessarily make the syncing easier or more reliable. But, whatever.

3

I don’t need it.
I think my way would be simpler.
I just want to know if it’s feasible.

4

ok. what happened when you tried it?

5

Your way is not simpler.

It is possible to use Apple File Sharing to transfer projects between a Mac and an iOS device. However, doing so is a “copy” operation, not a “sync” operation. That is, File Sharing copies the entire project, while synchronizing uploads and downloads the component files as needed to make sure that the two (or more) versions match. So using File Sharing means that you are responsible for keeping track of which version is which.

6

I didn’t. I haven’t bought the app yet, like I said in first post. Just want to make sure it is possible before doing so.

7

It is simpler for me, since I won’t need to use Dropbox at all.

So it’s possible, thanks. That’s all I asked.

8

I think you’re missing the distinction.

Using Dropbox, you have a small amount of one-time setup on each or your devices. Then, you simply make sure the sync is completed after working on your projects, and the current version of your content is always available.

Using Files, you must always be aware of which version is the current version and manually make sure that you are opening the correct version each time. Yes, it is possible, but over time, you are increasing your chances of working on the wrong copy of your project and creating a bigger problem for future you to fix.

1 Like
9

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.

1 Like
10

interesting. this may well be in your documentation but if not, might be a good idea to include.

11

Most of it is, in brief format, documented. It covers using alternative sync services via Files integration, using Finder/iTunes direct access (this can be done over wire, or if the device is set up for WiFi sync, wireless) and AirDrop. We even recommend using a wire for the initial transfer for Dropbox users who have massive projects to sync, since initial sync times go from potentially hours to a few seconds.

12

Hi guys I can share my experience, that is just really simple in my view. Yes it is not a real sync but it works and it is easy. I have my book saved on icloud. That’s it. When I need to work on ipad i just open the book from Files.
Once i’ve done the only thing I have to do is to copy the file, that it is now locally on my iPad, back to the original icloud position and override the old one.
When I open the file on the desktop version I have the most recent file I’ve worked on the iPad.
Yes i know it is not as syncing in dropbox, but if you are not bother having that … I can suggest what I do works and so far, in the last year I haven’t had any problems.
Of course mine is fictional book so it is a easy book to manage compare to a full of images book. So @SirFalstaff hope this would help you

13

i guess i still have a a hard time understanding why using Dropbox for some is so abhorrent.

14

oh no @rms don’t get me wrong. I’m just happy with my icloud space and I after I found out it works I just decided to carry on that way. Dropbox is a great cloud service. Doesn’t just work for me but for simple reason I’ve already have and I’m happy with Apple iCloud.

15

i use both. and dropbox less expensive as my projects fit in the free service. i like that i basically have to do nothing except ensure the syncs finish. easy.

16

I certainly wouldn’t use words that harsh. But to dig for some reasons: for some, myself included, there is a matter of its lack of security and privacy (which for some is a mandated limitation that includes most mainstream U.S. based services, but I don’t fall into that category). Equally important to me is that the concept of using such technology itself does not offer any substantial advantages to other safer approaches with one important exception: convenience. For myself, that’s just not good enough when you consider the added risks and increased complexity of using the internet to synchronise your data. I’d rather just use a local sync tool if I really want that. I have everything on the same desk, surely the local network is sufficient.

There are other factors as well, for why I’m not a “seamlessness” junkie. I’ve written a bit on my philosophies of using technology to mimic paper processes more closedly, there in context to a request for closer integration between Scapple and Scrivener. It would be fair to say that my use of iOS falls within that realm of thought, in that I very often do not even modify the original project, treating what I do in the iOS version as quick thoughts to be rewritten and integrated with the main projects once I get back home.

That said, if I did use it for more serious writing sessions, I wouldn’t really change anything about how I work, short of not primarily using throw-away blank projects on iOS. Like I said, I use this same copy-zip-based procedure between laptops, too. I’d rather have stacks of redundant copies and a super simple workflow than every machine messing with a “single” central copy that I must always remember to close and follow sync rules in order to use safely. I’m too much of a space cadet for all of that.

In the end though, Scrivener fully supports a wide variety of workflows in this matter, and so I don’t think anyone should have to justify which one they prefer to use. For however you prefer to work, we have good systems in place.

2 Likes
17

It works perfect for you. So as you see is not been abhorrent about Dropbox. it is just: does it works for me? and any of us have their own answer :smiley:

18

With all due respect, you are a shining paragon of what we in the IT consulting field term “operational maturity” – you take the time to understand the underlying technologies to the best of your abilities and build your workflow around the intersection of your requirements and how the technology actually works (as opposed to how you want it to work.)

A large part of being a senior IT architect is taking the time to understand how good the personnel at our clients actually are at understanding how things work, and how big the disconnect between their business processes and IT operational processes are. Successful projects are a three-legged stool – technology, people, and processes – and the technology is usually the easiest (and cheapest) one to solve by far. Get a good grasp on the other two, and usually the technical solution becomes very straightforward – with many potential solutions that would work for other organizations left on the bench because the current client can’t (or won’t) keep the required level of discipline in place.

This is why it’s good to have multiple solutions so you can hit differing sweet spots.

1 Like
19

The way you started that seemed as though you intended to confront my opinion with an argument that I should consider—but in the end I could not find anything that I disagree with. In particular:

@devinganger: This is why it’s good to have multiple solutions so you can hit differing sweet spots.

Indeed, my main intention here was to point out that Scrivener has several intended mechanisms for keeping one’s device updated and vice versa, and beyond, that iOS itself has several mechanisms that allow for one to mix and match preferred services and methods with tools that support file management, as Scrivener does.

I also agree with the notion that process can also be one of the first victims of a workflow, which in turn can lead to overall system failures. That is why we put emphasis on having a strong procedural process for both syncing (which requires one to be aware of their context to avoid conflict errors) and file copying. Having a checklist that you build into a habit helps avoid sync errors that can be rife with haphazard usage. Using an intermediary .zip stack helps avoid the “oops, I just copied yesterdays .scriv on top of today’s” errors.

The last point I would have, in reflection and extension to what you seem to be saying, is that when it comes to personal preference that can often have a much greater influence on the integrity of a process than the inherent or statistical weaknesses of that process. We’re getting a bit abstract here perhaps—but if I prefer to handle file management manually, and find that to be simpler and more straight-forward to how I work, then pushing me toward using automation, which I find opaque and unnecessary, will more likely cause me to instigate errors into the system—even if statistically speaking, more people on average may struggle with file management.

That brings us back to the beginning here, where designing software to have several key routes by which it can be used means catering to preferred processes which in turn can lead to fewer overall errors across the whole of those who use the software, rather than coercing everyone into a single path.

1 Like
20

Nah, I was just pointing out that your level of operational maturity and self-awareness are both extraordinarily high. :slight_smile:

2 Likes