Screenize: an open source macOS recorder with automatic zoom, now paused

The project status is the first thing to read

Screenize describes itself as a free, open source alternative to the paid screen recording apps for macOS, with the pitch being that you record a demo and let the auto zoom do the rest. The application is written in Swift, the licence is Apache 2.0, and the author is Yein Sung.

But the readme opens with a status section dated May 22, 2026, and it is the part that should shape your decision. Development of Screenize is currently paused. The author explains why: he started it because there was no open source application of this kind with automatic editing, he wanted something useful for himself and other indie hackers, and since then newer open source projects such as Recordly have appeared and raised the quality bar for screen recording and editing tools. Because the original reason for continuing is no longer as strong, he does not plan to actively develop it for now. The project will remain open source, and if the alternatives move in a commercial only direction he may return to active development.

The repository is not archived, and the last push was on 2026-05-22, the same date as that status note. The most recent releases are v0.4.1 on 2026-03-22, v0.4.2 on 2026-03-25 and v0.4.3 on 2026-03-28.

So the software exists and works, but the person who wrote it has stepped back. The contributing section is equally direct: issues and pull requests are still welcome, but responses may be slow.

Two auto-zoom cameras and a timeline that shows its work

The core idea is that the recorder watches what you are doing and reframes the video for you, so you do not have to keyframe anything by hand. Screenize tracks your cursor, clicks and keystrokes in the background, and the auto-generated zoom and effects are already on the timeline when you open the editor.

There are two camera modes, and the distinction matters. One follows the cursor in real time using spring physics, which gives a continuous move toward whatever you are pointing at. The other plans zoom levels per activity, distinguishing typing, clicking, scrolling and dragging, so a run of typing does not trigger the same movement as a click on a control. The documentation says both modes are customizable down to the smallest detail.

The second thing that separates this from a black box is the editor. Every auto-generated keyframe is visible and adjustable on a multi-track timeline, so if a zoom landed in the wrong place you change it rather than re-record. The readme frames that as the difference between a timeline editor and a black box.

There are also click effects and keystroke overlays, with ripple animations on clicks and keyboard shortcut badges such as the command C and shift command Z combinations drawn on screen, so a viewer can see what you pressed rather than guessing.

Export formats, colour spaces and the rest of the polish list

The feature list covers the parts of a recorder that usually decide whether you can use the output at all.

Export is MP4, MOV with ProRes, or GIF, at up to 4K and up to 240 frames per second, with presets you can save for your workflow. The colour handling is explicit rather than implicit, with sRGB, Display P3, BT.709 and BT.2020 supported, which matters as soon as a recording is graded or handed to a team with a different display pipeline.

On the capture side you can record the whole screen or a single window, at 720p to 4K, with system audio plus microphone, and a variable frame rate option for smaller files.

The visual layer is the part the readme is most enthusiastic about: gradient backgrounds, rounded corners, shadows, custom cursors and motion blur on fast transitions. The claim is that the result looks like you spent hours on it.

Localisation is complete rather than partial. Six languages are listed, English, Korean, Chinese, Japanese, French and German, and the repository carries a .swiftlint.yml configuration, a Screenize.xcodeproj project, a ScreenizeTests directory and an appcast.xml file, which is the feed format used for application updates.

Four macOS permissions, and why each one is needed

The application asks for four permissions on first launch, and the readme explains what each is for, which is a reasonable thing for a recorder to be explicit about.

Screen Recording is for capturing your screen. Microphone is for recording audio. Input Monitoring is for tracking clicks and keystrokes. Accessibility is for detecting UI elements for the smart zoom.

The last two are the interesting ones, because they are the permissions that make the automatic behaviour possible and the permissions that macOS treats as sensitive. Input Monitoring is what lets the app know that you pressed a key, which is the input to the whole system, and Accessibility is what lets it recognise the control you clicked so the zoom can be aimed at it.

For anyone evaluating this, that is the trade to weigh. The automatic zoom is the reason to use the application, and the automatic zoom is exactly what requires the two permissions users are most reluctant to grant to a recording tool. A reviewer of your app will also see these permission requests, since macOS surfaces them at launch, and the unnotarised first launch warning described below comes before them.

Installing the app and getting past the macOS warning

There are two install routes, and the recommended one is a Homebrew cask.

brew install --cask thedavidweng/tap/screenize

The manual route is to grab the latest .dmg from the GitHub releases page and drag Screenize into Applications.

Either way, there is a first launch wrinkle that the readme calls out. Since Screenize is not notarized with Apple yet, macOS will show a warning. The workaround is to right-click the app, select Open and confirm, and you only need to do that once.

That is a real factor in a decision, and it is worth being clear about it. Gatekeeper's warning is a signal to an ordinary user that the application is not signed by a known developer, and asking a viewer of your demo to right-click through a warning is friction. For a developer recording internal documentation, it is a thirty second inconvenience. For a product demo that a customer will open, it is a decision you have to make consciously.

The day to day operation is straightforward once the app is running. You pick a screen or a window and hit record, you do your work while it tracks the cursor, clicks and keystrokes in the background, you open the editor where the generated zoom and effects are already on the timeline, you adjust anything that needs it, and you export. Keyboard shortcuts cover the same flow, with a global hotkey to toggle recording, plus shortcuts for a new recording, start and stop, pause and resume, export, opening a video, opening a project and undo and redo.

Where Screenize is the wrong tool

Four reasons, and the first one is decisive for most teams.

The project is paused. The author states that he does not plan to actively develop it for now, that responses to issues may be slow, and that he may return if the alternatives go commercial only. For a personal tool that is a perfectly reasonable arrangement. For anything you plan to depend on, a screen recorder with no maintainer is a liability, and the releases stop at 0.4.3 from March 2026.

The second is macOS only. It is a native Swift application with macOS specific permissions, so it is not an option for a team that records on Windows or Linux.

The third is the unnotarised distribution. The first launch warning is expected, and it is a worse look for a product demo than for an internal tutorial.

The fourth is that the automatic editing is a heuristic, not an understanding. The zoom follows the cursor and classifies activity, which means it will occasionally choose a frame you would not have chosen, and the response to that is to open the timeline and fix it. The project is honest that this is the intended workflow rather than a fully automatic result, but a team that wants zero editing will spend time in the timeline.

There is also a plain question of alternatives to ask. The author's own reason for pausing is that newer open source projects have appeared and raised the quality bar, so the comparison to make is against those, not against the paid applications Screenize was originally built as an alternative to.

Licence, layout and what a paused project means for a fork

The licence is the Apache License 2.0, with the licence file at the root of the repository. That is a permissive grant with an express patent clause, so you can use, modify and redistribute the code, including in a commercial product, as long as the notice is kept. This is not legal advice, and the fact that the application bundles native libraries and an asset pipeline means a company should still run its own review of the dependency licences before shipping anything derived from it.

The repository layout supports the idea of a fork being practical. There is a Screenize.xcodeproj project, the application source in a Screenize directory, a ScreenizeTests directory, an assets directory, a scripts directory, a tasks directory, a website directory and a private-docs directory, along with AGENTS.md, CLAUDE.md and a Contributing guide. The documentation says AI-assisted contributions such as Claude Code or Copilot are welcome as long as they are well tested, and points at CLAUDE.md for agent guidance, which tells you how a contributor is expected to work with the code.

A paused project with a permissive licence is a common starting point for exactly the kind of work the author described, a feature you need that nobody is going to build. The realistic expectation is that you maintain it yourself, and the honest summary of the current state is that Screenize is a capable and complete recording app at version 0.4.3 that nobody is presently working on.

Editorial conclusion

Screenize is worth trying if you record macOS demos regularly and want the automatic zoom behaviour with a timeline you can still adjust, and it is a reasonable starting point for a fork given that the licence is permissive and the code is a native Swift application. It is the wrong choice for a product that needs a maintained screen recorder, because development has been paused since 2026-05-22 and the author says responses to issues may be slow, and it is the wrong choice off macOS. Before adopting it, check the current release for your macOS version, expect to work around the unnotarised first launch, and read the project status note in the readme before you plan any dependency on it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. syi0808/screenize on GitHub