What Was ReactXP? Microsoft's Cross-Platform React Library, Our Experience, and What to Use Now

ReactXP was an open-source library from Microsoft's Skype team that let developers write a single React and React Native codebase for iOS, Android, and the web.

Microsoft declared it end of life in 2022 and archived its GitHub repository in June 2026. We used ReactXP on a client project shortly after its release and got the web version of a mobile app almost for free.

This article explains what ReactXP was, how we built with it, and what we'd recommend to a team facing the same problem today.

What Was ReactXP and Why Did Microsoft Build It?

ReactXP was a JavaScript library that let one React codebase render native UI on iOS and Android and HTML on the web. According to the ReactXP FAQ, it "was developed by the Skype team at Microsoft in support of their development needs." The code appeared on GitHub in March 2017, and Microsoft announced it publicly in April 2017.

React and React Native already let teams share business logic across the web and mobile, but the view layer still had to be written twice: <div> and CSS for the browser, <View> and native styles for phones. ReactXP added what its README calls "a thin cross-platform layer." If you wrote your app against that abstraction, you could share view definitions, styles, and animations across platforms, and still add platform-specific variants where you needed them.

ReactXP deliberately exposed only the props, style attributes, and APIs that worked on every supported platform, so code that compiled for one target would behave consistently on the others. Its targets were iOS and Android (via React Native), the web (via React), and Windows UWP, which the FAQ listed as still in progress. ReactXP was written in TypeScript and shipped with type definitions for its entire interface.

Is ReactXP Still Maintained in 2026?

No. ReactXP is end of life. In April 2022, Microsoft added a notice to the README stating that "the ReactXP library is no longer being maintained," that no new versions will be published, and recommending React Native for Web instead. On June 11, 2026, Microsoft archived the repository, which is now read-only.

You can still install the package from npm and read the source, but you shouldn't start a new project on it. ReactXP 2.0.0 targets React Native versions from 2019. Every iOS and Android SDK update since then widens the gap between what the library expects and what app stores require.

How Did Cross-Platform App Development Look When ReactXP Launched?

In 2017, a team that wanted one codebase for iOS, Android, and the web had several options, and each came with a compromise. Most of those options still exist, though not all of them survived the decade.

Compiled-language platforms such as Xamarin and RubyMotion appealed to C# and Ruby developers targeting iOS and Android, but they still required a separate web app, and some required a paid subscription. Microsoft ended Xamarin support on May 1, 2024; its successor is .NET MAUI.

Hybrid apps built with Cordova/PhoneGap or Ionic shared business logic, HTML layout, and CSS between the web and mobile by wrapping a web app in a mobile browser runtime with native plugins. That came with some performance overhead, which faster devices have steadily eroded. Adobe shut down PhoneGap Build in October 2020; Apache Cordova and Ionic carry on.

Progressive Web Apps (PWAs) were the lighter alternative: regular web apps that use modern browser APIs instead of third-party wrappers to reach native features. They're still a solid choice when app-store presence isn't a requirement.

Google's Flutter took a different route: apps are written in Dart, and Flutter draws its own widgets instead of using the platform's native UI components. It has since grown into one of the two leading cross-platform frameworks.

React Native ran business logic in a JavaScript engine and rendered real native iOS and Android UI elements, which gave it a performance edge over browser-based approaches. Its business logic could be shared with the web, but layout and styling still had to be rebuilt in HTML and CSS.

Two open-source projects set out to close that gap at the time: Nicolas Gallagher's React Native for Web and Microsoft's ReactXP. Both provided web equivalents of React Native components such as View and TextInput, plus abstractions over common features like key-value storage and network status.

Why Did Monterail Choose ReactXP Over React Native for Web?

We first picked up ReactXP for a new client project whose main requirement was an app for iOS, Android, and the web with nearly identical features and very few design differences. Our three-person team had extensive JavaScript experience but had never shipped a native app in Objective-C, Swift, or Java, so a cross-platform approach felt right.

At first, we assumed we'd build the mobile and web apps separately. The designs barely differed, but the behavior did, and we expected that many components would need separate implementations anyway, making a shared codebase hard to maintain. Then we took a closer look at React Native for Web and ReactXP. React Native for Web was more popular, with more GitHub stars and more learning resources, but we went with ReactXP for two reasons.

First, it came from Microsoft, as a building block for the new cross-platform Skype. The new Skype had already shipped, which convinced us the library was production-ready and wouldn't be going away anytime soon. Second, it was written in TypeScript, our language of choice for the project. With Visual Studio Code and its IntelliSense code completion, we got type hints and instant error checking not only in logic but in markup and styles: every component prop and style attribute was typed, so mistakes showed up while we were still typing.

In hindsight, the first argument aged badly, because corporate backing didn't guarantee longevity. Microsoft stopped maintaining ReactXP five years after releasing it, and retired Skype itself three years after that. Meanwhile, the community-run React Native for Web kept shipping. Its TypeScript gap, which mattered to us then, has also closed: type definitions are now available through @types/react-native-web. If we were choosing today, adoption breadth and maintainer activity would weigh more than the name on the repository.

How Did a Single ReactXP Codebase Serve iOS, Android, and the Web?

We structured the app so the platforms split at the top and bottom of the stack and shared everything in between. The ReactXP GitHub repo included sample apps, from a simple Hello World to a test app exercising every component and API, and we based our setup on those.

Each platform got its own entry point (app.native.tsx and app.web.tsx) and its own navigation setup: React Navigation for native and React Router for the web, because navigation patterns differ so much between mobile and browser apps.

Below the navigation, views were shared. Once we reached a specific view (a screen on native, a route on the web), we imported a common container, and that's where the single-codebase benefit kicked in. Using ReactXP's cross-platform components, we defined each view once, and it looked and behaved as expected on mobile and the web. For simple platform-specific overrides, RX.Platform.getType() told us which platform we were on.

When a component needed genuinely different web and native versions, we imported it through path aliases. Separate tsconfig.json files and separate webpack configs resolved the same alias to different folders: @components pointed to src/components/web on the web and to src/components/native on mobile. To make webpack work for native builds too, we swapped React Native's default packager for Callstack's Haul.

After more than six months on the project, we were impressed with ReactXP and hadn't hit any blocking problems. The web app had cost us very little extra work. Our case study of Guild, a professional-community app built with React Native and ReactXP, shows what that looks like in numbers: the mobile apps shared about 99% of their code, and the web version reused around 80% of the JavaScript.

Most of that tooling has since moved on. TSLint, which we used for linting, was deprecated in favor of ESLint. Haul's maintainers now recommend migrating to Re.Pack. The architecture itself, shared views with platform-specific edges, is still the right pattern.

What Should You Use Instead of ReactXP Today?

Use React Native for Web, ideally through Expo. That's Microsoft's own recommendation in the ReactXP end-of-life notice, and it's what most React Native teams building for the web use now.

React Native for Web describes itself as "a compatibility layer between React DOM and React Native." You write standard React Native components (View, Text, TextInput, ScrollView), and on the web they render as DOM elements with styles compiled to CSS. Its compatibility table covers "the vast majority of React Native's JavaScript API." Twitter and Flipkart are among the companies that have adopted it, and we used it when migrating Cooleaf's employee recognition platform off unsupported AngularJS, sharing code between the web app and the React Native mobile apps.

The library's own multi-platform guide says it's "strongly recommended" to use Expo, which handles the web configuration for you. The React Native docs likewise recommend starting new apps with a framework, specifically Expo. Expo for web uses React Native for Web under the hood, and Expo Router gives you file-based routing across platforms, with optional static rendering for SEO.

The two libraries handle platform gaps in opposite ways. ReactXP limited you to the lowest common denominator, so anything it exposed worked everywhere. React Native for Web gives you nearly the full React Native API, but a few pieces are mocked or missing on the web, such as Alert, RefreshControl, and KeyboardAvoidingView. You need to know where those gaps are.

How Do You Migrate a ReactXP App to React Native for Web?

You rewrite the view layer and keep the rest. Business logic, state management, and API clients carry over unchanged, because ReactXP never touched them. The work concentrates in three places.

1. Swap ReactXP components for React Native ones. RX.View, RX.Text, RX.Image, and RX.TextInput map closely to their React Native counterparts, but props and style names don't always match one to one, so budget time to check each screen by hand.

2. Rework platform detection. RX.Platform.getType() checks become Platform.OS. Custom path aliases and parallel webpack configs can give way to platform file extensions (Button.web.tsx, Button.native.tsx), which the bundler resolves automatically.

3. Move the build tooling. An Expo project is usually the cleanest destination, because it brings Metro bundling, web support, and routing in one package. Teams that need webpack-style customization for native builds can use Re.Pack, and TSLint configs should move to ESLint.

Expect most of the effort to go into everything that froze alongside ReactXP. An app last updated around 2019 may also need a large React Native upgrade, replacements for abandoned third-party libraries, and new navigation. Before estimating, audit your dependencies. In some cases, a structured rebuild on a current stack is cheaper than an incremental upgrade.

What Does a Shared Codebase Really Cost?

A single codebase cuts duplicated work and pushes platform differences to the edges of the app, where you still have to staff and test them.

Navigation and UX still diverge. Our original assumption, that navigation would stay platform-specific, held for years. Expo Router has since narrowed the gap, but web users still expect URLs, deep links, browser history, and hover states that mobile users don't.

The web also has its own quality bar. A web app that's an afterthought of a mobile app shows it, in accessibility, SEO, and load performance. Static rendering and code splitting are available through Expo and React Native for Web, but someone has to own them.

Finally, dependencies carry business risk. ReactXP was a well-built library from a major vendor, and it still reached end of life while apps depended on it. Favor tools with broad adoption and active maintainers, keep platform-specific code behind clear boundaries, and budget for regular framework upgrades instead of letting them pile up.

Is a Single React Native Codebase Still Worth It for Web and Mobile?

Yes, for most products where the mobile and web apps share features and audiences. ReactXP showed us that one TypeScript codebase can deliver iOS, Android, and web apps with a three-person team, and that lesson outlived the library. Today you don't need a niche abstraction to get there, since React Native for Web and Expo are the officially recommended path. The work that decides success is less glamorous: drawing clear lines where platforms differ, picking dependencies that will still be maintained in five years, and keeping up with upgrades.

If you're planning a cross-platform product, or you're sitting on a ReactXP-era app that needs a way forward, Monterail's React Native and web application development teams can help you assess what to keep, what to migrate, and what's worth rebuilding.