Why Some Apps Don't Play Nice With StackWM (And How to Fix It)

You set up the perfect scene. You've got Telegram on the left, your code editor on the right, and everything aligned perfectly. Then you switch to a different scene and back — and Telegram doesn't return to its zone. What happened?

Welcome to the world of macOS Accessibility API limitations. It's not a bug in StackWM. It's a limitation in how these apps talk to macOS.

The Root Cause: Accessibility APIs

StackWM relies on macOS's Accessibility framework to manage windows. When you create a zone, StackWM asks macOS, "Which windows belong to which app?" and macOS tells it what's open.

The problem? Not all apps cooperate.

Some applications — particularly Telegram, Brave, Obsidian, Arc, and a few others — don't properly expose their windows through the standard Accessibility APIs. From StackWM's perspective, these apps either:

Report no windows at all
Report windows with incomplete or generic information
Hide their actual app window behind helper processes

This means when you switch scenes, StackWM can't find those windows to move them back to their assigned zones.

Why Do Some Apps Do This?

It's usually one of three reasons:

1. Non-standard window architecture

Apps like Telegram use custom rendering frameworks (often Electron or Qt-based) instead of native macOS AppKit windows. This gives them cross-platform flexibility but breaks compatibility with macOS window management APIs.

2. Security and sandboxing decisions

Some developers deliberately limit what their app exposes through Accessibility APIs as a security measure. It's a trade-off: better isolation vs. worse integration with system tools.

3. Legacy code or architectural debt

Some apps haven't updated their window handling code to meet modern macOS standards. They work fine day-to-day, but don't play nicely with external window managers.

The Common Culprits

Here are apps known to have Accessibility API issues with StackWM:

App	Issue	Severity
Telegram	Windows not properly exposed to Accessibility APIs	High
Brave Browser	Auxiliary windows reported incorrectly	Medium
Obsidian	Window detection issues in certain workspaces	Medium
Arc	Arc-specific UI elements not accessible	High
cmux	Terminal multiplexer with limited window reporting	High
Google Antigravity	Proprietary window handling	High

(This list grows or shrinks as app developers update their code. Check the StackWM blog regularly for updates.)

The Solution: The App Compatibility

Here's the good news: StackWM has a built-in workaround called the App Compatibility.

When you add an incompatible app to this list, StackWM switches to a fallback strategy:

Instead of relying on Accessibility APIs, it uses visual position tracking and process matching
When you switch scenes, StackWM remembers where these windows were positioned and attempts to restore them
It's not perfect (the app has to cooperate to some extent), but it restores 90% of functionality

How to Add Apps to the App Compatibility

Open StackWM Preferences → go to the Settings tab
Find "App Compatibility" section
Click the plus button to add an app
Select the app from the list of installed applications
That's it. The app now gets a red checkmark ✓ and StackWM will handle it specially

You'll know the app is added when you see the compatibility icon appear next to it in the list.

What the Red Checkmark Means

Once an app is in the App Compatibility:

StackWM stops trying to use standard Accessibility APIs for that app
Instead, it tracks window positions and remembers zones
When you switch scenes, it restores the app window to its previous zone if possible
You might see slight delays (a few hundred milliseconds) as StackWM locates and moves the window

Important caveat: Some apps (particularly those that run in a sandboxed environment or use non-standard windowing) still might not move properly even with this workaround. If that's the case, there's usually nothing we can do — it's a limitation of the app itself.

Workarounds if the App Compatibility Doesn't Help

If adding the app to the App Compatibility still doesn't solve the problem:

1. Use the app in a persistent single zone

Instead of trying to move it between zones, keep the app in one fixed zone and focus your workflows elsewhere.

2. Control it separately with Cmd+Tab

For app-level switching, use macOS's native Cmd+Tab instead of relying on StackWM's zone restoration. This works for any app, compatible or not.

3. Keep manual overrides ready

If the app doesn't return to the right place automatically, just drag it back. It's a workaround, but at least you get zone management for your well-behaved apps.

4. Reach out to the app's developers

If an app is critical to your workflow, consider filing a GitHub issue or contacting the developer asking them to improve their Accessibility API support. The more pressure developers get, the more they fix these issues.

What We're Doing About It

The StackWM team actively monitors:

Which apps have the most compatibility issues
Whether app updates improve or break compatibility
Workarounds that might help in edge cases

We also maintain an updated compatibility matrix that shows the known status of popular apps, updated with each StackWM release.

The Bigger Picture

This problem isn't unique to StackWM. Every window manager on macOS — including yabai, Magnet, and even Raycast — struggles with the same apps for the same reasons.

It's a fundamental limitation of how macOS exposes window information. Until Apple provides a more robust API (or app developers voluntarily improve their Accessibility API support), this will remain a challenge.

Quick Checklist

✅ Try adding the app to the App Compatibility first
✅ If it still doesn't work, check if a newer version of the app has better API support
✅ As a fallback, keep the app in a single zone and move on
✅ If it's critical, file an issue with the app's developer asking for better macOS API support

Last updated: March 3, 2026

Questions? Contact us or check out our full documentation.