Pocket Screen - Keep any Mac window visible in a floating mini screen

Pocket Screen turns the frontmost window on your Mac into a compact, always-on-top PiP-style view. Keep documents, chats, videos, or reference material visible while you work in another app—without constantly switching windows. Processing stays on your Mac.

Add a comment

Replies

Best

How do you handle window resizing and aspect ratio changes when converting a full window to the mini PiP view?

 Thanks, Aymen!

The floating window can be resized freely, while the source content keeps its original aspect ratio and scales to fit rather than stretching.

If the source window itself changes size or aspect ratio, Pocket Screen updates the capture and reframes it automatically.

Very useful - however I can't figure out where to download it! Please can you help me?

 Thanks, Andrea!

You can download Pocket Screen directly from the Mac App Store here:

Sorry the download link wasn’t clear!

The single-display framing is the part that got me — I make music and my DAW eats the entire screen, so I'm constantly tabbing back to a YouTube tutorial or a lyrics doc and losing my place. Does the floating window survive over a fullscreen app, or does macOS shove it behind? Also nice call making Option+Cmd+P pin the frontmost window instead of asking me to pick from a list.

 Thanks, Ziang!

The floating window is designed to stay above full-screen apps. One limitation is macOS Spaces: if the pinned source window is on a different inactive Space, Pocket Screen temporarily hides and automatically resumes when that source Space becomes active again.

I’ll continue refining this behavior to make the experience as seamless and practical as possible.

The occlusion question a couple people raised is the real gotcha with this kind of tool. When we built window-mirroring on macOS, ScreenCaptureKit stopped handing us frames the second the source window went behind another one, so the mirror just froze until you brought it back to front. Did you find a way to keep frames flowing for an occluded or minimized source, or does the float only stay live while the source is at least partially on screen?

 Thanks, Dipankar!

That was one of the key cases I tested carefully. In my testing, a source window can be fully covered by another app and the floating view continues updating, including browser video playback.

Minimized windows are a little different: depending on macOS and the source app, new frames may temporarily stop. Pocket Screen keeps the window association and resumes automatically when it is restored, so it does not need to be pinned again.

I’d like to keep improving Pocket Screen based on feedback like this and make it more practical and reliable for everyday use.

this is one of those tools where the use case clicks immediately, i'm constantly alt-tabbing to check a doc while writing in another app. question on multi-monitor setups: does the floating window stay pinned to one display, or can you drag it across screens and have it remember where you left it next time you launch the app

 Thanks, Gal!

In the current version, the floating window can be dragged across displays like a normal macOS window, and Pocket Screen saves its last position. With the same monitor arrangement, it should generally reopen where you left it.

However, the current release wasn’t specifically designed for changes such as disconnecting or rearranging displays, so I can’t guarantee reliable restoration in every multi-monitor setup yet. I’m currently adding more display-aware position restoration and recovery for the next update, which I’m planning to submit to the App Store early next week.

That covered-versus-minimized split lines up with the ScreenCaptureKit internals: per-window capture keeps handing you frames for an occluded window because it samples that window's own backing store, but a minimized window loses its backing store so there's nothing to read until it's restored. Our freeze came from grabbing the whole display and cropping instead of capturing the SCWindow directly, which is why ours died on occlusion. Sounds like you took the cleaner path from the start.

 Thanks, Dipankar — that explanation matches what I observed during testing.

Pocket Screen’s primary capture path works directly with the selected window, which is why covered windows generally continue updating, while minimized windows need to be handled differently.

Your comparison with full-display capture and cropping is really helpful context. I appreciate you sharing the technical details.

Makes sense. The one detail that helped our users on the minimized case: instead of holding the last frame quietly, we dimmed it and dropped a tiny 'source minimized' badge, so a stale frame never got read as a live one. Since you keep the window association and resume on restore, do you surface that paused state visually or just hold the frame? Really enjoyed how carefully you tested this.

 Thanks, Dipankar — that’s a thoughtful UX detail.

At the moment, Pocket Screen doesn’t show a dedicated “source minimized” badge. The behavior can vary by source app: in some cases ScreenCaptureKit continues delivering frames while the window is minimized, while in others the content may pause and recover after the window is restored.

Your point about preventing a stale frame from being mistaken for a live one is very valid. Dimming the preview and showing a clear paused state would make that behavior much easier to understand, so I’ll keep this in mind for a future update. I really appreciate you sharing how you handled it.

That app-by-app variance is what made a reliable paused signal hard for us too. What ended up working was ignoring per-app behavior and watching the frame's presentation timestamp: if the PTS stopped advancing for roughly a second we treated it as paused, since ScreenCaptureKit never fires an explicit stream-idle event. Saved us from special-casing each source. Good luck with the App Store push next week.

So, if I understand correctly, this is mainly for beginners? On a Mac, I can switch between windows almost instantly using keyboard shortcuts...