Scrivener iOS syncing via Dropbox continues to crash the app

[KillerWhale]

Lunk, when Catalina stopped supporting 32-bit apps, devs did not throw their hands in despair saying they do not work anymore. They had to ship updated apps. So if Scrivener is relying on methods that are slowly becoming unreliable, the app needs to be updated in a way that will work.

[NoHope]

Lunk, when Catalina stopped supporting 32-bit apps, devs did not throw their hands in despair saying they do not work anymore. They had to ship updated apps. So if Scrivener is relying on methods that are slowly becoming unreliable, the app needs to be updated in a way that will work.

This is all speculation.
What is known is that Scrivener is not the only app impacted which suggests an iOS issue and one where Apple have not given warning of any change that could cause.
L&L have nit been able to replicate which means it’s a slippery sucker of an issue.
Beyond ghat it’s all guesses, chest beating and finger pointing.
Perhaps we should provide all the information we can to assist L&L and leave soap boxes to the politicians.

[devinganger]

Lunk, when Catalina stopped supporting 32-bit apps, devs did not throw their hands in despair saying they do not work anymore. They had to ship updated apps. So if Scrivener is relying on methods that are slowly becoming unreliable, the app needs to be updated in a way that will work.

At a very simple level, the necessary step to update a 32-bit app to a 64-bit app is to update the compiler and tell it to recompile the existing code as a 64-bit app. There's usually very little else to do if you don't actually need to take advantage of the features that 64-bitness gives you (which, honestly, most programs don't need).

Scrivener 3 just underwent a major, multi-year re-write, which already involved changes to the project format to provide better support for sync use cases (as well as updating to 64 bits for future proofing). These re-writes were based on the developer documentation that Apple and Dropbox make available. Now, after years of working satisfactorily, something changed and it wasn't in L&L code. Until L&L can determine *what the underlying cause is* -- what Apple or Dropbox changed *and didn't tell devs they changed* -- they don't know if the change is classified as a bug (which can be fixed) or a feature (which needs to be coded around), let alone how to achieve the latter. And the "solution" you've casually tossed around would require a complete restructuring and re-write, which could very well destroy the very features that attracted users to Scrivener years before the iOS version and sync became a thing.

[KillerWhale]

(Regarding the conversion to 64-bit: this is not as simple as you suggest, DevinGanger. Many APIs became deprecated and some apps needed a complete rewrite. Which some devs have done, and others have, indeed, not, leaving the app users stranded. It was mostly a reply to lunk's argument which is not, either, as simple as it seems.)

I am attached to Scrivener because it's an awesome app and it truly allowed my writing career to reach new levels. I have even been an affiliate for many years and evangelised many of my pro colleagues with great pleasure, believing in it and its team 100%.
But since this whole sync story began, I am just finding the replies by support deeply unsatisfactory and, frankly, disappointing to the point of being infuriating, even for an indie dev. You don't see DEVONtech, Pixelmator, Affinity, Procreate, Omni with such a discourse (okay, maybe DEVONtech). I need Scrivener to make a living and I am trusting the app to work. Now I cannot trust it anymore, not even so much out of the bug itself, but because the replies by support are frankly baffling to me. Next time a serious issue arises, I am not sure it will be taken to heart either.
But the point is taken, and I have probably been taking too much bandwidth of this thread but it was out of passion. I'm wishing LitnLat success in fixing whatever the issue is. As for me, I give up. I'll be transitioning to Ulysses and pulling my recommendations as well as cancelling my affiliate contract some time next year.

And happy writing to everybody, because in the end, that's what matters

[drmajorbob]

Lunk & KillerWhale:

Scrivener's sync code isn't broken, as it never existed. Dropbox and other cloud services do synchronization. Scrivener doesn't and never did, so it's hard to imagine "fixing" Literature & Latte sync code in this situation. iOS Scrivener only TRIGGERS the iOS Dropbox app (via the Dropbox API) to do certain things ... and Dropbox (or iOS) is failing for a tiny % of users. It's SUCH a small % that Literature & Latte hasn't observed such a user in person.

To replace Dropbox functionality in Scrivener code would be onerous beyond belief, and converting Scrivener to exploit the iCloud API would be just as bad or worse. I gather there's nothing in that API to accomplish what's needed.

For certain, either of those hypothetical solutions would come far too late to satisfy you.

Meanwhile, it's not a lot of trouble (though annoying) to sync via iCloud on your own, through iCloud Drive and the iOS Files app. You're not high and dry — just inconvenienced a bit.

[lunk]

Lunk & KillerWhale:

Scrivener's sync code isn't broken, as it never existed.

Yes, I thought that was what I wrote ...

[keyladamaer]

Now, after years of working satisfactorily, something changed and it wasn't in L&L code. Until L&L can determine *what the underlying cause is* -- what Apple or Dropbox changed *and didn't tell devs they changed* -- they don't know if the change is classified as a bug (which can be fixed) or a feature (which needs to be coded around), let alone how to achieve the latter. And the "solution" you've casually tossed around would require a complete restructuring and re-write, which could very well destroy the very features that attracted users to Scrivener years before the iOS version and sync became a thing.

If the problem is caused by Apple or Dropbox, then why doesn't Scrivener support ask their dev teams what they changed without saying it? Because it's not like a user can do that. It's obviously a technical problem that experts should try to solve.
I wish I lived closer so I could give my tablet for testing, but I don't.

That said, I updated to Scrivener 1.2.1 on my tablet and it still syncs the only project I left in the sync folder.
I'll try to add more projects and see what happens then.

[kewms]

If the problem is caused by Apple or Dropbox, then why doesn't Scrivener support ask their dev teams what they changed without saying it? Because it's not like a user can do that. It's obviously a technical problem that experts should try to solve.
I wish I lived closer so I could give my tablet for testing, but I don't.

You're assuming that we haven't?

Again, without a reproduction case, it's very difficult to have this kind of conversation.

Katherine

[devinganger]

If the problem is caused by Apple or Dropbox, then why doesn't Scrivener support ask their dev teams what they changed without saying it?

Given the n umber of times KB has openly discussed developer tickets he's opened with Apple concerning various Mac and iOS bugs over the years (and how long it has taken Apple to move on some of them), I have no reason to believe that they haven't been doing *exactly* that.

But Katherine's point is valid: how do you get Apple (or Dropbox) to provide support for a bug that you cannot document?

Without a reliable reproduction case that L&L can strip down to the simplest set of circumstances and demonstrate the underlying bug *every time* (or at least under a known set of circumstances), any ticket they open with Apple or Dropbox will be ignored. They have to be able to show "we call this method and should get result X, but instead we get result Y" in order for Apple or Dropbox to agree "yes, the error is in our code, not yours." And then Apple/Dropbox have to decide it's a *big* enough error that they will devote the appropriate resources to troubleshooting how the bug is happening, create a fix, and then test it to make sure that bugfix doesn't cause problems for someone else (many, many bugs are first introduced during patches introduced to fix another bug). If they have higher visibility, higher-profile bugs, this one could wait for a while.

Literally the biggest thing we as users can do to help get this issue fixed is to keep reporting the issues we have *and turning in our projects that cause the issue*.

[drmajorbob]

If I had a device exhibiting the problem, I would mail it to Literature & Latte in a heartbeat. Replacing it would be expensive, but I could live with that, and I'd do it for the good of the community.

Can't someone out there do that?

[HathWrites]

Can anyone tell us what devices L&L are using for testing? Because reading this thread, it seems pretty obvious that the issue is bound to certain devices under certain versions of iOS/iPadOS (like, the latest?), except maybe for the 12-inch iPadPro. Do they even have the right devices to test for that issue? Because if they don't, it's no surprise they can't replicate it.

I haven't tried it (because I, like most of the people coming to this forum, am very busy writing and don't have time to do debugging for an app that I paid) but from my experience, duplicating the tutorial enough time and syncing it would be enough to trigger it, seriously.

It happens so much and with so many different kinds of projects that if you have the right gear to test with, I feel like it's impossible not to replicate it. So my question is : with what devices are the L&L people testing?

[lunk]

reading this thread, it seems pretty obvious that the issue is bound to certain devices under certain versions of iOS/iPadOS (like, the latest?),

No, it’s not.

[devinganger]

Because reading this thread, it seems pretty obvious that the issue is bound to certain devices under certain versions of iOS/iPadOS (like, the latest?), except maybe for the 12-inch iPadPro.

There have been conflicting reports about this, so while it looked that way initially, further error reports have shown it not to be the case.

[drmajorbob]

It happens only on iOS 13 and iPadOS, but otherwise, there's no reliable pattern.

There has to be a piece of code somewhere in iOS 13, just ONE LINE perhaps, a line used by the Dropbox API, that fails on a random selection of CPUs, many of which SHOULD be identical. Very bizarre. Perhaps it's determined by other apps installed, but that would be odd.

That line of code can't be cornered and identified without a reproducible case, and Literature & Latte doesn't have one in hand.

[scshrugged]

Just a shot in the dark, but I've not seen it mentioned and it's easy to check....

iOS 13 introduced a feature for cellular and Wi-Fi called Low Data Mode. I've read that for some iOS users when they've enabled then disabled it, it has reenabled on its own. The feature is set per network and the Wi-Fi preference (cellular too?) gets synced via iCloud. I've done limited research and have not found thorough technical information about the feature. General information, including how to enable/disable, from Apple:

https://support.apple.com/en-us/HT210596

"You might want to use Low Data Mode if your cellular or internet plan limits your data usage, or if you're in an area with slow data speeds."

That could be useful or not depending upon user location and conditions at a point in time, and of course, if it actually works properly with each piece of hardware/circumstance for which it's available.