enriched-markdown: native Markdown rendering for React Native

Native text, and what that buys you

Enriched Markdown is a multi-platform SDK for rendering Markdown as native text and editing rich text with Markdown output, and the native part is the whole point of the project.

The rendering feature is described as high-performance Markdown rendering built on platform text APIs with no WebView. That is a design decision with a long list of consequences, and the first one is the obvious one, the text is laid out by the same engine that lays out the rest of your app, so it inherits the system font, the dynamic type settings, the right to left handling and the selection behaviour of the platform.

The second is accessibility, and the project lists it explicitly. VoiceOver on iOS, TalkBack on Android and semantic HTML on the web, which means the rendered output is exposed to assistive technology rather than being an opaque view.

The third is that the output is text, so it can be measured, copied, searched and styled, and a text input that renders Markdown can be built on the same foundation rather than on a screenshot of one.

The complementary half is rich text input, with Markdown output, inline formatting, headings, lists, links and mentions. The direction of the conversion is what makes it interesting: the user types in a rich editor and the model receives Markdown, which is the opposite of the usual arrangement where a Markdown preview is derived from a source string.

Three packages and three API shapes

The packages table is small and each entry links to its own README, which is the shape most multi platform SDKs have and the one that costs you the most when you use it.

The React Native package is on npm as react-native-enriched-markdown, and the usage is a component with a markdown prop and a link handler.

import { EnrichedMarkdownText } from 'react-native-enriched-markdown';
import { Linking } from 'react-native';

<EnrichedMarkdownText
  markdown={"# Hello\n\nThis is **enriched** [markdown](https://commonmark.org)."}
  onLinkPress={({ url }) => Linking.openURL(url)}
/>

The Android package is on Maven Central under com.swmansion.enriched.markdown, with a compose artifact, and it is a Kotlin API with the same shape of call.

dependencies {
  implementation("com.swmansion.enriched.markdown:compose:0.3.0")
}

The iOS package is a Swift package, and the usage is SwiftUI with a modifier for the link handler.

dependencies: [
  .package(
    url: "https://github.com/software-mansion-labs/enriched-markdown-ios.git",
    from: "0.1.0"
  ),
]

The feature list describes the API as consistent across React Native in TypeScript, iOS in Swift and Android in Kotlin, which is the promise a multi platform SDK makes. The iOS example is interesting because it lives in a separate repository under the software-mansion-labs organisation, so the packages are not all built in one place even though the documentation is.

CommonMark, GFM, math, highlighting and streaming

The remaining features are the ones that separate a renderer from a parser, and two of them stand out.

The first is Markdown streaming, described as real-time streaming support for AI and LLM chat interfaces. Rendering a document that is being generated token by token is a different problem from rendering a finished one, because partial syntax has to be tolerated, incomplete emphasis and half written code fences have to be shown sensibly, and the layout has to stay stable while the text changes underneath it. Shipping that once, properly, in a shared library is exactly the kind of thing that is worth not writing three times.

The second is LaTeX math, with block and inline math rendering powered by RaTeX, which covers the other common thing a chat response contains that plain Markdown does not.

Code syntax highlighting is native and powered by tree-sitter, which means it uses the same parsers the rest of the tooling ecosystem uses, so the set of languages is not limited to what a regular expression based highlighter can guess.

The compliance claim is full CommonMark with GitHub Flavored Markdown extensions, the GFM ones being tables, task lists and strikethrough. That matters more than it sounds, because a chat assistant that emits a task list or a table is extremely common, and a renderer that silently drops the table turns a perfectly good answer into a wall of pipe characters.

The compatibility table is the document to read first

There is a feature comparison table in the documentation, and the project links it directly from the feature list with a request to see it for a detailed breakdown of supported features per platform.

The fact that the project publishes that table is the most useful signal in the README. A cross platform library that claims a consistent API while quietly differing in coverage would be a trap, and a library that publishes a per platform matrix is telling you the difference exists and where it is. Read it before you design the feature set, because the answer to whether you can ship a given behaviour on a given platform is in there and not in the bullet list.

The Android example in the quick start also carries a version that does not match the repository's own releases, since the compose artifact is at 0.3.0 while the project tags are 1.1.x. That is normal for a package with its own versioning, but it is a reminder to check the per package readme rather than assuming the repository version applies to the artifact you depend on.

The release history itself is quick. The tags are 1.0.2 on 2026-08-20, 1.1.0 on 2026-10-01 and 1.1.1 on 2026-10-06, so the 1.1 line is young and the 1.0 line has been out since August, and the repository was last pushed to on 2026-10-15.

A monorepo with Maestro screenshot tests

The repository is a Yarn workspace monorepo with packages/ and apps/ as the workspace roots, and the script names in package.json describe the test matrix precisely.

There are example apps per platform, a React Native example, a macOS example, a web example, an Android example and an iOS example, and the end to end tests are driven by Maestro, in a .maestro/ directory with its own scripts directory.

The test targets distinguish the React Native implementations from the native ones, because they are tested differently. There is a mobile suite that runs everything, and then separate suites for the Android native build and the iOS native build, each taking a platform, an app and a configuration file, and there are smoke variants of each, and update-screenshots variants of each.

That is a lot of ceremony for a text renderer, and it is the right amount. A Markdown renderer that renders a table slightly wrong, or a code block with the wrong padding, is not obviously broken, and the only way to catch that is to compare rendered output against a stored image. The screenshot update variants exist for the same reason, so that an intentional change to the rendering is a reviewed diff rather than a surprise.

The rest of the tree is standard for a large React Native project: a turbo.json for the task runner, a lefthook configuration for the git hooks, an eslint config, a babel config, a .yarn directory with the Yarn release pinned, a tool versions file, a clang format configuration for the native code, a context7.json for documentation context, and a vendor/ directory.

Editorial conclusion

enriched-markdown fits a React Native team that has to show Markdown from an AI assistant and wants it to behave like native text, selectable, accessible and consistent with the rest of the app, rather than a web view bolted into a scroll view. It does not fit a project that needs one API across more platforms than the library covers, and it does not fit a team that wants identical feature coverage everywhere, because the project publishes a per platform compatibility table precisely because the coverage is not identical. Verify three things before you commit: which features you actually need on which platforms, by reading the compatibility table rather than the feature list, that the streaming behaviour is what your chat interface requires, since real time streaming is a distinct feature from rendering a finished document, and that you are on a version whose release notes cover the platform you are shipping, given that the project released 1.0.2 in August and 1.1.1 in October 2026.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. software-mansion/enriched-markdown on GitHub