My feature request is to have a progress bar of the synchronisation at the top of the page for the Android version of Joplin (or perhaps all of the mobile clients). Right now I need to remember to open the tabs view and check if my notes are being synchronised.
This would help the issue of conflicting notes since that is the reason that I check the sync status of my notes. This is not a problem on the desktop version since I can always have the page with the sync status open.
Better feature would be speeding up sync speed on android. On desktop about 100 items is synchronized per second. But on Android, sync manages to process about one item per second only.
@horvat Are you using file system sync? It’s a known limitation on Android that it is very slow. You can work around this by running a local WebDAV server on your phone which serves the directory you want to sync
Sync speed is affected not only by target, but by client as well. I’m syncing to selfhosted WebDAV without encryption. On desktop, sync speed is reasonable, comparable with syncing to local directory. Sync to android is considerably slower, with only a few items per second synced.
I asked ChatGPT the likely cause of slower sync on Android, after giving it context of what I know from reverse engineering the Joplin code. These answers seem the most likely causes (aside from varying sync speeds dependent on the sync target / server used). The first is a SQLite for Android limitation and the second is a React Native limitation, so neither are solvable without completely re-writing the app
Most Likely Causes (with filesystem/server/backgrounding eliminated)
1. SQLite Write Performance on Android
While filesystem APIs are bypassed in the sync process, the SQLite layer itself on Android is inherently slower than on desktop:
Joplin writes downloaded items (notes, resources, metadata) into its local SQLite database.
On Android, the SQLite engine is often slower due to:
WAL (write-ahead logging) may be disabled or less optimized on mobile.
Storage performance (even on fast phones) is limited by I/O contention and limited fsync throughput.
Joplin does not batch writes very deeply — this becomes a bottleneck when syncing thousands of small items.
On Android, SQLite performance is often 2–5× slower than desktop for bulk inserts due to this overhead.
There are GitHub issues in various SQLite-based apps citing this. Joplin also acknowledges SQLite overhead as a factor in sync time, especially on Android.
@vetlehh In terms of your feature request, it’s probably difficult to efficiently determine live progress for every type of sync target. However I think what you are really interested in is a simple indicator within the note view, indicating that a sync is in progress. This has been attempted to be implemented twice, but unfortunately both code changes were rejected due to Laurent not wanting to have duplicate code and therefore it requires some UI redesign. This resulted in the feature being implemented within a plugin instead (see Joplin Plugins - Extra Markdown editor settings ). While the plugin is maintained and supports mobile, unfortunately it does not support the rich text editor on desktop nor mobile
Thank you so much! Because that was exactly what I had in mind. Will need to try out that plugin sometime this year (it is a good thing that I don’t use the rich text editor.
If these things are the bottleneck, wouldn't anyone syncing from android be having the same issue? I'm also syncing between Android and Linux. I haven't actually investigated my speeds, and I'm not using encrypting, but sync seems to be nearly instantaneous for me.
@Tink There is a probably a lot of varying factors to be honest. I’m not saying sync on Android is always what can be considered as slow, but it may be warranted that there are archetectual limitations that can make sync on Android slow-er than on desktop, depending on certain factors. I havn’t done a proper benchmark comparison with my own profile, but I have felt a general sense that the sync is a little slower on Android, but not by much.