StackWM app iconStackWM
Compatibility

StackWM Compatibility

StackWM relies on macOS Accessibility APIs to find, move, and restore windows. Some apps expose incomplete window data, create extra helper windows, or behave differently enough that a dedicated workaround is useful. This page is a curated guide to known patterns, not a promise that every app will behave identically on every release.

Read setup docsSee pricing

Boundary

A listed issue does not automatically mean StackWM is broken. In many cases the limiting factor is how the target app exposes windows to macOS.

Boundary

Known behavior can change when macOS or the target app updates. Treat this page as reviewed guidance, not a permanent guarantee.

Boundary

Compatibility mode and workarounds can improve behavior, but they cannot override limits in the target app's own window architecture.

Known app patterns

This list focuses on patterns that are already documented in StackWM's docs or blog. It is curated, not exhaustive.

Telegram

high

messaging

Symptom

Windows may fail to return to the expected zone or may not respond cleanly during scene restore.

Likely cause

Telegram uses a non-standard window architecture that exposes incomplete data through macOS Accessibility APIs.

Workaround

Add Telegram to the compatibility list and expect a fallback strategy based on process and position tracking instead of ideal Accessibility metadata.

Notes

This is one of the clearest examples of an app whose internal architecture can limit any macOS window manager.

Arc Browser

high

browser

Symptom

Special UI surfaces such as auxiliary or floating windows may produce confusing results in switchers or restores.

Likely cause

Arc builds on Chromium patterns and also ships Arc-specific UI elements that are not always exposed as clean user-facing windows.

Workaround

Treat Arc as a browser family with extra helper surfaces, and prefer compatibility guidance plus conservative restore expectations.

Notes

The issue is less about a single bug and more about how the browser family creates extra window-like surfaces.

Brave Browser

medium

browser

Symptom

Auxiliary or helper windows can appear where only one browser window was expected, especially in overview-style UI.

Likely cause

Chromium-based browsers often create internal or auxiliary windows that macOS reports as real windows.

Workaround

Use compatibility guidance for Chromium-based browsers and expect some extra filtering logic around helper windows.

Notes

This family-level issue is shared with other Chromium-derived browsers and is not unique to StackWM.

Obsidian

medium

notes

Symptom

Window detection can become inconsistent in some workspaces or during scene restoration.

Likely cause

Cross-platform windowing layers do not always map cleanly onto the Accessibility metadata that macOS window managers expect.

Workaround

Test Obsidian with compatibility mode enabled and keep expectations conservative for aggressive scene switching.

Notes

Behavior can vary with app version and workspace complexity.

Chromium auxiliary windows

medium

window-family pattern

Symptom

Picture-in-picture, extension panels, previews, or helper surfaces may show up as extra windows in switchers or overviews.

Likely cause

Chromium creates multiple legitimate window surfaces that macOS cannot always distinguish from the one the user actually cares about.

Workaround

Prefer filtering and conservative interpretation of browser windows, and do not assume every reported window is user-facing.

Notes

This affects more than one browser and is a broader macOS window-classification problem.

Electron and Qt apps

medium

app-family pattern

Symptom

Some windows refuse to restore cleanly, report generic metadata, or behave unpredictably with drag-to-zone flows.

Likely cause

Cross-platform frameworks often prioritize their own rendering and window layers over native macOS AppKit conventions.

Workaround

When available, add the app to compatibility mode and treat it as a special-case app rather than a fully cooperative native macOS window.

Notes

This pattern explains why several unrelated apps can fail in similar ways.

Practical workarounds

  • Add the app to StackWM's compatibility list when standard Accessibility detection is unreliable.
  • Keep especially stubborn apps in a persistent zone rather than expecting frequent scene movement.
  • Re-check the latest version of the app after updates, because compatibility behavior can improve or regress over time.
  • Use app-level switching as a fallback for apps whose windows remain partially opaque to Accessibility APIs.

Read next

StackWM vs Rectangle

Choose StackWM if you want named zones, per-zone stacks, and repeatable scene restore on wide screens. Choose Rectangle if your workflow mostly stops at fast snapping and resize shortcuts. If you are considering Rectangle Pro, the gap is less about raw feature count and more about whether you want a dedicated workspace model.

StackWM vs Magnet

Choose StackWM if you need your display to behave like a reusable work surface with zones, stacks, and scenes. Choose Magnet if you want a straightforward snap tool and prefer manual arrangement over adopting a richer workspace model.

StackWM vs yabai

Choose StackWM if you want a lower-friction, desk-like workflow built around zones, stacks, and scenes. Choose yabai if you want a deeply configurable tiling window manager and accept a steeper setup and configuration curve.

StackWM vs Raycast Window Management

Choose StackWM if your main problem is recurring window context on wide screens. Choose Raycast if you primarily want a broader launcher that also happens to include window commands and lightweight layouts.

FAQ

Does a compatibility note mean StackWM is the only tool affected?

No. Many of these issues come from macOS Accessibility limits or the target app's own window architecture, so other macOS window managers often hit similar boundaries.

Will compatibility mode fix every app completely?

No. It can improve behavior by switching to a different handling strategy, but it cannot force an app to expose window information it never provides.

Why do Chromium browsers sometimes show extra windows?

Because Chromium-based apps create helper and auxiliary surfaces that look like real windows to macOS, even when they are not the window the user meant to manage.