Unreliable Joplin mobile sync, solutions.. (save icon..)?

golemus · 2 August 2026 04:39

I have had numerous sync issues with Joplin and I think most of them are caused by Joplin mobile android. It might extend to IOS but I'm not sure as I've not used it on that side as much.

Root cause seems to be that often Joplin does not sync to server although you think it did. You edit a note on mobile, then switch app, go to home, edit note on desktop, then later you open Joplin mobile again and it finally starts to sync your old edits and this messes up things and content has even disappeared.

I just did a test, 1. added aaa on moblin mobile to NOTE1, switched app, 2. added bbb on desktop to NOTE1, 3. opened joplin on mobile so that it synced. After this I saw temporarily a different versions of NOTE1, as there was conflict so Joplin did 2 of them.

But after this one of them disappeared I don't remember anymore if it was aaa or bbb which disappeared but either of them did.

Some test results:

often after editing note in Joplin I change very fast to another app with home or multitask button. Even that "allow background activity is enabled" this seems to interrupt Joplin syncing the note and if you open the note next time lets say 48 hours in worst case it could be such long without syncing.

So there is at least 2 issues involved.

Can Joplin mobile sync be made so that it works reliable even when switching apps...?
How can user know if a note has been synced.

I know little about mobile programming so I am not sure how easy it is to solve 1. It does work with Standard Notes more reliably so it can be made more reliable but not sure how much work is involved and it is FOSS project.

can be solved much more easily. If user has clear feedback of state of joplin (A. SYNCED TO SERVER AFTER LAST EDITS, B. NOT YET SYNCED TO SERVER) he can be prevent sync conflict by behaviour.

I suggest SYNC/SAVE button. In beginning as optional feature which is disabled as default. One potential place fo the button would be on right side of note title and left side of drop-down menu where you switch notebooks. Another (actually ergonomically better) would be in formatting bar at left (or right) end.

This button would be RED whenever there is changes that are not synced to server and green when note is in sync with server. Also if/when it is RED you could force a sync by pressing it if for some reason the auto sync did not went through.

Opinions? I know that this can be done in left sidebar at bottom but problem is that its hidden behind too many swipes and you should really see the sync state constantly when editing notes.

DoneWorkin · 2 August 2026 17:33

I have been following this issue for quite a while and feel your pain.

Both the Android and IOS clients do not sync in the background at all. Once you leave the app it stops all syncing activity completely.
There have been several attempts made at background sync and all have proved to be unreliable and so not implemented/released. Part of this is due to the design of the app and not wanting different code bases for each platform.
When you edit - the clients do start a sync immediately upon edit in an attempt to get the sync done before you leave - but as you have found out this often isn't quick enough.

I completely agree with your suggestion of some sort of indication that a sync is ongoing so I can just wait for it to finish. I would even be happy with a red dot in the corner of the screen whenever a sync is running. Having to exit several screens to see the sync status every time I edit a note is a complete pain in my rear end.

NOTE: I am often in very poor service areas so my sync events often take several seconds to complete - those of you on high speed internet probably don't notice this at all.

_vg · 2 August 2026 19:43

I have good news for you. Check Show visual sync indicator feature of this plugin: GitHub - personalizedrefrigerator/joplin-plugin-extra-editor-settings: Adds additional settings to the Joplin note taking app's Markdown editor. · GitHub

Works like a charm for me on Android.

mrjo118 · 2 August 2026 21:42

I have good news for you. Check Show visual sync indicator feature of this plugin

Yes, was going to mention this. But bear in mind if you use the rich text editor the sync indicator is not supported with that plugin.

However there is also a project in flight at the moment to improve the conflict resolution in Joplin, a notable feature being that conflicts which are not on the same line will be automatically merged, which includes mobile support. So hopefully this will help a great deal with the lack of background sync on mobile.

_vg · 2 August 2026 22:04

This is great news

Relevant links for anyone interested:

github.com/laurent22/joplin

Automatically merge non-overlapping changes when a sync conflict is detected

opened 09:24AM - 23 Jul 26 UTC

varunkumar-22

When a same note is edited on two devices before syncing , presently Joplin crea…tes a conflict note in conflicts folder [ notebook] even if the changes are non-overlapping [ any additions/deletions] & are not genuine conflicts. For example, if one device edits first paragraph and the other edits last paragraph, there's no real conflict, but still the conflict note is created and makes users to manually resolve them. As a part of GSoC Conflict Resolution project, this feature adds Automatic-conflict resolution when the changes are not genuine conflicts. This ensures any non-overlapping changes are merged automatically and only the genuine conflicts are considered as conflicts when the base version [ a common version of both devices before conflict is detected] is available in the device in which conflict is created. ### Behaviour: Library Used: [node-diff3](https://www.npmjs.com/package/node-diff3) When a note conflict is detected during sync, performs a three way merge against the last synced version [ base: the common ancestor] before creating a conflict note. The merge is line-level, with a word-level for the edits to different words on the same line. * If every change in that note can be merged cleanly (both sides changed different parts), saves the merged note and don't create a conflict note at all. * If part of that note has genuine conflicts (both sides changed the same lines differently), still creates a conflict note, but makes the non-overlapping sections [ if any non-overlapping changes made] to merge automatically and only those genuine conflicts will be left for resolving * Titles are handled the same way: merged automatically if only one side changed the title, treated as a conflict only if both changed it differently On going this project, Conflict Resolution UI will be implemented to resolve conflicts.Notes with no recorded base (for ex: received only by download, never edited-and-uploaded on this device) or encrypted notes fall back to the existing conflict-note behavior, since a safe merge is not guaranteed there This issue covers only the merge logic in the sync layer. It does not include any UI.An optional setting to turn auto-merge on/off will be implemented in a separate PR

github.com/laurent22/joplin

Mobile, Desktop, Cli: Resolves #16020: Automatically merge non-overlapping note changes on sync conflicts (#16023)

dev ← varunkumar-22:feat/conflict-auto-merge-v2

opened 03:12PM - 23 Jul 26 UTC

varunkumar-22

+934 -0

Fixes #16020 ### PR Summary: As described in issue #16020 : When the sync …loop detects a note conflict, this new code runs inside `handleConflictAction`, just after the existing mustHandleConflict check and before the conflict note is created. So, the automatic conflict resolution is performed after the conflict detection and just before the note creation. Read-only notes, encrypted notes , and locked notes fall back to the existing conflict note behavior. **The three versions** A three-way merge needs base, local, and remote, and all three already exist: - base :- the last version this device [ in which conflict is detected] uploaded, kept in sync_items.base_body/base_title. Saved only on upload, never on download, so it's always something this device really agreed with the server. [ PR: #15669 ] - local :- the current note. - remote :- the incoming version (remoteContent). If there's no base (a note only ever downloaded ), it falls back to the plain conflict note **How the merge works (diffNotes.ts):** autoMerge(base, local, remote): - Firstly strips trailing spaces from every line. Editors sometimes leave an invisible trailing space, which causes a fake conflict (found as bug while implementing) - Uses [node-diff3](https://www.npmjs.com/package/node-diff3) library to split the three versions into parts: parts in which only one side changed, and parts both sides changed - Each part becomes a section marked as unchanged, auto-merged, or conflict. If the same line has a conflict, it tries again at the word level. This lets changes to different words on the same line merge **Turning that into two notes (autoMergeNote.ts)** From those sections it builds two versions that are same everywhere except where a real conflict is happened: - resolvedLocal : keeps the user's side for conflicts - resolvedCurrent : keeps the incoming [remote] side for conflicts - fullyMerged is true only when nothing is left as a conflict - titles work the same way: merged if only one side changed it, conflict if both did changed **What sync does with this:** - Fully merged : no conflict note will be created. The merged note is saved with anew updated_time, so it is uploaded during the next sync and reaches the other device - Partially merged : a conflict note is still created, but the changes that can be merged are added to both the conflict note (local version) and the updated original note (remote version); this means they only differ where there is a real genuine conflict. The base and the remote versions are also saved in conflict_note_states for the future conflict resolution UI ### E2EE support Initially, automerge not used to run when E2EE is enabled as we can read encrypted remote note content until it is decrypted and normal conflict behaviour is continued. So, now this case is handled by decrypting the notes which are found to be conflicts, E2E encrypted and local is not encrypted. the encrypted remote note is decrypted in memory and it is used for running automerge. If everything is merged cleanly, then the merged note is saved directly over the local note and If incase a real conflict exists, decrypted remote (along with some auto-merged changes) is used to update the original note and is also stored in `conflict_note_states`, which helps upcoming conflict resolution UI to compare against the actual remote content instead of encrypted or any empty data The local note is not decrypted; it is expected to already be decrypted during a normal sync, and if incase it is still encrypted, or if the remote note cannot be decrypted (for ex, the master key has not been unlocked), then the behaviour safely falls back to the existing conflict note behavior - Testing for E2EE handling: added additional tests in `Synchronizer.autoMerge.test.ts` for cases : merging an encrypted remote, recording the decrypted remote in the conflict state, and the fallback when decryption is not available **Settings** A new setting controls this: `sync.autoMergeConflicts` - a normal public setting under the Synchronisation, named as "Automatically merge non-conflicting note changes". It is off by default, so merging this PR does not change sync behavior to anyone , so auto-merge only runs if the user turns it on. the default can be changed to on later if required. The setting is read through a static helper (isAutoMergeEnabled()) instead of checking the setting name in different places <img width="886" height="402" alt="image" src="https://github.com/user-attachments/assets/62907ead-791e-4206-8505-d5daab1b5f8c" /> <img width="338" height="514" alt="image" src="https://github.com/user-attachments/assets/136dacff-4f46-43d7-9677-637ff7fcc3ec" /> ### Testing: Tests are added: - `diffNotes.test.ts` - the merge engine: clean merges, real conflicts, word-level merge, trailing whitespace, no-base fallback - `autoMergeNote.test.ts` - title rules and the two resolved versions - `Synchronizer.autoMerge.test.ts` - two real synced devices: clean merge makes no conflict note and reaches the other device, partial merge keeps shared changes into both, locked notes skipped Tested the automatic merge implementation across various Markdown edge cases, including images, links, tables, code blocks, lists, headings, blockquotes, checklists, nested formatting, emojis, whitespace-only changes, insertions, deletions, and mixed content to verify that merges behave correctly without breaking the document structure and all are working correctly. ### limitation: Word-level merge on a single line: if one line has both a real conflict and a mergeable change, the whole line becomes a conflict.Wrote a test for it , splitting it further is possible later but that makes the UI implementation harder ### AI Assistance Disclosure: AI was used in researching & learning about the library implementation, in writing some tests and also for data while testing various edgecases

Piotr · 3 August 2026 20:41

I always display notebook list. There's a sync status at the bottom.

golemus · 4 August 2026 00:27

I know. I use only single notebook (unless it is exception situation) so I don't have it visible. It consumes screen estate and with small display it is a problem.

Topic		Replies	Views
Discussions about Sync Lounge	29	1889	25 June 2020
One enhancement request for syncing Features	26	602	5 March 2026
Unsyncable/Phantom Notebooks Between Linux and Android Devices Support	15	920	1 December 2023
What features did you like in 2023 and what do you want to see in 2024? News	204	8503	9 September 2024
Very disappointed on Joplin and its sync problems Lounge	19	1486	1 May 2025

Unreliable Joplin mobile sync, solutions.. (save icon..)?

Related topics