PiP clones any macOS window into an always on top preview

A floating preview of anything already on screen

The core idea is simple to describe and surprisingly useful in practice. PiP is a macOS application that shows an always on top preview of a window, a camera feed or an active display, and lets you keep that preview floating while you work in something else. The feature list spells out the range: clone any visible window, clone multiple active displays, camera preview, HLS streaming, crop the preview, automatic and manual resize preserving the aspect ratio, transparency and opacity control through a slider in the right click menu, pinch to zoom, and native picture in picture support on cmd+p. Multiple previews from the same process are possible, with cmd+n to open one and cmd+w to close it. The target user is not a developer integrating a feature into an app but an individual who wants a small persistent panel on a Mac, for instance to keep a chat window or a build output visible while working in a full screen editor.

CoreGraphics capture, OpenGL or Metal rendering, and a private framework

The Code Info section is where the engineering reality sits. It is a Nibless Cocoa app, written in C, with an OpenGL or Metal renderer that supports HiDPI displays. Capture is CoreGraphics based, and the author notes alongside it that they are looking for an alternative, which is an honest signal that the current approach may not be the long term one. There are no third party dependencies, in the sense of no external libraries pulled in for the capture and rendering path. The important caveat is the next line: native picture in picture support uses a private framework. That means the cmd+p behaviour is not built on a documented API, and it is the reason the app cannot be described as a fully supported system integration. The repository layout matches that description, with a pip/ directory for the main app sources, an airplay/ directory and an airplay_sender/ directory, an Xcode project at pip.xcodeproj, a CMakeLists.txt, a package.sh for producing the distributable, a settings.py for configuration and a run.sh for the quick build and launch path.

Installing with a cask or building the app yourself

There are three documented routes. The manual route is a download from the latest release page. The Homebrew route is a cask:

brew install --cask amitv87-pip

The third route is building from source, and the README shows the full sequence with xcodebuild:

# checkout code
git clone https://github.com/amitv87/PiP.git
cd pip

# build using xcode
xcodebuild -alltargets
open build/Release/PiP.app

The same block also offers the shortcut for people who do not want to run the build steps by hand:

# or simply
./run.sh

Either way the artefact is a macOS application bundle, PiP.app, which you open from the build/Release directory. The build path assumes a machine with Xcode installed and the command line tools available, since xcodebuild is doing the compilation, and the presence of both an Xcode project and a CMakeLists.txt suggests the CMake side is a secondary path rather than the primary one. Whatever you build or install, the first thing to do on macOS 12 or later is turn off the built-in AirPlay receiver in system preferences, because the app's own receiver takes over that role.

The AirPlay receiver is borrowed from two other projects

The AirPlay side is the part of the project that is not original, and the README says so directly: the AirPlay backend comes from the FDH2/UxPlay project and the KqSMea8/AirplayServer project. What that means in practice is that PiP inherits a receiver implementation that was written for a different purpose and adapted here. It also inherits the limits of that code. The feature list caps the server at up to 10 parallel AirPlay sessions, and calls that a soft limit, which is the language of a constraint that can be pushed past. HLS streaming is supported as a source alongside window and camera capture, and the app can act as an AirPlay sender as well, though that direction is explicitly marked as unstable. So the sensible reading is that PiP is a reliable AirPlay receiver and an experimental sender. If your plan depends on pushing video from the Mac to another device with PiP, that is the part to test first.

Window management details that decide whether it is usable

The small features are what separate a preview tool people keep from one they try once. Cropping the preview lets you cut the captured region down to the part that matters, and automatic and manual resize preserving the aspect ratio means the panel does not stretch the source when you drag its corner. Pinch to zoom gives you magnification without opening the source window. Transparency and opacity control through a slider in the right click menu is what lets the panel sit over your work without hiding it, and multiple window preview from the same process with cmd+n and cmd+w means you can watch more than one thing at once, for example a build log and a chat. The overall interface is described as minimal and modern, which in practice usually means a small panel with a context menu rather than a window with chrome. One caveat for anyone pairing this with the AirPlay receiver: the receiver and the built-in macOS AirPlay receiver are alternatives, not companions, so you need to disable the system one first.

A private API dependency and an uneven release history

Two things belong in an honest assessment. The first is the private framework. Native picture in picture support on macOS through undocumented APIs can break with a system update at any time, and the author is candid about the state of the capture path too, noting the CoreGraphics based capturer is something they are looking to replace. That makes PiP a tool to enjoy today and re-verify after each macOS upgrade, rather than something to build a workflow on without a fallback. The second is the release pattern. The tag list shows v3.01 on 2026-01-21, v2.70 from 2024-03-18 and v2.60 from 2024-02-20, so the recent numbering moved from two digit to three digit versions while the intermediate years show no tags. The last push to the repository was on 2026-08-30 and it is not archived, so work is still landing. The licence is MIT, which permits use and redistribution as long as the copyright notice and licence text are kept, though any judgement about relying on a private API is a risk question rather than a legal one.

Editorial conclusion

PiP suits someone who wants a floating always on top preview of a window, a camera or a display while working in another app, and who wants that panel to double as an AirPlay receiver so a phone can stream into it. It is a poor fit for a team that needs a supported, non private API path or a stable AirPlay sender, since the native picture in picture support uses a private framework and the sender is described as unstable. Verify first that you can turn off the built-in AirPlay receiver in system preferences on macOS 12 and later, since the two otherwise compete for the same streaming role, and check that the release you download matches the macOS version you run.

Frequently asked questions

Official sources

1. amitv87/PiP on GitHub
2. Issues
3. License: MIT
4. README
5. Releases