React Native Support?

[markwitt1]

Problem Statement

Are there any plans to support React Native? What would be the biggest challenges there?

Proposed Solution

👀

Alternatives Considered

No response

Use Case

Priority

None

Contribution

• I am willing to help implement this feature

Additional Context

No response

[zhm]

This would be fantastic. React Native is in need a solid modern markdown component. react-native-markdown-display is ok but it seems to have gone stale and not actively maintained.

FWIW I actually got this library to render a simple output on react-native by making one small change here removing this wrapper div. I also had to provide the components prop that maps to RN components. But it works on a simple output so it seems potentially promising.

[VikashLoomba]

+1, would love to use streamdown in a react-native/expo app!

[ayush-rgp]

well if they do , i hope they will let custom selection on rendered components just like web if thats possible !

[edgarpavlovsky]

@haydenbleasel we publicized https://github.com/darkresearch/streamdown-rn today, streamdown rebuild in react native. happy to contribute upstream - let me know if it's something you guys would like to see added here.

to @zhm's comment, we're using react-native-markdown-display for the time being but happy to migrate to something else given i'm not sure how much it's being maintained

[HarshidKhunt09]

@haydenbleasel Can we add support for the react native please?

[ayush-rgp]

@edgarpavlovsky does this support custom text selection ? And like pass data to custom modal after text selection instead of showing native copy , select all menu that usually appears after text selection !

[hryhoriiK97]

Hi! We’ve built react-native-streamdown, a streaming solution for React Native.

It is built on top of:

1. react-native-enriched-markdown: Fully native Markdown rendering with text selection support and advanced features.
2. remend: From the streamdown ecosystem.
3. react-native-worklets: Utilizing Bundle Mode for high performance.

Check it out here: https://github.com/software-mansion-labs/react-native-streamdown

[thanggggg1]

Hi! We’ve built react-native-streamdown, a streaming solution for React Native.

It is built on top of:

1. react-native-enriched-markdown: Fully native Markdown rendering with text selection support and advanced features.
2. remend: From the streamdown ecosystem.
3. react-native-worklets: Utilizing Bundle Mode for high performance.

Check it out here: https://github.com/software-mansion-labs/react-native-streamdown

It hard to setup

[HarshidKhunt09]

@haydenbleasel Can we add support for the react native please?

@timneutkens @haydenbleasel @sleitor @2hu12 @FranciscoMoretti @aradhyacp @ayhansipahi @thatbeautifuldream @swiftugandan

Any update on this?

[sleitor]

React Native Support: Technical Analysis

Thanks for the interest! I've looked into this in some depth and wanted to share a thorough breakdown of what RN support would actually require.

TL;DR: Supporting React Native would require a nearly complete rewrite of the rendering layer. It's not a configuration option or a thin abstraction — it's a fundamentally different target.

---

Core blockers

1. No DOM — rehype pipeline doesn't work

Streamdown's entire processing pipeline is built on the unified ecosystem: remark (Markdown → MDAST) → rehype (MDAST → HAST) → HTML. The HAST (Hypertext Abstract Syntax Tree) produces HTML nodes like div, pre, code, table, etc.

In React Native there is no DOM and no HTML — <div> and <span> don't exist. The entire HAST output would need to map to <View>, <Text>, <ScrollView>, etc. That's a custom renderer from scratch, not a plugin.

2. rehype-raw, rehype-sanitize, rehype-harden — all DOM-dependent

These plugins operate on raw HTML strings and HTML nodes. In RN context they either become no-ops (raw HTML passthrough has nowhere to go) or need complete replacement. HTML sanitization via rehype-sanitize only makes sense when HTML is the output.

3. CSS / Tailwind — not available in React Native

The entire styling system is Tailwind CSS classes. Every component — CodeBlock, Table, the toolbar buttons, the fullscreen overlay — uses className with Tailwind utilities. RN uses StyleSheet.create() or inline style={} with a completely different property set (fontSize vs text-sm, flexDirection: 'row' vs flex-row, etc.).

The prefix prop (Tailwind v4 prefix support), dark: variants, [&>*:first-child] arbitrary selectors — none of these translate.

4. Shiki syntax highlighting

Shiki renders highlighted code by producing <span> elements with inline color styles derived from TextMate grammars. In RN, <Text> with nested <Text> elements can approximate spans with inline styles — but Shiki's output is HTML-first and the integration in @streamdown/code uses CSS custom properties (--shiki-dark, --sdm-c, etc.) which don't exist in RN's style system.

Would need a full custom renderer for Shiki token output targeting RN primitives.

5. Mermaid diagrams

Mermaid renders to SVG via a browser-based runtime. It uses the DOM extensively (document.createElement, window, etc.). There is no React Native port of Mermaid. This feature would simply not be available.

6. KaTeX / Math

Same situation — KaTeX requires a DOM environment and produces HTML output. @streamdown/math would need a separate RN math renderer (e.g. react-native-mathjax or similar).

7. Interactive controls (copy, download, fullscreen)

• Copy: navigator.clipboard — not available in RN (needs @react-native-clipboard/clipboard)
• Download: <a href download> — doesn't exist in RN
• Fullscreen overlay: uses a DOM portal + document.body — not available in RN

8. "use client" directive

The current package is explicitly a React client component (Next.js App Router). RN doesn't use the App Router model at all, so this directive and the related assumptions would need auditing.

---

What a RN version would look like

The markdown parsing core (remark + MDAST) is actually reusable — that part is pure JS with no DOM dependency. But everything from MDAST onward would need a new implementation:

1. A custom MDAST → RN component tree renderer (replacing react-markdown + rehype entirely)
2. StyleSheet-based theming system replacing Tailwind
3. A custom Shiki token renderer targeting <Text> elements
4. RN-native clipboard, share, and scroll APIs
5. SVG-based or WebView-based fallback for Mermaid/KaTeX

This is effectively a separate package (streamdown-native?) that shares only the markdown parsing and block-splitting logic with the web version.

---

Happy to help think through the architecture if maintainers are interested in going this direction. The streaming/incomplete-markdown-handling logic in particular would be very worth preserving for RN AI chat use cases.