zexpe

OK, just tried that now and can recreate your experience. It's possible the problem only occurs under certain circumstances, e.g. when a long time has passed and Evernote app has reloaded on the iOS device... or it's a bug that only occurs if you don't have Evernote Premium and so don't have offline notes on iOS?

That's what used to happen, but it's not happening to me now... the iOS changes were just lost.

I have never lost an entire note in Evernote. However, note content of a given note that was not synced to the server from iOS will always be lost if that same note has been more recently edited on another device and that edit was synced to the server prior to the iOS app connecting to the server to submit its edits. In this situation there should be a note edit conflict notification of some sort. This used to exist, but it doesn't currently exist: this is the latest regular release of the iOS app and has been a problem for some time now...

Evernote support were useless:

Does the iOS app no longer support conflicting edits in notes? I often have examples where I've edited a note on iOS but then closed my phone before the changes were saved to the server, then I forget the note is edited on iOS and I go and edit the same note on my Mac, which gets saved to the server. Next time I open up Evernote on iOS I notice the unsaved changes are marked as not synced to server, they get uploaded to the server, and then immediately overwritten with the version I had previously saved from my Mac. The changes to the note from the iOS app are lost (but can be found in the Evernote Premium note history). Previously this would have caused a edit conflict to be marked either in the note, or the note moved to notebook of conflicting edits. However, now note conflicts just seem to get silently "resolved" by having the changes in the iOS note replaced by the server version. At the very least I would expect that we should get a notification that this has happened even if there is no way of resolving the conflict (other than checking the Evernote Premium note history: which is not ideal if you don't have Premium), but I've never seen such a notification in recent years.

Yeah, for sure. That's why it's a big deal that we're rolling out this new beta editor on Windows right now. It means that the same editor that's being used to edit and display notes on Mac will be used on Windows. We think this'll make formatting differences largely disappear, at least between these two clients. I'm still waiting for the iOS and OS X versions to be consistent with treatment of bullet list spacing. Surely, these two platforms are the easiest to make consistent to each other in this respect?

Split it up into separate text files for each conflicted version (use Cmd-F to find each conflicted version in the same note) and then use a tool to do the comparison between the text files. You can use "diff" on the command line (e.g. "diff a.txt b.txt") or use a text editor with a comparison function such as TextWrangler or a dedicated compare tool such as Meld. It's somewhat absurd we have to do this...

Well, at least it's nice to know that others use Evernote in the same way as me and so experience the same problems... I wish we'd get some developer feedback on this issue.

The problem still exists in this Beta 2 version. Just now I was editing some text: typing in some characters, indenting a bullet and pasting a URL. What should have happened in about 1s took 10s!

I still have this issue on large notes; it was literally beach-balling on me just now. BTW, for anyone else with large notes that use Evernote on more than one device, I highly recommend doing a search for "conflicting modification": you may be surprised by the results!

Previously when there were conflicting modifications in Evernote notes a duplicate note was created in separate "Conflicting changes" notebook. I've just noticed that this behaviour seems to have changed in newer versions and the conflicting content now occurs at the bottom of the note. So far I've found two notes in my library with conflicting modifications from back in January and February. I never received any notifications of these conflicts and the notes have since been edited so it's impossible to see what the original conflict was! Please, please, if there conflicting changes please give me a notification when it occurs so I can fix it without losing data. It's impossible to do months later. And just putting the conflicting changes at the end of a long note does *not* help! I won't notice it and it isn't easy to fix... I preferred the old system. At least creating a duplicate note made it obvious that a conflict has occurred!

Apparently, they are "working on it": https://discussion.evernote.com/topic/79836-slow-typing-responses-in-evernote-for-mac-605/page-3#entry346586 But this doesn't give me much hope about the quality of Evernote's software design...

I'm pretty certain it's related to the changes made to syncing, where updated notes are automatically synced (whilst you are still editing them!). Normally when I quit Evernote it quits immediately. Whenever I have the slowdown when typing a note into Evernote I quit Evernote in the hope that restarting it will cure the slowdown (it always does) and every time I quit Evernote during such a slowdown I always see a dialogue window announcing that Evernote is currently syncing and will quit when it is finished. It normally takes a few seconds (up to about ten) for the dialogue window to disappear before Evernote then quits. I'm sure this slowdown is related to the fact that that (slow) sync is taking place on a note I'm currently editing and possibly the fact I'm currently editing it is causing the sync to keep restarting and thus slow down the typing even more... it's probably some kind of race condition that doesn't always occur when editing a note, but when it does occur it ends up in a feedback loop and will keep getting slower until you quit Evernote giving it a chance to get the sync done.

So, does the latest beta fix this bug or does it just introduce new bugs?

But no specific mention of this particular heavily-reported bug being fixed, but it's only at Beta 1 release so far...