Why do the AFO actions behave differently than most other apps' actions?

Actions for Obsidian is basically just a proxy that sits between Obsidian and Shortcuts, translating between Shortcuts and Obsidian, which adds a layer of complexity, compared to an application like Apple Notes exposing its own actions directly to Shortcuts.

When an app provides its own actions, the communication between it and Shortcuts is simple. Any workflow that uses such an action directly tells the action's parent application "do this, use these parameters, then report back". And the app will:

1. Use the parameters
2. Do the work internally (usually in the background)
3. Report back to the workflow.

Obsidian doesn't provide its own actions. Instead, AFO provides actions to Shortcuts. For security reasons in iOS no app can directly steer another application. (Which is honestly really good.) In our case, AfO can't just start rummaging around in Obsidian's code and make it do things, but it can use Obsidian's official API and ask it to do things. Now when a workflow tells the Actions for Obsidian app "do this, use these parameters, then report back", the following happens:

1. The AFO app as the action's parent transmits the work description and the parameters to Obsidian
2. Inside Obsidian, the AFO companion plugin Actions URI picks up the call and does the work requested
3. Once done, Actions URI transmits the result (success/ failure) back to AFO
4. Actions for Obsidian lets the Shortcuts workflow know about the result

In short, the action doesn't happen "internally" inside one single app. And at the time of this writing, due to iOS restrictions, Actions for Obsidian can not be in the background when it calls Obsidian. This is a system-wide restriction to prevent shenanigans by malicious apps happening behind your proverbial back. (Again, security-wise this is a seriously excellent idea!) And that very same rule applies to Obsidian, meaning that when a Shortcuts workflow tells AFO "do this, use these parameters, then report back" …

• AFO must be brought to the foreground to call Obsidian
• Obsidian must then be in the foreground to call back to AFO
• Due to the type of API that Obsidian provides, each API call will focus the receiver app

How does Actions for Obsidian communicate with Obsidian?

Obsidian's API is URL-based. Just like a Safari deals with URLs starting with https://, Obsidian handles URLs starting with obsidian://, and those URLs contain the information what to do.

So, the only way to communicate with the Obsidian API is telling iOS to open an obsidian:// URL. iOS will then launch Obsidian (or bring it to the foreground if it is already running). Obsidian then returns its answers to AFO the same way, because due Obsidian provides no other communications channel. It's impossible for an app like mine to move this work into the background. (And I've tried basically everything.)

You say it's in the foreground but why don't I see Actions for Obsidian during workflows?

As mentioned, AFO can only ever run in the foreground. That means that every time a AFO action is called, iOS will bring it to the fore. Since the app popping up again and again over the course of a workflow would be highly annoying, I've built it so it will hide its main window when it is called from a workflow; it'll make its window visible again after a few seconds. It basically works like this:

So you'll always end up in Actions for Obsidian if one of its actions is the last one in a workflow because AFO is already open and in the foreground, albeit blacked out, until it shows its screen again.

Now what?

During development I've tested out a number of possible ideas to make this process less jarring, and for the most part, I'm pretty happy with how well it works! But there is the possibility of apps explicitly allowing specific other apps to call them in the background, at least on paper.

This research sits firmly on my Todo list.