I believe every device connected to your account must support the feature, or none of them get it. I’ve not been able to enable it on my account as we have one really old iPad. It tells me to remove it from the account if I want ADP (last time I tried anyway).
(Apple One account, so we’re talking a dozen devices across the family)
That sounds logical:
iPhone: iOS 16.2 or later.
iPad: iPadOS 16.2 or later.
Mac: macOS 13.1 or later.
Just an fyi: ADP was withdrawn from the UK last year:
I’d just like to point out the the OP is on Windows. iCloud is pretty terrible everywhere else, or non-existent if you’re a Linux user.
There are plenty of good options out there that provide good security that aren’t bound up in selling hardware as part of their gig.
I successfully use iCloud across a combo of Mac and Win, however my preference is Sync, mentioned earlier. It works for me and two big plusses, encryption and outside of the US.
We only use third-party technology partners we have vetted.
From the Dropbox docs. That makes me feel so much better.
If you prefer something other than DropBox, Proton Drive might also an option. I would also stay away from iCloud (which can also be configured to encrypt your data) for the same reason others have mentioned – sometimes it doesn’t sync right away. According to Proton, not even they can access your data.
In the end it comes down to if you want to use the cloud securely, you need to do the leg work. I’d prefer that Scrivener refrain from adding encryption features, and instead focus on being the best writing app. This encryption isn’t a problem Scrivener should need to solve.
I suppose its another “use at your own risk”. I don’t know how Proton handles packaged files. Looks interesting. I personally don’t have any compelling reasons to move off of Dropbox, but there is now a less than zero chance of them being gobbled up by someone else given their struggling financials (if rumours be true).
I suppose its another “use at your own risk”. I don’t know how Proton handles packaged files.
I always recommend testing anything you decide to use that doesn’t have a lot of testimonial behind it.[1] But to be clear, all syncing is used at your own risk, and there is no service out there that will protect you from yourself, which is in my experience the largest risk in the equation, by far. The technology itself doesn’t have a ton of variation; there are only so many ways to do this thing.
I would have one nitpick though, as for “packages”, this is another one of those myths to be aware of. I’m sure Proton can sync them just as well as it syncs any other folder with files in it. In fact I would say the chance of failure or problems is higher the more a service is “aware” of Mac conventions such as treating some folders as files. It has historically been a lot more difficult to recover your data out of the Dropbox app on iOS, or their website, for example, because they actively discourage examination of a folder’s contents if it matches commonly known Mac naming conventions. I’d rather sync be entirely and completely unaware of such things, and treat it just as it does any other large folder.
I entirely agree on the last point, or the implication of it, and that is how important zero-knowledge encryption is. I might trust Tresorit and the third-party security audits that clear them, or Proton, but do I trust what happens when/if they go out of business and sell off to Meta or Google? Nope! Good thing they don’t have my keys. It is still not safer than keeping your data off of the Internet entirely, but if you’re going to, at least lock the door, and if your service always has their foot wedged into it, give them the boot. They aren’t worth it.
Though you do have to be careful of testimonial, or what appears to be that. There is a pile of confusion out there on this topic, and probably not a small amount of grassroots marketing and LLM regurgitation making a mess of all information as well. ↩︎
One slight quibble here. One key to avoiding sync issues is for the service to upload changes promptly, keeping the copy of the project on their server as close to the copy on the current computer as possible. In particular, changes to the .scrivx project index file need to happen in sync with the corresponding additions/deletions of actual data files. That is, a project is not just a “large folder,” it’s a large folder in which the relationships between documents are as important as the documents themselves.
Services that – perhaps in the interest of “performance” or “conserving bandwidth” – attempt to “optimize” the order in which things are uploaded/downloaded are more likely to cause problems than services that don’t. In theory, a service that is aware of “package” structures should be able to make smarter optimization decisions. (In practice, well … for a long time iCloud was one of the worst offenders, even though “packages” are an Apple thing. )
Yes, maybe a better and less ambiguous way of putting my thoughts on the matter is that I prefer sync services that work as simply as possible, to just copy stuff up to their server the moment a change is detected, and download from the server the moment it updates, and for it to always to do that (i.e. no “smart” sync). You do that, and it doesn’t matter if your folder is coming from Obsidian (not a package), Scrivener (a package), a video editing suite (not a package) or GarageBand (a package). All of these things want their files immediately, and likewise you want your own loose files in a folder immediately when you switch systems. Nothing should be holding anything back from you, based on its kind—that’s basically what I’m getting when I say packages shouldn’t be treated any differently.
That is how this technology worked in the early days, and by and large I think most people will agree it worked better back then. Where this tech got messy, unreliable, slow and at times even dangerous is when companies started over-complicated the equation with scheduling, proxy file systems, “smart sync”, data analysis and a raft of other such things. The evidence of this decline in what I would consider to be simple integrity can be seen all over the forum.
Thankfully, most smaller and security-first services do keep things simple, in part because they kind of have to when they don’t know anything about what the user is uploading, and that includes knowing whether the data it is transmitting is from folder that a particular operating system that connects to the network might consider to be something it should display specially, in its GUI.