MarkText is on its 0.20.0 release candidates, and macOS has no universal build

macOS gets two disk images and no universal build

The macOS section is the shortest of the three platform notes and the one that removes an option Apple users tend to expect. Universal builds aren't published, so the release page offers a file named `marktext-mac-(arm64|x64)-%version%.dmg` and you pick the half that matches your processor. The build scripts tell the same story from the other side, since every macOS target in the root manifest is per architecture and no combined target exists.

    "build:mac": "pnpm --filter marktext build:mac",
    "build:mac:x64": "pnpm --filter marktext build:mac:x64",
    "build:mac:arm64": "pnpm --filter marktext build:mac:arm64",
    "build:linux": "pnpm --filter marktext build:linux",

The stated floor is macOS 11 Big Sur or later. Nothing in the download section explains how to tell which variant a given machine needs, or what happens after you install the wrong one, so the choice is left with you. Windows is given that guidance. macOS is not.

Windows publishes two architectures and two install scopes

Windows is the only platform where the mechanics are spelled out, and it opens three ways in. The setup file is `marktext-win-(x64|arm64)-%version%-setup.exe`, published for x64 and for arm64, and the wizard asks whether to install per-user or machine wide. That scope choice is yours to make and it decides who can launch the editor afterwards. Two package managers are offered as alternatives to the wizard.

choco install marktext

winget install marktext

Each route assumes the package manager is already present, Chocolatey in one case and Winget in the other, so a working package manager joins the installer as a prerequisite. Windows 10 or 11 is the stated requirement. A reader on Linux gets neither command, and both of these paths sit above simply copying a file somewhere and double clicking it.

Linux has no command anywhere in the repository

The Linux section is a single sentence and a link. It points at the Linux installation instructions on the project site and stops, with no package name, no repository line and no script to run. The only other statement that covers Linux says that all binaries for Linux, macOS and Windows can be downloaded from the release page, and that if a version is unavailable for your system you should open an issue. So the Linux answer lives outside the repository, on a page the project can change without editing a file you can read, and the stated fallback for a missing build is a bug report rather than a documented workaround. For anyone judging this editor on Linux, the install decision cannot be made from the source tree at all.

The root package is private and pinned to pnpm 10.33.4

There is no npm route into this editor, and the root manifest settles why. The root package is private, so a global npm install of the repository is not a path that can work, and its version reads 0.20.0-dev, which is a development marker rather than a release number. The expected toolchain is pinned just as firmly.

  "packageManager": "[email protected]",
  "engines": {
    "node": ">=20.19.0",
    "pnpm": ">=10"
  },

Node 20.19.0 is the floor and pnpm 10 is the required package manager, not npm and not yarn. A pnpm-lock.yaml and a pnpm-workspace.yaml sit at the root beside a packages/ directory, and every script in the manifest reaches the application through the marktext filter, so one package is selected by name out of a monorepo. The default branch is develop, which means the default clone is a development tree rather than a release tree.

postinstall runs a TypeScript script before anything is built

Install hooks are where a source install can fail before any of the application exists. The root manifest runs one automatically after every install.

    "postinstall": "tsx scripts/postinstall.ts",
    "format": "prettier --write .",
    "lint": "eslint --cache .",

That script is executed by tsx, a TypeScript runner, so an install on a machine whose Node does not meet the engine floor fails here rather than at build time. A separate prepare hook runs husky, and a .husky/ directory at the root is where those git hooks live, so installing from source also installs a pre-commit check on your commits. Beside them sit .npmrc, .prettierrc.yaml, .prettierignore, .editorconfig, .gitattributes, eslint.config.js and a .vscode/ directory. For a contributor that is a strict toolchain, and for an evaluator it explains why the build instructions live on an external documentation page rather than in the repository.

Pandoc support is selective and the subset is not written down

Markdown dialect is the part of this editor most likely to surprise a writer, and the project's own word for Pandoc support is selective. CommonMark and GitHub Flavored Markdown are listed as supported, Pandoc markdown is supported selectively, and alongside them sit math expressions through KaTeX, front matter and emojis. The feature list does not say which Pandoc constructs fall inside that selection, so a document written with a Pandoc extension outside the subset has no documented rendering path and no documented error. What you can inspect instead is the text itself, because source mode exposes the markdown as written, and the project exports HTML and PDF. The other two modes, Typewriter and Focus, change scrolling and emphasis rather than the dialect being parsed.

Three release candidates share one version number

The release tags say where this project stands. The three newest are v0.20.0-rc.5 on 2026-09-19, v0.20.0-rc.6 on 2026-09-24 and v0.20.0-rc.7 on 2026-09-29, so a single version has been through three candidates in eleven days while the root manifest still reads 0.20.0-dev. The repository is not archived, and the last push to the default branch landed on 2026-09-25, four days before that rc.7 tag, so the branch and the newest tag are not the same point in history. Nothing in the tree records what changed between candidates. The changelog is an external page at marktext.me/docs/changelog, and the download section sends you there to see what is new, which means comparing tags is the only in-repository way to see a difference.

Bundled third-party code has its own two scripts

The project licence covers MarkText's own code, and a built editor ships code it did not write, so the repository treats the two separately. One script generates a third-party licence file and another validates licences.

    "gen-third-party": "tsx scripts/generateThirdPartyLicense.ts",
    "validate-licenses": "tsx scripts/validateLicenses.ts",

Licence checking being a script in its own right, rather than part of the lint command, tells you it is treated as a gate in this project's process. MIT covers the repository, but it does not relicense anything bundled into a built binary, and no file in the tree states which third-party components a release contains. The same habit shows up in the documentation, where eight translated READMEs live under docs/i18n and a minify-locales script exists for locale files, keeping translation work versioned apart from application code.

Editorial conclusion

MarkText suits someone who wants a desktop markdown editor they can install from a package manager on Windows and a per architecture disk image on macOS, and the MIT licence leaves that choice open. It does not suit a Linux user hoping for a command in the repository, because the Linux section is a link to an external page, and it does not suit anyone who needs a settled release number, because the newest tags are three release candidates for 0.20.0 while the root manifest still reads 0.20.0-dev. Match the installer architecture to your own machine before downloading, then read the changelog page the download section links to.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes