Show HN: SpinWin – A macOS menu bar app to visually rotate or spin any window

https://github.com/alokdhir/spinwin
SpinWin is an open source menu bar app to visually rotate any individual window. You can rotate / spin as many as you want one by one.

I was scrolling reels when one came on where the content creator suggested "turning the phone upside down" for a portion. I was sitting at my mac, and decided to see if I could find something that did this. To my surprise, nothing exists, so I decided to build it.

Turns out macOS doesn't provide any public API to do anything like this, so I wound up using the Accessibility API to move the target window offscreen, where it keeps rendering. Then we capture it's contents with ScreenCaptureKit, and display that on a transparent, borderless overlay window which has a CALayer to rotate it.

It's written in Swift, open source, MIT license, and signed/notarized.

Have fun - would love to hear your comments.

Comments

gwynforthewynJul 26, 2026, 12:34 AM
This reminds me of when wobbly windows were the big thing in linux. It was good plain fun back then, it seems fun again with this.

Drawing apps do regularly allow for canvas rotation, so I’m sure this’ll turn out to be useful for some class of application that I’m not considering.

itomatoJul 26, 2026, 12:57 AM
Oh, like Sun's Project Looking Glass. https://www.youtube.com/watch?v=JXv8VlpoK_g
loumfJul 26, 2026, 12:56 AM
I think it’s apps that don’t implement the JPEG orientation tag correctly.
mortenjorckJul 26, 2026, 12:34 AM
I’ve been building a window manger for macOS that involves hiding windows offscreen, but I’ve found AccessibilityKit clamps position writes at the screen edge, so I’ve had to settle for allowing a 1px-wide sliver (plus shadow) in the corner. Is that what you’re doing too, or did you find an alternative?
dbm5Jul 26, 2026, 1:02 AM
Same issue — I never found a way around the clamp. I park the window's top-left at (maxX - 1, maxY - 1) of the union of all displays' CGDisplayBounds, i.e. just inside the bottom-right corner of the whole arrangement. The clamp is much looser going off the bottom/right than up/left — pushing to something like (-30000, -30000) gets snapped back near the top-left and leaves a full-height sliver, whereas bottom-right leaves just the corner pixel (plus its shadow, which I also haven't beaten).

Since the target is derived from the union, a display disconnect or resolution change shrinks the desktop and the parked window pops back into view. I listen for display-config changes and re-apply the position.

1bppJul 26, 2026, 6:12 PM
Did you write this or have Claude do it? You've never used an em dash in your comment history and this doesn't sound human. Are you trying to use it for translation?
mortenjorckJul 26, 2026, 3:18 AM
Thanks for the corroboration. Something that apparently might be possible is using the private framework for Spaces to offload windows to a "holding Space"; I haven't tried it because it felt just a little too hacky for something I'm ideally hoping to turn into a commercial product, but it might be worth investigating depending on your use case.
dbm5Jul 26, 2026, 3:18 PM
Not sure if it is worth it for your use case, but I was successful in creating a virtual display - second screen - and putting the window there. That did work. I was trying to get kb input and mouse clicks to work, but then realized that that was even more useless than spinning a window to begin with (lol) so backed out all that effort for this much simpler implementation.

EDIT: private APIs — CGVirtualDisplay / CGVirtualDisplayDescriptor / │ CGVirtualDisplayMode (the same ones BetterDisplay uses)

hollow-moeJul 26, 2026, 1:10 PM
wayfire does it since about 7 years ago no weird hack required : https://youtu.be/ZBLLC5fOy98
dbm5Jul 26, 2026, 2:56 PM
not on macos
metasimJul 26, 2026, 1:17 PM
Why?
lagrange77Jul 26, 2026, 1:02 AM
Very handy.
chrism238Jul 26, 2026, 4:56 AM
For what?
lagrange77Jul 26, 2026, 11:57 AM
Should be sarcasm, sorry.