# react-native-windows-samples is a showroom, not a framework

> microsoft/react-native-windows-samples collects React Native sample apps, components and templates for Windows, macOS and Surface Duo, sitting alongside the react-native-windows and react-native-macos framework repositories. Its four samples show a calculator written twice, native module plumbing, CI configuration and WinRT interop, and the documentation site is built with a Docker image pinned to a very old Node release.

**microsoft/react-native-windows-samples** — A repository showcasing React Native samples and templates for Windows, macOS, and Surface Duo.

- Repository: https://github.com/microsoft/react-native-windows-samples
- Website: https://microsoft.github.io/react-native-windows/
- Stars: 544 · Forks: 218
- Language: C#
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-react-native-windows-samples

## A companion to the framework repositories

The repository describes itself as a companion to the React Native for Windows and React Native for macOS repos, and the content here features React Native sample apps, components and templates for Windows, macOS and Duo. That distinction is the first thing to understand. The framework work, the runtime, the bindings and the platform packs live in the other two repositories, while this one is a gallery of finished examples that show how those pieces are used. The audience is a developer who already has decided to target React Native on Windows or macOS and now needs a working example of one specific thing, a native module, a build pipeline, an interop call, and not a conceptual introduction. The project is MIT licensed, it is not archived, and the last push was on 2026-10-18. There are no GitHub releases, which is consistent with the nature of the repository, since a sample gallery has nothing to release. The samples themselves are listed in the README, and there are four of them, each targeting a different question a developer actually asks.

## Four samples, four different questions

The samples table in the README is short enough to read as a decision list. The Calculator is a sample RNW app implementing a simple calculator with both C++ and C# implementations, which answers the question of how much of the app you write in each language. ContinuousIntegration holds sample CI pipeline configurations for RNW projects, which answers how you wire a build for this platform rather than for a mobile one. NativeModuleSample is a sample RNW Native Module and Native Component, which is the classic question of how you expose a platform API to JavaScript and how you expose a platform view to the React tree. The fourth entry, ReactNativeWinRT, points at a sample app in the separate microsoft/react-native-winrt repository, and it shows an app that uses React Native WinRT to consume native WinRT APIs. That last one is a pointer rather than a copy, which tells you something about how the project is organised, since some demonstrations need infrastructure that lives outside the samples repository. The sample folders in the tree confirm the layout, with samples/Calculator, samples/ContinuousIntegration and samples/NativeModuleSample present alongside a samples/README.md.

## The Calculator written twice is the interesting one

Most sample galleries show one way of doing something. This one deliberately shows two. The Calculator sample implements the same application with both a C++ and a C# implementation, and that pairing is the point rather than an accident. React Native for Windows is a hybrid stack where the JavaScript layer, the native host language and the interop layer all have to agree, and a sample that only exists in one language hides the decisions that matter, which are the boundary between the two and how state crosses it. Reading both versions of the same calculator is a way to see which parts of the logic are shared and which are reimplemented natively, and to see the shape of the native module boundary from both sides. The primary language of the repository is C#, and the file listing shows the samples directory as the working area, with samples-old/ retained separately as an archive of earlier examples. For a developer choosing a language for a Windows native module, the value of this sample is higher than its simplicity suggests, and it is also the piece most likely to be copied directly into a real project.

## Continuous integration is treated as a sample too

Having CI configuration as a first class sample is a sign of how the project thinks about adoption. Most developers building a React Native application for Windows arrive from either mobile or web, and in both cases the existing pipeline assumes a different toolchain, a different artifact format and a different test story. A directory of sample pipeline configurations is an answer to that gap. The repository carries the GitHub Actions side as well, with three workflows visible in the README, ci.yml, ci-upgrade.yml and website-publish.yml, and the upgrade workflow is notable because it exists to test the samples against newer versions of the framework, which is the maintenance task that most sample repositories skip. There is also an .ado/ directory, which points to Azure DevOps pipeline definitions, and a CodeQL.yml for code scanning. The trade-off of the ContinuousIntegration sample is that it is a starting point that encodes decisions about signing, packaging and artifact layout that you will need to review, since the sample is showing a shape rather than a policy.

## The docs site runs in Docker on a Node 8 image

The documentation site in this repository is a Docusaurus site, and it is built and served with Docker, which the repository makes explicit in a compose file. The service is named docusaurus, it builds from the repository root and publishes two ports:

```yaml
services:
  docusaurus:
    build: .
    ports:
      - 3000:3000
      - 35729:35729
```

The volumes mount the docs, website, i18n, pages, static, sidebars and siteConfig directories into the container, so a local edit to the site shows up without rebuilding the image, and the working directory is /app/website. The image itself is defined by the Dockerfile at the root:

```dockerfile
FROM node:8.11.4

WORKDIR /app/website

EXPOSE 3000 35729
COPY ./docs /app/docs
COPY ./website /app/website
RUN yarn install

CMD ["yarn", "start"]
```

This is the part of the repository that has aged badly, and it is worth saying plainly. A base image pinned to node 8.11.4 is a release from 2018, and the install step runs yarn install with no mention of a frozen lockfile for the website, which means a site build can pull different transitive versions on different days. It does not affect the samples themselves, which are consumed by cloning and opening in an IDE, but it does mean the local docs preview is the least trustworthy part of the project and the site that CI publishes through the website-publish workflow is the one to rely on.

## Two site generations and a legacy samples folder

The top level listing tells a story of a repository in mid-migration. There are two website directories, website/ and websitev2/, which is why the compose file mounts website/core, website/i18n, website/pages, website/static, website/sidebars.json and website/siteConfig.js individually rather than the whole directory, since a monolithic websitev2 folder cannot be overlaid piecemeal in the same way. There is also samples-old/, which preserves earlier versions of the examples rather than deleting them, and a .spelling file that suggests a spell check runs over documentation text, plus a .vscode/ directory for editor settings. A .dockerignore sits alongside the compose file so the build context excludes local artefacts. Taken together, this is a repository that keeps its history in place, which is helpful when you want to see how a sample changed and how the docs were restructured, and unhelpful when you want a clean snapshot. The website directory is also not the documentation site for the framework itself, since the React Native for Windows documentation is published from the microsoft.github.io/react-native-windows site, which is the homepage given for this project.

## Where a samples repository is the wrong answer

The realistic alternative is to start from the template that the framework repository already provides and write your own application, ignoring the samples entirely. The difference in approach is that the samples are teaching artefacts and the template is a starting point, and that distinction shows up in three ways. A sample is not versioned with the framework, so a sample you copied a year ago may reference APIs that have since changed, and the upgrade workflow in CI exists precisely to notice that. A sample is not hardened, so it shows a technique rather than a shipped application, with none of the error handling, accessibility work or localisation a real product needs. And a sample cannot be depended on, since there is no package to install, no version constraint to satisfy and no release to track, so the only thing you can take is the code. The samples earn their place in the specific cases, when the question is how to do one thing on this platform, when you need the C++ and C# versions of the same feature side by side, or when you need a CI configuration to start from. For everything else, the template in the framework repository and its own documentation are the faster path.

## Conclusion

Use react-native-windows-samples when you need a working reference for a specific React Native for Windows problem, a native module or native component to copy, or CI configuration for an RNW project. Do not treat it as a dependency, since it is a gallery of examples with no versioned releases, and do not use its Docker setup for the docs site as a model for anything new, given the Node 8 base image. Before starting from a sample, check that the target framework repository, react-native-windows or react-native-macos, is where the actual dependency and template live, and note the last push was on 2026-10-18.

## FAQ

### What is in the react-native-windows-samples repository?

It is a companion to the React Native for Windows and React Native for macOS repositories, and it holds sample apps, components and templates for Windows, macOS and Duo. The four samples listed are Calculator, ContinuousIntegration, NativeModuleSample and a pointer to a React Native WinRT app.

### What does the Calculator sample demonstrate?

The README describes it as a sample RNW app implementing a simple calculator with both C++ and C# implementations, so you can compare the same feature written in each of the two host languages.

### How do I run the documentation site locally?

The repository ships a docker-compose.yml with a docusaurus service built from the root Dockerfile, publishing ports 3000 and 35729 and mounting the docs and website directories. The image is based on node:8.11.4 and runs yarn install followed by yarn start.

### How do contributions to react-native-windows-samples work?

Most contributions require agreeing to a Contributor License Agreement, and a CLA bot checks pull requests and decorates them accordingly. You only need to do this once across the repos using that CLA, and the project has adopted the Microsoft Open Source Code of Conduct.

## Sources

- [Issues](https://github.com/microsoft/react-native-windows-samples/issues)
- [License: MIT](https://github.com/microsoft/react-native-windows-samples/blob/main/LICENSE)
- [microsoft/react-native-windows-samples on GitHub](https://github.com/microsoft/react-native-windows-samples)
- [Project website](https://microsoft.github.io/react-native-windows/)
- [README](https://github.com/microsoft/react-native-windows-samples/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-react-native-windows-samples