NotchPrompter hides your script from the screen recorder, not just from the desktop

The feature that separates it from a text editor window

Most people who need text on screen while recording open a notes app and resize it. NotchPrompter is built around that job and adds one capability that no ordinary window has: the feature list states that it is not visible on screen recording apps.

That is a different product decision. A floating always-on-top window that sits above the application you are demonstrating is already unusual, because a normal macOS window either floats above everything or gets lost behind whatever you switch to. Making that window invisible to a recording tool, so you can read a script without the script appearing in the video, is the specific trick this app is built around.

The rest of the feature list is deliberately short: always on top, voice activation, a minimalist design, quick options, customizable speed, size and font style, multi-monitor support, multi-language support and a custom position. Minimalist design and quick options sit next to each other in that list, which suggests the author is aiming at a script you can start scrolling within seconds of opening the app rather than at a configurable studio tool.

The repository description frames the audience as people making quick videos and people who want important text visible while they work. Those are two different use cases served by one window.

The obvious alternative is a general purpose window, and the difference in approach is worth naming. A text editor or a terminal placed on top of your screen has to sit in the same window stack as everything else, so it either competes with the application you are showing or hides behind it, and it will be captured by the recording tool along with everything else. NotchPrompter takes a different approach: it owns its own always-on-top presentation layer and excludes itself from capture, so the script and the recording are separate surfaces. That is a small design decision with a large effect on the workflow, and it is the reason a dedicated app exists at all.

Placement around the notch, and multi-monitor behaviour

The application is named for the notch, and the repository topics list apple, macbook, macos, notch and prompter. That tells you the design origin, though the README does not describe a specific behaviour tied to the notch, so it is safer to treat the name as a design lineage than as a documented feature.

What is documented is placement. The feature list includes custom position and multi-monitor support. That combination addresses a real problem with always-on-top windows on a modern desk: a MacBook with a notch is not the only screen, and a bar that belongs over the built-in display can end up on the external one, or floating over the wrong monitor when you unplug.

The control surface implied by the feature list is quick options for position, plus customizable speed, size and font style. So the intended workflow is to open the app, nudge the window where you want it, set the scroll rate and the text size, and start. Adjusting size and font style separately matters on a 4K external display, where text scaled for the laptop panel will look wrong.

The README does not say whether the position is remembered between launches, whether positions can be saved per display, or how the window behaves when a display is disconnected. If your recording setup uses two screens, those are the details to verify yourself.

Voice activation for starting the scroll

Voice activation appears in the feature list without any further explanation, and the README does not expand on how it works. That is a documentation gap rather than a small detail, because voice control on macOS is implemented through system level dictation and accessibility permissions, and the setup a user must perform is not described anywhere in the repository pages we have.

Two readings are possible and the honest one is that the README does not say which is intended. It could mean the scroll starts on a spoken keyword, or it could mean the app follows the system dictation engine. Either way, a permission prompt on first launch is likely, and the failure mode for a user who does not grant it is that one control silently does nothing.

Everything else in the feature list is a visual or timing control, and voice activation sits oddly beside them because it is the only feature that depends on something outside the app. If you plan to use it, test it first on the machine you will record on rather than assuming it is on by default.

The honest framing for an evaluator: this is a documented feature with an undocumented setup, and that is a risk worth a few minutes of trial.

Distribution is through the Mac App Store, so there is no build to run

This project is not distributed as source builds or binaries you download from GitHub. The README carries a Download on the Mac App Store badge linking to the app listing, and the homepage is notchprompter.com. That is the whole installation story, and it is worth being clear about it: there is no build command, no installer script and no configuration file to edit before first run.

That choice has consequences in both directions. You get automatic updates through the store and a familiar install path on macOS, and you do not get the ability to run an unreleased build, to modify the app, or to inspect what it does with the microphone and screen recording permissions it needs.

The repository is still the source of truth, and the top level shows a conventional application layout. There is a notch-prompter/ directory holding the app code, notch-prompterTests/ and notch-prompterUITests/ for the test targets, a docs/ folder, a website/ folder that backs the homepage, and a .run/ directory that holds IDE run configurations. The primary language of the repository is listed as HTML, which is worth noting given that the project is a native macOS application.

So the app code lives in notch-prompter/ with its test targets beside it, and the public repository also carries the site and the docs. Reading that layout is the fastest way to understand what a change request would actually involve.

Translations are machine made and open for correction

Multi-language support is in the feature list, and the README explains how it works: translations are made via DeepL, so they might be incorrect in some places, and the project invites better suggestions through a SimpleLocale link.

The repository supports that story. Localizable.xcstrings is the Apple string catalogue for the app, simplelocalize.yml is the SimpleLocale configuration, and sync-translations.sh is the script that pulls translations between the catalogue and the translation service. Together they describe a machine translation pipeline with a human correction channel, rather than hand written locale files maintained in the repository.

That model has an obvious upside and an obvious cost. New locales appear quickly without a translator on staff, and a mistranslated string is a wrong word in a menu rather than a broken build. It also means the translation service is in the loop for your checkout, which matters if you fork the project and want to keep the sync working.

The practical point for an adopter: the interface is localised, but you should not assume the wording matches the English precisely, since the source strings themselves are translated by a machine first.

A custom licence that GitHub could not classify

The repository is not licensed under a standard open source licence. The licence field for this project is recorded as other, a custom licence that GitHub cannot classify, and the terms live in the LICENSE file at the top level.

That single fact changes how you should evaluate the project. With MIT, Apache-2.0 or similar terms, redistribution and modification are straightforward and you can reason about them without reading anything. With a custom licence, the only way to know whether you may modify the app, redistribute it, or use it commercially is to read the LICENSE file yourself. This is not legal advice, it is a practical warning about review effort.

It also interacts with the distribution model. Because the binary comes from the Mac App Store rather than from a GitHub release, most people will never need the licence at all, they will install the app and use it. The licence question only becomes relevant if you plan to fork the code, build your own binary, or ship the app to other users, and those are the cases where you need the actual text.

For a video tool you install for yourself, this is a low risk item. For anything else, read the file before you build a plan around it.

Release 2.7.0 and a repository still taking commits

On maintenance, the repository is not archived and the last push was on 2026-10-07. The recent releases are 2.7.0 on 2026-10-07, 2.6.2 on 2026-07-29 and 2.6.0 on 2026-05-03. The newest tag and the last push share a date, which means the release and the code are in step.

The version numbers are in the 2.x range and the project has a homepage, a Mac App Store listing and a website directory, so the surrounding infrastructure is in place for a product rather than a script.

What is missing from the public pages is the same thing that is missing from every other part of this repository: an installation guide, a usage walkthrough, a list of permissions the app requests, and a note about which macOS versions are supported. The README is a feature list and a download button. Nothing in it describes the settings behind the quick options, the behaviour of the window during a screen share that uses a different capture method, or the keyboard shortcuts.

That thinness is the honest characterisation of the documentation. The app looks small and focused, which is a virtue for a tool you open once a week and a risk if you are trying to configure it precisely.

Editorial conclusion

Adopt NotchPrompter if you record videos on a Mac and need a script that scrolls in front of your other windows without appearing in the capture, or you want a reference note parked above your work. Do not adopt it if you need a teleprompter on Windows or Linux, or if you need to build on the code, because it ships through the Mac App Store and its licence is a custom one that GitHub cannot classify. Before you install it, read the LICENSE file, try the window placement on a multi-monitor setup, and check the voice activation on the macOS version you run, since the README does not describe its setup.

Frequently asked questions

Official sources

1. Issues
2. jpomykala/NotchPrompter on GitHub
3. Project website
4. README
5. Releases