As I mentioned on Discord, my impression from coverage of the new background processing feature is that Sync isn’t the kind of use case it is intended for (tho I’d love to be wrong about that). I believe it’s for handling explicit, bounded actions the user has taken (like rendering a video), and not things the app does on its own.
In fact, I just followed your link, and the first paragraph’s second sentence is, “Submission needs to occur as a result of a person’s action, such as tapping a button.”
The more detailed document linked from the one you linked (Performing long-running tasks on iOS and iPadOS | Apple Developer Documentation) gives these examples:
- Exporting video in a film-editing app, or audio in a digital audio workstation (DAW)
- Creating thumbnails for a new batch of photo uploads
- Applying visual filters (HDR, etc) or compressing images for social media posts
It also sounds like it expects to be able to produce a progress bar, which is something Sync doesn’t provide (feature request: Sync: Progress bar or other progress update).
When the system runs a continuous background task and a person backgrounds the app, the system keeps them informed of the task’s progress through a system interface. … Your app regularly reports progress of the task, which enables the system to make informed suggestions through the interface about possibly stuck tasks that a person can cancel.
The “Report progress” section later emphasizes, “It’s important to display accurate progress” and provides example code that seems to reinforce the idea of “progress” being something like a percentage of a known amount.
So it sounds to me like if Obsidian implemented “percent-of” progress reporting for Sync and a command to trigger a sync, manually triggered syncs could run in the background. That might be nice to have, but doesn’t satisfy the common desire to not have to think about Sync.