I’m in the process of updating to iOS 8.0 on my iPhone and iPad. I notice that it now incorporates a feature called iCloud Drive which sync’s Mac, iPad, iPhone and PC and probably offers deeper synchronisation knowing Apple.
I know, originally you were talking about using Dropbox for syncing between the Mac version and iPad version of Scrivener, and for that matter, I guess the Windows versions as well. But does the introduction of iCloud Drive now offer an alternative, realistic option worth considering with the advent of the iOS version of Scrivener for the iPad and iPhone?
Only if iCloud Drive is accessible to non-App Store and non-Mac users. And only if it handles Scrivener projects correctly, which the current version of iCloud does not.
My limited understanding is this: Windows users (who can access iCloud Drive) would be classed as non-Mac users, but I wouldn’t know about the technical in’s and out’s of handling Scrivener projects correctly, maybe a little clarification from Keith or someone like AmberV Could throw some light on this.
I might be wrong, but I think that iCloud Drive is a different product to iCloud. Now I know that Keith said there were issues around iCloud one of which was the ability of iCloud to accept hierarchies of files, but iCloud Drive may be different.
That’s correct, the former is essentially like Dropbox, rather than the existing MobileMe cough, I mean iCloud walled garden system. And yes, it will be available for Windows—actually it is available for Windows. Ironically, it is Mac users that still have no access (well, outside of 10.10 beta testers).
So the first matter in adopting anything officially is to see whether their technology is safe to use with complicated and “active” file formats like Scrivener’s. While these services all work using the same high-level principle: keeping multiple machines up to date at the file system level, not all have the same degree of reliability in doing so. We for instance advise against using Google Drive because it has been known to cause serious issues with anything other than simple single-document open-and-save file formats. Who knows whether Apple’s technology will be reliable or not. It will take fearless users testing it to find out, over a fairly long period of time.
The second matter is of course whether Apple provides a solid synchronisation API for their less flexible iOS systems. I’m sure they will, in theory, but it may not be cut and dry for what we need. On account of how their iOS appliances can’t fully multitask or share resources between programs, we have to hand code these interfaces, and that means extensive programming and testing. We ran into a surprise with Dropbox, when it was discovered that the API most people use for iOS development would not be adequate or safe for what we needed of it. We basically had to recreate a chunk of what Dropbox does, using their much deeper level core SDK. That may all sound like gibberish: it means we had to reinvent a bit of the wheel because the easy to use stuff that Dropbox provides wasn’t good enough. Hopefully iCloud Drive’s programming interface is more powerful, but we aren’t even looking into it yet because of the above.
Given that, we have decided to support one synchronisation service for 1.0: the one that most of the world that uses sync, uses. We aren’t going to push back the release schedule for a sync tool that isn’t even out yet or may, as adoption rates increase beyond a handful of beta testers, in the coming years, prove to be statistically unreliable.
And for those that don’t want to use Dropbox, or sync in general, it is very easy to drop projects onto the phone or tablet with a file management tool—even iTunes works at the very least, for that.
Just to add to what Ioa said: After iScriv 1.0 is out, we most certainly will be looking at what we can do with iCloud Drive. We just didn’t want to hold up an already much-delayed product trying to implement a new sync system, and then have to test two sync solutions out simultaneously. Once Scrivener for iOS is stable and we’re all confident the kinks in the syncing routines have been ironed out, we can look at transposing those routines to other sync solutions too.
Thank you for the detailed reply, both of you. This is exactly the kind of response I was hoping for—a detailed, thorough and with weighted considerations.
So, to surmise, what I gather you are saying is all positives arise from he who weighs considerations. Even if the positive is a, “don’t go there” negative—if you see what I mean )
I really hope you consider adding an option for Sugarsync (once you’re live and stable and ready to add sync solutions, of course). They are the most dependable for live sync, and don’t require users to move their projects into a specific folder.
Once we’re confident the Dropbox sync is working smoothly (after 1.0 is out in the wild), we’ll be able to look at other sync solutions. As long as they have an API and work similarly to Dropbox, we can consider them.
Until “done” loses data for folks. If you notice, most of the issues with data loss here on the forums is folks using sync services. KB has too many folks dependent on scrivener for their lively hood to do anything less than “as close to perfect as possible”.
What Jaysen says. People get very upset when their data disappears. And, in my experience, they always initially blame Scrivener, no matter how tangentially related to Scrivener the data loss was.
Poor synchronization experiences involving iCloud Drive (or any other service) will hurt us more than Apple. After all, iCloud Drive “just works” for Apple’s own software…
)