Aero Markdown vs MacDown: reading files or editing beside a preview?

First identify which MacDown you mean

MacDown appears in years of Markdown recommendations, but the name alone does not identify the software you are about to install. The original project has a stable release, separate prereleases and a history that other continuations may build on. Their features and compatibility should not be combined into one imaginary current product.

This comparison concerns the original MacDown project. If you are looking at MacDown 3000 or another continuation, use that project’s own release notes instead. That distinction matters more than declaring one app newer or giving it a larger feature count.

The core workflow is straightforward: MacDown is an open-source editor where source and preview work together. Aero Markdown begins with the rendered page and makes editing optional. One is directly suited to authoring while checking output; the other is designed around reading documents that already exist.

Features compared

Scroll sideways to compare both apps →

The original feature page and official releases support the distinction. An unspecified or untested feature is not automatically missing.

Source-and-preview editing still has a clear use

Keeping the raw Markdown visible is useful when you are repairing a table, checking a code fence or learning how the syntax creates the rendered document. You can see the source structure and its consequence together. That is a valid working preference, especially for documents you write yourself.

Aero Markdown offers a source mode and an optional preview beside it during editing. Its ordinary reading mode uses the space for the document, surrounding files and heading outline. If you are mostly reviewing other people’s text, that arrangement may be more relevant than the authoring tools. If you spend the session changing source, a dedicated editor remains a sensible choice.

The reader-versus-editor article explains that division without treating either category as unable to display Markdown. An app can support both activities and still put one of them first.

Compatibility and rendering are version-specific

The original MacDown site advertises a particular stable download, while the repository also lists prereleases. One prerelease mentions upgrading Mermaid. That alone is enough to make a blanket claim that MacDown never supports diagrams unreliable. The exact build matters.

Before replacing an installed setup, record the version you use and the syntax you depend on. Include front matter, math, tables, local images and any diagrams. A useful migration question is whether the new reader understands your documents, not whether its marketing page contains the same format names.

Aero Markdown hides YAML and uses a front-matter title only when there is no H1 in the body. It bundles its highlighting, Mermaid and KaTeX. These are specific reading choices to compare against your files, rather than promises that every Markdown extension will behave identically.

Review a folder instead of a single sample paragraph

An authoring preview can look convincing on one short page and still tell you little about reviewing a connected project. Use the Project Reading Kit to follow the specification into architecture and decisions. Then return to the acceptance criteria.

In a copy, correct one line and verify the result. Keep that editing task separate from reading through the folder. If your installed MacDown build handles both naturally, continuing to use it is reasonable. If the friction is mostly moving among documents, the file tree and history in Aero Markdown are the parts worth evaluating.

Cost and a practical migration path

The original MacDown project is open source and does not need to become a paid-reader purchase just because it is familiar from older articles. Check its current official downloads and the compatibility of the actual build you intend to keep.

Aero Markdown is $14.99 USD, one-time, for a lifetime Aero 1.x license for one Mac. Download and checkout are not available yet. It requires macOS 14 or later. Keep your current working setup, preserve the source files and test any future reader on a copy of a representative folder. A migration should solve a repeated reading problem without making your documentation less portable.