I don’t think push based syncing will help the mobile app finish uploading changes after the app has been quit. This is a case where the only viable solution may be iCloud-based syncing, unless Obsidian Sync can be updated to use URLSessionConfiguration.background or BGProcessingTask.
This doesn’t help the main case of using the app on a phone without worrying about Sync, but on iPadOS 26 it seems that windowed apps are considered active even when not currently focused, so Sync will still work when Obsidian is (for example) hidden behind 2 other windows. Baby steps!
1 Like
Hello!
Push based sync could trigger the app to launch in the background. The app should then simply check what needs to be synced and launch a short process to upload/download what’s needed.
Done right, it should work. ENTE is an alternative to Google Photos, the whole point for them is to upload pictures as frequently as possible.
The app is still at the mercy of any changes from Apple’s side, but that looks like a promising, Omni is another example that it seems doable.
Windowed = a program open in iPadOS, but not currently the one in focus / being displayed ?
Does the depth of window matter ?
If Obsidian is behind 3 other windows … then it won’t sync ?
Has this been confirmed to work with iPadOS 26 and NOT iOS 26 ?
Windowed means you’re using iPadOS’s “Windowed Apps” or “Stage Manager” mode and the app isn’t in full screen mode. IOS doesn’t have these modes. I don’t know if the depth matters but I would guess not. There may be a limit to how many windows can be open (perhaps dependent on how much RAM the device has), but if so it’s more windows than I’m likely to have open.
1 Like
I think this pretty fundamental core functionality for syncing, that most people (including myself) expected. I understand it’s not trivial given the constraints, but that doesn’t mean it’s impossible to improve the situation. I doubt that anyone pays for sync without expecting to use it on multiple machines. Not familiar with Apple’s APIs, but there can’t be some native part of the app running in a separate thread that could continue to run for syncing? Most syncs are short. And if one is too long and gets killed by the OS, then it could just be rolled back or not committed on the server or something? Just saying, there have to be options here.