ScreenArc: a screen recorder that zooms where you click

The zoom follows the mouse, so nobody has to keyframe

ScreenArc is a cross-platform screen recording and editing tool whose central idea is that the camera movement is derived from your own activity. The README says it automatically tracks your mouse movements and clicks and creates smooth cinematic animations that keep viewers focused on what matters, with no manual keyframing needed.

That single decision defines the product. A conventional tutorial workflow is to record flat, then open an editor and add pan-and-zoom moves by hand at every moment that matters. ScreenArc takes the position that the moments that matter are already signalled, because you clicked there. The cost of that assumption is that the framing is decided by input events rather than by editorial judgement, which is the trade-off to keep in mind when you evaluate it.

The intended users are stated plainly: developers, educators and content creators who want to produce tutorials, demos and presentations. The topics on the repository track the same ground, from tutorial-videos and cinematic-video through screen-recording and productivity.

The project is young and actively shaped. The repository is not archived, the last push was on 2026-07-22, and the release history shows v1.3.0 and v1.4.0 both published on 2026-04-26, followed by v1.4.1 on 2026-07-22.

Capture modes, webcam overlay and a visual timeline editor

The feature list in the README covers three areas. Capture is flexible: you can record your full screen, a specific window or a custom area, and the README says multi-monitor support is handled without extra setup. A webcam overlay lets you appear in the recording, which is the usual requirement for tutorial and course production.

Editing is visual, with a timeline for trimming clips and for adjusting frames, backgrounds, which can be colours, gradients or wallpapers, and shadows. There is a preset system, so a look you have tuned once can be saved and applied instantly to later projects to keep a channel visually consistent.

Aspect ratio handling is one click, with 16:9 named for YouTube, 9:16 for Shorts and TikTok, and 1:1 for Instagram. Export produces MP4 or GIF at resolutions up to 2K.

The 2K ceiling is worth noting if you produce work for large displays, and the GIF option is the one most tools skip. The preset system is the feature that matters most for anyone publishing regularly, because re-deriving the same framing and background settings for every video is exactly the repetitive work the tool set out to remove.

Electron and React on top of FFmpeg, with undo handled by Zundo

The tech stack section names the pieces. The core framework is Electron with Vite and TypeScript, and the frontend is React with TailwindCSS. State management is Zustand with Immer and Zundo, and Zundo is there for undo and redo. Backend and video processing are Node.js and FFmpeg.

The repository layout backs that up. There is an electron directory for the main process, a src directory for the renderer, a public directory, a resources directory, a build directory, a scripts directory and a binaries directory, plus an electron-builder.json5 file that configures the installers. The vitest.config.ts and tsconfig.json and tsconfig.node.json files show a typed project with tests configured.

The interesting dependency is the binaries directory. FFmpeg is not something the application downloads at runtime; the development guide tells contributors to fetch the appropriate FFmpeg executable from a separate screenarc-assets release and place it in the binaries/[os] directory. The same directory therefore serves two purposes, holding the encoder for development and, presumably, the one shipped inside the packaged app, which is why the release artifacts are so large.

Undo and redo in a video editor is a harder problem than in a form, and the choice of Zustand with Immer and Zundo says the author treated editor state as ordinary application state rather than as a separate document model.

On Linux the AppImage needs X11, and Wayland is not supported

The Linux instructions start with a prerequisite rather than a download, and the constraint is absolute: ScreenArc currently does not support Wayland, and the X11 display server is required.

The README gives you a way to check what you are running, by echoing the XDG session type in a terminal, and the guidance is that if the answer is wayland, you switch to X11 from the login screen. On current desktop distributions, that is often not a one-click decision, so this is a real blocker for anyone on a default Wayland session rather than a footnote.

The installation itself is three commands, starting with the AppImage download from the releases page.

   wget https://github.com/tamnguyenvan/screenarc/releases/latest/download/ScreenArc-*-linux-x64.AppImage

   chmod +x ScreenArc-*-linux-x64.AppImage

     ./ScreenArc-*-linux-x64.AppImage

The troubleshooting notes are practical rather than speculative. Permission errors mean the file is not executable, and for AppImage problems the README suggests running with the --no-sandbox flag. The download is an x64 build, so the Linux path documented here is for x64 machines.

Unsigned binaries mean a security prompt on Windows and macOS

The README is unusually candid about the installation friction on the other two platforms, and it starts with a security notice rather than a download link. As a new open-source project, ScreenArc has no code signing certificate yet, so the operating system will warn you.

On Windows, the guidance is to keep the download when the browser asks, and to use More info and then Run anyway on the SmartScreen prompt. On macOS the route is longer: attempt to open the app, close the warning dialog, open System Settings and then Privacy and Security, scroll to the Security section, click Open Anyway next to the ScreenArc warning, and confirm with Open.

The install steps themselves are conventional. On Windows you download the ScreenArc-*-Setup.exe file and run it. On macOS you pick a package by architecture, ScreenArc-*-arm64.dmg for Apple Silicon machines and ScreenArc-*-x64.dmg for Intel ones, open the disk image and drag the application to your Applications folder.

The absence of a certificate is a normal state for a young project rather than a red flag, and the README points at the fact that the code is fully open source for review. Still, for an application that asks for screen capture and microphone-adjacent permissions, an unsigned binary asks users to make a trust decision by hand, and that is a real adoption cost on managed machines where unsigned installers are blocked outright.

Building from source needs a C++ toolchain, Python 3.8 and a manual FFmpeg step

The development guide is the most concrete part of the README. On Windows you need the Build Tools for Visual Studio 2022 with the Desktop development with C++ workload, plus Python 3.8 on the PATH. On macOS you need the Xcode Command Line Tools and Python 3.8. On Linux you need an X11 session.

The clone and install steps are explicit, and they start by deleting the committed lock file.

    git clone https://github.com/tamnguyenvan/screenarc.git
    cd screenarc

    rm package-lock.json
    npm install

Removing package-lock.json before installing means the dependency tree is resolved fresh rather than replayed from the lock, which suits a project whose native and build-time dependencies vary by platform, at the cost of reproducibility.

The FFmpeg step is manual, and the README names the exact assets release and the directory layout, with a separate binary per operating system.

    # Linux
    wget https://github.com/tamnguyenvan/screenarc-assets/releases/download/v0.0.1/ffmpeg-linux-x64 -O binaries/linux/ffmpeg
    chmod +x binaries/linux/ffmpeg

The package.json scripts show how the release binaries are produced, and they make clear that electron-builder is the packaging layer, with one target per script.

    "dist:appimage": "tsc && npm run build && electron-builder build -l AppImage --publish never",
    "dist:deb": "tsc && npm run build && electron-builder build -l deb --publish never",
    "dist:rpm": "tsc && npm run build && electron-builder build -l rpm --publish never",

The build script itself runs the type checker before bundling.

    "build": "npm run clean && tsc && vite build",

The engines field pins Node to >=18 <=22, and the lint script runs ESLint over ts and tsx files with --max-warnings 0, so warnings fail the check.

GPL-3.0 and a licence question for anyone who ships a build

ScreenArc is released under the GPL-3.0, and the LICENSE file sits in the repository root alongside a CHANGELOG.md, CONTRIBUTING.md and CODE_OF_CONDUCT.md. The .releaserc.json file indicates that releases are produced by a release tool rather than by hand, which is consistent with the tagged versions in the history.

For an end user running the app, GPL-3.0 is simply the price of admission for open source. For anyone who plans to redistribute it, modify it, or embed parts of it in something else, the copyleft obligations are the part that needs attention, and the license text is where you find the detail rather than this review. A reasonable rule of thumb: running the app as a user is unaffected, while shipping a modified build of the application means working within the GPL terms for that build.

The version history is short and worth reading as a signal about the project's stage. v1.3.0 and v1.4.0 arrived on the same day, 2026-04-26, an hour apart, and v1.4.1 followed on 2026-07-22, the same date as the last push to the repository. Two releases on one day in April suggests the version line was being moved quickly, and the gap of nearly three months before v1.4.1 suggests it then settled. The README states no fixed release schedule, and the topic list on the repository includes tutorial-videos, which suggests the project is used for exactly the kind of screen walkthroughs it was built for.

Editorial conclusion

ScreenArc fits developers, educators and content creators who record long screen sessions and want the focus to follow the action without hand-editing every zoom, and it fits teams that already accept GPL-3.0 terms for distributed binaries. It does not fit Linux users on a Wayland session, since the README states X11 is required, and it does not fit anyone who needs a signed installer today, because the project says it has no code signing certificate yet. Before installing it, check your session type with echo $XDG_SESSION_TYPE, confirm FFmpeg is available as the project expects it in the binaries directory, and read the licence terms in the LICENSE file if you intend to redistribute a build.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. tamnguyenvan/screenarc on GitHub