I’m going to call baloney on blaming iOS/iPadOS for the protracted syncimg issues, background syncing issues, startup issues, etc. I have way too many other apps that do not have this issue.
There are fundamental assumptions being made by the Obsidian developers that are probably only partially correct, and they can’t see it likely because of their own unconscious bias and maybe some lack of experience, idk.
I am a software engineer with mobile and large enterprise system design, architecture, blah blah blah experience. I’ve had to solve this problem over and over again, most of the time because a software developer doesn’t know how to do incremental syncing on disconnected devices when metadata and indexes are involved.
The first thing to solve: load the UI in its last known state and assume statelessness, meaning be skeptical of the the local files state. Allow the user to use the app while you sync in the background. Since Obsidian was built on Node.js and Electron. Electron has a small flaw on iOS and iPadOS… where to store volatile metadata files like the indexes, file lists, etc. Because the developers have chosen to store them on the .obsidian directory instead of the default location iOS and iPadOS expects, the developers are subject to iOS/iPadOS offloading the core files of the app. It appears, with Obsidian Sync they are trying to handle this more elegantly, but they are still putting synchronization as a foreground process even while Node.js and Electron allows this to be a background process called asynchronous communication using async, promise, and callbacks. There is also a collection of design patterns in software engineering for distributed systems that should be used but seems like they aren’t. This is a pretty common skills development problem in software development because front-end/UI developers using don’t have the same skills as a back-end developer developers, and people that claim to be a full-stack developer (front-end and back-end) usually are a master of neither. Nor can they be. This stuff is just too complex to really master both. So while this post could be read as an indictment against the software developers at Obsidian, I think it is more likely an indictment against the management’s understanding of the different skill sets (and different people) needed to build a robust distributed application ecosystem.
Or I could just be wrong and something else is going on.
The fact that there are so many other commercial distributed apps built with Electron and Node.js that sync just fine points towards design decisions and lack of skills by the development staff at Obsidian. (Cough. Notion. Cough.)
The old saying is, “Engineers are great at not planning for the success of their products. We struggle scaling beyond our initial design.”
I really think that is the case here.
Hopefully someone at Obsidian reads this and digs into what I’ve said. This app has so much potential but still fells like something just hacked together for their own, initial use case. Often refactoring an app means fundamentally changing the BUSINESS model, what you charge for and what you don’t. I paid for Obsidian Sync and I don’t use it because it stinks and there is no assurance of data privacy or security. That forced me to switch to iCloud sync. And that REALLY doesn’t work. Why? Because I have over 30k notes that are hyperlinked in a knowledge web. Obsidian isn’t designed for that, wasn’t designed for that, and doesn’t seem to be using design patterns that would handle concurrency, supervisor, semaphores, deadlocks, observer/observable state, stateless distributed data accessors, and other challenges that comes with multiple application instances on different platforms being used simultaneously.
Obsidian has been a game-changer for me, and this has been the only major hitch. If we know the Capacitor plugin won’t work, I need to see if I can find another creative solution. I have some ideas, but I don’t want to try something that the experts already know won’t work.