Ah, but there’s the rub. They were demanding Apple give them a free replacement.
1 Like
“I did my best – I argued for hours but they just wouldn’t relent. I tried everything I could, even went down on my bended knee. So you see it’s really not my fault I had to buy this new laptop…”
1 Like
Hi Guys, I’m Marco and i’m using Scrivener for my first book. It’s been a year and half now. I’m not really a forum person but I like to read conversation etc.
I can suggest my workflow and although is not a syncing thing as you would desire it works for me.
90% of the writing is on my Mac. I saved the file in iCloud. So when i’m need to review on my ipad mini because i thought of something during the evening, just for an example, i just click on the file from Files app and it open straight away. I’ll do my changes or adding some notes and, once i’m done, i just replace the file on Cloud with the new one on my device. Then to make sure, i’ll just removing from the device once the upload is complete.
Is not a real syncing, i’m aware but it does work.
Extra note: when you open the new file on the mac, it tells you in the binder ‘sync document section’ which section have been updated.
Also … from my low knowledge of coding and I don’t want to create any more caos in this long icloud chat 
, could it be … providing on iphone/ipad an open from location instead of copying on the device an alternative to a real sync? or this would be anyway a syncing operation?
Of course you should have open the file on just one place, or the mac or the ipad or the iphone … but who does work on the more then one device at the same time?
Guys be polite on this last sentence At the end I don’t want to argue. It started as a workflow sharing that might help people if you never tried it 
Marco
On iOS devices, you don’t have a full shared filesystem like you do on MacOS – each program gets its own little “sandboxed” storage area that only it (and a couple of system utilities) can read/write to. This keeps malicious or badly-written applications from rifling through all of your data.
One of those system apps is the Files app, which is how you can use that to transfer files between app sandboxes. Regular apps can’t really do that.
Many people do – it’s as simple as “I was working on this project before I left for work/school, had to answer the door, and forgot to come back to close my project before I walked out the door.” Luckily, the Mac and PC versions have a shutdown timer where if they are inactive for a configured period of time, they will automatically save and shut down. Some people don’t take advantage of this because they want to keep Scrivener on all the time, so they will run into issues, it’s a great feature for many of us.
1 Like
We’re going so far off topic as to miss the point of what I was saying, but yes it is possible to guarantee. There are numerous apps who won’t accept new input until it is confirmed stored in a central backend. Can’t save at all == no sync conflict.
That’s totally implausible and useless for a writing tool that needs to operate detached, so HERE we actually get on topic. It’s not impossible to avoid sync errors, but it requires making a completely different set of choices/priorities that an app that needs to work offline and not hang if internet is unavailable will make.
These are completely different sets of needs, and expecting a fixed-price, pay once app focused on being easy to use no matter what circumstances to be able to do guaranteed sync with centralized locking is unreal. Different use cases. As you said:
Well $DAYJOB operates a streaming service, so if your Internet is down you can’t use the service anyway. Our text APIs are going to work any time you can successfully use the service 
Thus my point. You picked what was important for your users 
Someone who wants instant sync anywhere has different needs.
There are numerous applications that will guarantee sync. If it’s important to you it can be solved.
Guaranteed sync is not important enough to Apple (or their customers based on relative happiness) to disrupt the easy user interface they provide.
1 Like
I think we’re describing the same thing in different ways. Certainly we agree that refusing to save at all is not an acceptable solution to the problem for Scrivener’s user base.
You are being ridiculously pedantic. Yes, in theory, with bucketloads of money you can do most anything.
Within the bounds of reasonable services available to the average user, what you claim is not practical. Why not give it a rest.
1 Like
This conversation beggars utter confusion. There are dozens of free apps that provide guaranteed sync. Banking apps, stock apps, …etc tons of examples, can’t accept inconsistent state. If you can’t sync state, you can’t use them. They have different needs.
Likewise, code tracking and other shared data applications totally accept and provide zero data loss with inconsistent sync. They force the conflict resolution down to the user, which is acceptable for their uses. Different needs.
There’s no “bucketloads of money”, it’s just different use cases, different needs, and different audiences. Which is the point I was making–I think that L&L chose the right set of needs to address, and that instant sync–while totally possible–requires a different set of priorities.
But nevermind, who needs to be rational. If Apple can’t sync Reminders consistently with their free service, then clearly this problem is unsolveable right? Logic need not apply. Let’s just keep claiming it’s impossible in defiance of basic observation, rather than address that it’s impractical. My apologies for being rational, I won’t make the mistake of posting again.
I’m not sure how the fact that I can’t talk to my bank without an internet connection is relevant to a conversation about Scrivener’s handling of synchronization conflicts.
A writing application that provided “guaranteed synchronization” in the way you define it – doesn’t work at all without internet access – would no longer be Scrivener in any meaningful way. This is sort of like arguing that powered flight is possible in a conversation about bicycles.
FWIW, such an application used to exist. It was called Google Docs, and an offline mode was one of the first things they added.
Exactly. That’s what I said – this argument about “other apps can guarantee sync, why can’t Scrivener” is pointless because those apps serve a different need, that has different priorities and thus different constraints. Because other apps (with entirely different use cases) can do it doesn’t mean that it makes sense for every app to do it.
But why be rational. I quit this conversation so that ya’all can go back to saying cloud sync never works, is impossible, nothing more than a hat trick.
(and I will not be responding again, no matter how far and wide you go to deliberately misread my entirely practical statements on this)
Your contradicting yourself.
If you can’t sync, they don’t guarantee sync.
My banking app require internet connection of a certain speed. If things take too long, it will log me out. So it doesn’t provide “guaranteed sync”.
A few days ago I was writing a rather long message, tapped “Send”, and after a while I was informed that something went wrong and was kicked out. I logged in, no message sent.
An app that guarantees sync, no matter what, needs to guarantee some kind of communication system, in itself. An app with built-in internet comnection? Not very likely…
I think in a good quantity of those cases, it would be more accurate to refer to that as a client - server relationship, where each transaction is announced, sent, and verified, then vice versa. We might think of the two elements of the equation being “in sync”, but this would be a broad and somewhat nonspecific use of the term, rather than equating it directly to the same sort of technology that offers to keep multiple file systems synchronised with one another, down to the byte, when said systems can all be taken in and out of the ongoing pool of systems that is currently being synced. I.e. you have to log in, and everything you do is done live at that point, until you log out.
There’s no “bucketloads of money”, it’s just different use cases, different needs, and different audiences. Which is the point I was making–I think that L&L chose the right set of needs to address, and that instant sync–while totally possible–requires a different set of priorities.
Sure, I suppose to the extent that there was much of a choice to be made, you could say that. It is true that choosing a client-server model would not have been a good idea for this particular use, and so we chose to go with so-called “cloud sync” instead, and within that realm, one in particular that had the necessary tools to reinvent a basic sync client since iOS completely lacks the capability for full-scale sync clients to talk with software (and indeed the hardware cannot really handle that kind of system anyway, it would drain the battery in minutes). That latter part of the decision was the important part, to my mind—that was a choice between Dropbox and a few other options at the time, where none of the others had a compelling toolkit, and few still do to this day.
But I would say that was more the choice though, made between systems that fit within the definition of file and folder level syncing—not between that and other things entirely that nobody was asking for or wanting.
I think this is something you’re saying yourself, in how you are phrasing things, so to be clear I’m saying this for the benefit of “the thread” as well, and to return to the topic at hand: what you’re describing isn’t iCloud. It isn’t OneDrive, or Google Drive, or SpiderOak, or Box, or Sync, or Tresorit. Nothing that we would think of as “sync” would be described in the terms you are giving. That’s fine to bring it up, but it was never a rational choice, no more than building our own Scrivener Terminal and selling it as a way to connect to the Literature & Latte Mainframe.
Likewise, code tracking and other shared data applications totally accept and provide zero data loss with inconsistent sync. They force the conflict resolution down to the user, which is acceptable for their uses. Different needs.
Well that is much closer to syncing in the “cloud sync” sense that people think of when they say they want sync. It’s not quite the same because these systems tend not to to be “always on”, but more importantly, they have a very high level of maintenance overhead that comes with their usage. Again, I think you are saying that as well, but for the benefit of the thread: this kind of technology isn’t what people are thinking of when they ask, “why do you only support Dropbox?”
That said, in a much less intensive way, that latter point you bring up is precisely what systems like Dropbox do. They put the burden of conflict resolution on the user. In most cases that means opening up two files and comparing them with anything from a human scrolling through and reading things manually, to using some kind of comparison software or technology to help them. With programs like Scrivener, it means parts of its storage format get redundant conflict files, and it is upon the software to reveal those breakages so the user can solve them—and that is what we do.
Now Scrivener does make some lossy choices under some circumstances—we do for that very reason, that not doing so is extremely high maintenance and results in a large quantity of false positive conflicts that frustrate people. It means someone may get burned rarely, but it’s very difficult for that to happen and generally requires one to make very poor decisions about how they use technology. By a large majority, Scrivener’s use of cloud sync technology does not result in data loss. It has multiple safety nets and versioning mechanisms in place to avoid that.
But why be rational. I quit this conversation so that ya’all can go back to saying cloud sync never works, is impossible, nothing more than a hat trick.
I don’t think anyone is saying quite that, but even so I’m not quite sure I follow what it is you are putting forth here. As you say yourself, you’re talking about a different kind of technology than cloud sync, so it doesn’t seem applicable to the argument of whether that type of technology would find this capability difficult or indeed impossible. Something can be rational when the scope is set to a certain range, but become irrational in a larger scope, would you agree?
2 Likes
And this proves my point. Banks spent truckloads of money, getting their systems and processes to work. One of ours poured a ton of money down a hole to only start again.
Yet, as I sit in my motorhome typing this, I have already been unable to log on to my bank or e-trade due to scrappy 4G coverage, (in a major regional town 90 minutes from Sydney) so no ‘guaranteed synch’.
1 Like
Nobody has said that. I think a lot of us are talking past each other – in that Scrivener’s project format was designed to provide specific benefits and objectives that in turn render it a poor candidate for the kind of mindless synchronization that many end users are used to seeing in their applications.
Everyone seems to be agreeing on this point, we’re just coming at it from different directions, and creating some needless friction when we’re misunderstanding or misinterpreting the points that people are trying to make.
1 Like
Ditto. My credit union often logs me out before I can finish adding a bill-pay transaction, balancing the checkbook, or sending a message to them.
1 Like
All major banks in Australia offline for a good part of today.