I did not build Streifen because I wanted a window-manager side project. I built it because my desktop kept renegotiating itself all day.
That gets old fast.
I work on an ultrawide. Not because it looks cool, but because my day is genuinely wide: browser, IDE, terminal, notes, chat, mail, maybe one more browser, maybe a PDF, maybe some scratchpad window I need for ten minutes and then again two hours later.
That kind of work exposes every lie in a layout model.
Where the frustration started
Before Streifen I used AeroSpace.
That is a classic tiling window manager. Open a new window and the available space gets re-divided automatically. In theory that sounds clean. In practice it kept creating exactly the kind of instability I do not want while working.
A window opens. Everything resizes. One pane becomes too small. Another becomes too large. You fix it. Then the next window arrives and the whole negotiation starts again.
That can be fine when your work really behaves like a tree. Mine does not.
On an ultrawide, with several parallel workflows, I do not want the whole layout to re-argue itself every time one more window appears.
The idea that unlocked it
Then I ran into the PaperWM idea.
The important shift was not “another tiler.” The important shift was: stop thinking in trees, start thinking in strips.
Windows next to each other. One current focus. Neighbors still visible. Left and right remain real directions instead of abstract branches in some layout graph.
That clicked immediately.
I took that core idea, rebuilt it for macOS, and pushed it toward the model I actually wanted:
- one horizontal strip per workspace
- 9 workspaces
- stable movement through a strip instead of constant relayout drama
- explicit sizing logic instead of accidental geometry
That became Streifen.
How Streifen actually works
The visible model is simple.
Each workspace owns one horizontal strip of windows. You move through that strip with the keyboard. Windows live somewhere physical in that strip, so orientation stays intact instead of dissolving into “where did that pane go?”
The sizing logic is where it got interesting.
I did not want hardcoded pixel widths. Those age badly across screens. I also did not want equal-width nonsense, because a terminal and a browser do not deserve the same amount of space.
So Streifen uses a slice grid.
The screen gets a fixed number of slices depending on its class:
- laptop:
4 - desktop:
6 - ultrawide:
8
Each window takes an integer number of slices. That makes sizing predictable. It also means the same app can fit different screens without becoming random.
On top of that, apps get defaults.
- Browser: large
- IDE: large or extra large
- Terminal: compact
- Communication tools: medium
- Calculator: tiny, because obviously
That part sounds boring until you live with it. Then you realize how much friction came from making the same sizing decision 50 times a day.
The part that made it real
This is where these projects stop being a nice idea and start becoming software.
The first version is always the easy one. The second version begins when reality shows up with edge cases.
Browser popups and autocomplete panels suddenly look like real windows. JetBrains tools do weird things with resizing. Manual resizes need to snap back into the grid instead of drifting into chaos. Off-screen workspace windows must stay alive without confusing the tracker. State needs to survive more than the happy path.
That is where most of the actual work went.
A few examples from the build history:
- browser popup tracking had to be filtered so workspace switching would not get hijacked by autocomplete garbage
- JetBrains resize handling needed special treatment because the naive version lied about what was resizable
- state save moved to “every structural change” because anything less is how recovery becomes fiction
- manual resizing now snaps back to the slice grid instead of creating a second sizing system by accident
- four-finger trackpad pan was added because strip navigation should feel native, not only keyboard-correct
That is the difference between “cool concept” and “I can actually use this all day.”
Why the strip model feels better
The biggest win is not aesthetics. It is cognitive stability.
A new window does not have the right to renegotiate your entire screen. It should enter a system that already has rules.
That is what Streifen gives me:
- stable spatial context
- predictable sizing
- fast workspace switching
- less layout churn
- fewer tiny corrective actions all day
It is not magic. It is just a better fit for the work.
Built the hard way on purpose
Streifen is a native Swift app using the macOS Accessibility API.
No Electron shell. No private frameworks. No SIP circus.
That constraint matters. If I am going to trust a window manager with the entire shape of my working day, I want it to behave like a proper macOS citizen, not like a workaround with branding.
Why I like building tools like this
This is the broader reason I enjoy these projects.
Sometimes a category exists, but the working model underneath it is still wrong for you. At that point the pragmatic move is not endless tool-shopping. It is building the version whose assumptions actually match your life.
That is what Streifen is for me.
It is in developer preview right now. If this sounds like your kind of problem, take a look at streifen.eu and the GitHub repo.
A proper app release is coming.
And yes, there is already an early Windows beta. If you are brave enough to try it, let me know.