Issues with If, Else, and End Condition Actions in If Condition Overhaul

Bugs or Unexpected Behavior
1

Bug 1 - Description

In the latest release, via the if-then condition overhaul:

  • An If condition action, seems to now require an explicit matching End condition Action - per each if condition

Prior to the overhaul, (first screenshot is Version: 6.726 (2026081403):

  • an if condition action did not require an explicit matching ending if condition action
  • The entire if, else, end action chain could contain a simple end condition.
    • Like in the first screenshot.

Bug 1 - Screenshots

Below are two screenshots. Both show the same trigger and action list.

The first screenshot is the trigger and action list in the aforementioned BetterTouchTool version

  • Version: 6.726 (2026081403).

The second screenshot is the same trigger and action list in the latest BetterTouchTool version.

  • Version: 6.769

In Version BTT Version: 6.726

If-Then--Version - 6.726 2026081403
If-Then--Version - 6.726 20260814031920×1821 317 KB

In BTT Version: 6.769

If-Then--Latest
If-Then--Latest1920×1805 342 KB

Bug 2 - Description

Existing "if actions," "else actions," and "end actions" seem to be removed from triggers when updating to the latest BetterTouchTool version.

The screenshots above were produced in the following way:

The trigger name is the same in both screenshots, and the actions are also the same. The first screenshot shows the original version with the old functionality of the if, else, and end if conditions.

The second screenshot shows the same trigger action list as the first, in the in the latest version of the app

I recreated the actions in the new app because, after the update, if, else, and end actions were gone.

At the same time, something odd happened with the presets.

  • If you look at the trigger preset color, it's different in the second screenshot
  • If you look at the top right-hand corner of both screenshots, you’ll notice that the same preset, called RSDefault, is set as the default / master
    • That preset is labeled green, not purple. (As is shown in the screenshot)
    • This means the second screenshot, which is the latest version of the app, is showing a different color for the same preset.

I'm explaining this because it may be something I did wrong, but it may also indicate an issue.

SHOT
SHOT1128×800 101 KB

Device information:

  • Type of Mac: MBP, Apple M1 Max, 2021
  • macOS version: 26.6.1 (25G76)
  • BetterTouchTool version: Version: 6.726 (2026081403)
2

could you try hovering the purple indicator at the trigger? it should show which preset it is assigned to.

The end if thing was actually a bug in the old version, but I still should not break the behavior. I‘ll add a fallback to support the old behavior as well - but with the same undefined / faulty behaviors that could occur there in that case

3

6.771+ fully supports the old single-End-If / no-End-If structures again - they behave exactly as in 6.726, quirks included - and the editor now shows a neutral "no End If, runs to end of list" hint instead of a warning for them.

For properly closed blocks the new, well-defined bracket matching applies. A quick example of why the old behavior was problematic:

If (app is Firefox)
If (dark mode is on)
→ action 1
Else
→ action 2
End If

Here the inner If has no End If of its own - the single End If at the bottom actually closes the inner block, leaving the outer one open. The old version paired branches by simply jumping to the first Else it found, ignoring nesting. So when Firefox was NOT frontmost - where you'd expect nothing to happen at all - BTT jumped into that Else and ran action 2 anyway. Whether an action ran could depend on bracket accidents like this rather than on the conditions you wrote, and with deeper nesting the results got even harder to predict (a second Else could shadow the first, some branches could never run, etc.).

That's why the overhaul introduced strict matching: every If pairs with its own Else/End If, and nesting behaves like in a normal programming language. Old presets with unbalanced brackets keep the legacy behavior 1:1 so nothing breaks, but for new setups I'd recommend closing each If explicitly - the editor's indentation now shows you exactly how the blocks pair up.

For your other issue I don't think this is caused by the new version. It sounds like some preset mixup.