How rules and native apps interact

Bouncer checks your rules first. Native app routing runs after them, and only when Prefer native apps is on. Three statements cover every case.

A rule that matches the link always wins

If a rule matches the link’s address, the link goes where that rule says. Native app routing does not run.

For example, you have a rule for any Figma link that opens in Chrome. You click a Figma file link. It opens in Chrome, even with Prefer native apps on and the Figma app installed.

This also holds for a rule whose target is an app. A rule that sends Figma links to the Figma app is a normal rule. See Route any link to any app.

A rule that only matches the sending app does not stop the native app

Some rules match the app the link came from, with no address pattern. Such a rule does not block native app routing. The native app still takes the link.

For example, you have a rule for links from Slack that opens them in Chrome. A friend posts a Zoom meeting link in Slack. You click it. The Zoom app opens the meeting, not Chrome. The rule matched only the sending app, so the native app won.

Any other link from Slack, such as a news article, still opens in Chrome.

A catch-all rule lets the native app win

A catch-all rule has no conditions at all. It matches every link. Bouncer treats it like no match for native app routing.

For example, your only rule is a catch-all that opens everything in Firefox. You click a Zoom meeting link. The Zoom app opens the meeting. A link that is not on the built-in list, such as a blog post, opens in Firefox.

Where this fits

The full order is: rules from the top down, then native app routing, then the fallback browser. For the rule order and what a catch-all rule is, see How rules work. For the apps and links on the built-in list, see Built-in app routes.