SpeedyNote annotates PDFs on a $50 tablet, and SAI2 layers on the side

The pitch is one feature: PDF annotation a stylus can keep up with

SpeedyNote frames itself against a specific gap rather than against note apps in general. The README puts three rows in a problem table: OneNote does not support PDF annotation, Xournal++ is slow on large PDFs, and GoodNotes or Notability cost more than ten dollars and require an iPad. The claimed answer on each row is fast PDF rendering, 360Hz stylus polling on a Celeron N4000 running at 1.1GHz, and a free open-source build that runs on a fifty dollar tablet.

That is a narrow, defensible target. The user is a student annotating lecture PDFs on a device bought for its screen size, not a company standardising a note system. The project states it is built for "students who need iPad-quality annotation on budget hardware", and the platform badge spans Windows, Linux, macOS, Android and iPadOS.

The claim you should discount by default is the frequency number. Stylus polling at 360Hz is stated as tested on one specific low-end Intel chip. Nobody has published the input pipeline, the event coalescing behaviour, or a latency figure in milliseconds, so treat 360Hz as a directional statement about input handling rather than a measurement you can rely on across devices.

Native C++ with MuPDF behind the page rendering

The reason the project can claim quick PDF opening is architectural. It is native C++ built on Qt 6, and the build prerequisites list MuPDF among the Linux dependencies. The README calls out the absence of Electron explicitly as the reason for the small memory footprint, which tells you the design intent: a note app that holds a large PDF open and processes pen input on the main thread without an embedded browser engine between the stylus and the canvas.

Drawing is vector based. Strokes are not stored as a bitmap of the page, so they stay sharp when you zoom. The ink tools are Pen, Marker and Highlighter with pressure sensitivity, and there is a stroke eraser rather than a pixel eraser, which means removing a mark removes the stroke object and not a rectangle of the page beneath it. Undo and redo cover that erasure.

For canvas work the edgeless mode uses lazy-loading tiles on an infinite whiteboard. Pages and the canvas share the same .snb document extension, so the two document modes live in one file format rather than in two incompatible ones.

SAI2-style layers on a page, not just strokes on a page

The feature that separates SpeedyNote from a plain PDF highlighter is multi-layer editing, described in the README as SAI2-style: you can add, delete, reorder and merge layers. For anyone who has annotated a technical document and then wanted to push the annotations underneath a later revision, that is the operation a flat annotation model cannot express.

Around the layers sit a few structural objects. Link objects point to a markdown note, a URL, or a specific position, which is how you get a clickable reference out of a page. PDF backgrounds can carry clickable internal links, and a PDF outline panel lets you jump to a section from the table of contents. A markdown note can be attached to a page or a position rather than living in a separate document.

Sharing uses a different extension. A document is .snb; a shareable cross-platform bundle is .snbx. That distinction matters if you plan to move notes between the desktop and the tablet build, because the two are not interchangeable by assumption and the README does not document the bundle format's internals.

On-device handwriting OCR, and where it does not run

Handwriting recognition is described as on-device, so recognized text is searchable and selectable inside your own notes rather than sent to a service. The README states support for Latin scripts plus Chinese, Japanese and Korean. For a student with a printed PDF and handwritten margin notes, searchable handwriting is what makes the annotated file usable a month later.

The platform qualifier is easy to skim past: OCR is listed as available on macOS and Linux. The feature list marks it "(macOS & Linux)" and does not extend that claim to Windows, Android or iPadOS. On those platforms the app still takes ink, but text search over handwriting is not promised. Whether that is a platform API limitation or simply not finished on those builds is not stated, and the README does not say.

Related to that, the accessibility picture is partial. There is palm rejection and two-finger pan with pinch to zoom for touch input, but no keyboard shortcut documentation and no screen reader support is mentioned anywhere.

Getting it onto each platform, including the awkward one

Desktop installs are binary downloads. The README points to GitHub Releases or the project website for the Windows .exe installer and the macOS .dmg disk image. On Arch Linux the package name is short:

yay -S speedynote

That pulls from the AUR helper, not from Flathub. Flathub is linked separately as a badge and carries the application id org.speedynote.SpeedyNote. Android is distributed as an .apk rather than through a store listing.

The minimum versions are stated plainly: Windows 7 SP1, macOS 12, Ubuntu 22.04 or Fedora 38 with Qt 6.4 and MuPDF, Android 9 at API 28, and iPadOS 16.0. Recommended targets are Windows 11, macOS 15 or later, Android 13 or later and iPadOS 17 or later. Hardware requirements are stated as any x86_64 or ARM64 CPU, with testing named on an Intel Core i5 470UM from 2010, a Celeron N4000, a Snapdragon 7c Gen 2, a Rockchip RK3399 and an Apple M4. ARM64 native builds are called out for Snapdragon laptops and Rockchip Chromebooks.

Building from source needs CMake 3.16 or later and a C++17 compiler on every platform, then platform tooling: MSYS2 with a clang64 or clangarm64 toolchain on Windows, Xcode Command Line Tools and Homebrew on macOS, and Qt 6.4 or later development packages plus MuPDF on Linux. Note that the prerequisite table in the repository is truncated mid-sentence at the MuPDF entry, so the full Linux dependency list is not readable from the README and the build guide would have to be consulted directly.

The iPad path is the real limitation

There are three ways onto an iPad and none of them is the App Store. Sileo on a jailbroken device takes the SpeedyNote APT repository. TrollStore takes a.ipa downloaded from GitHub Releases. Building from source follows the iPadOS build guide in the repository. The README is explicit that a jailbreak or TrollStore is required and that App Store distribution is not available.

That single constraint undoes part of the project's own argument. The pitch is iPad-quality annotation without iPad pricing, and the desktop and Android builds honour that. On iPad the audience is narrower: you already have a jailbroken iPad or you are willing to install a sideloading tool, and your device's state of compromise is now part of the cost of the app. For an institutional iPad under management, the answer is simply no.

Where a lighter annotation tool or a full notebook suite fits better

The alternatives split along the axis SpeedyNote is trying to occupy.

If the job is only marking up a PDF and never organising pages, a PDF viewer with a built-in highlighter covers it with less to install and no layer model to learn. You give up the edgeless canvas and the per-page markdown notes, but you also give up the requirement to install a Qt application.

If the job is a long-lived notebook that syncs across your devices, with attachment handling and searchable text throughout, a mainstream notebook suite does that with a server behind it. SpeedyNote's differentiator is precisely the absence of that server: multi-tab editing and local files, with no account and no sync service described anywhere in the project. The cost of the local-only model is that the same notebook on two devices is two documents, and merging them is a problem the README does not address.

A third option is the PDF layer inside a drawing app with a SAI-style layer model, which overlaps with SpeedyNote's layer feature but not its PDF annotation speed. The difference in approach is that those tools treat the PDF as one document type among many, while SpeedyNote treats the stylus and the PDF as the central case.

Maintenance cadence and what GPL-3.0 means here

The repository is not archived and the last push was on 2026-09-21. The three most recent releases are v1.6.3 on 2026-09-03, v1.6.2 on 2026-09-01 and v1.6.1 on 2026-08-31, three patch releases over a short window.

The licence is GPL-3.0, with the LICENSE file at the repository root. GPL-3.0 lets you read, modify and redistribute the code, subject to the licence's conditions. For anyone considering SpeedyNote as a starting point for their own annotation app, it means distributed modifications carry the same licence obligation, which rules out folding the code into a closed-source product without a relicensing arrangement.

Two upgrade questions the repository does not answer: whether.snb documents written by v1.6.x open in later versions without loss, and whether the.snbx bundle format is stable across versions. Both matter more here than in most projects, because the user data is ink and layer structure rather than something you can regenerate.

Editorial conclusion

SpeedyNote fits a student or researcher who annotates PDFs with a stylus on hardware too weak for GoodNotes, and who is willing to install a jailbroken package on iPad to get the same app there. It does not fit anyone who needs a sanctioned iPad build from the App Store, a collaborative notebook, or a sync account, since none of those exist here. Before adopting, download the .exe, .dmg or .apk from GitHub Releases or Flathub, open one large PDF you care about, and confirm the stylus latency and rendering on your own device rather than trusting the stated 360Hz figure on a Celeron N4000.

Frequently asked questions

Official sources

1. alpha-liu-01/SpeedyNote on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases