React Native Windows und macOS: Out-of-Tree-Plattformen einordnen | Mironsoft

1. Was eine Out-of-Tree-Plattform bei React Native bedeutet

React Native Windows und React Native macOS gehören zu einer Kategorie, die Facebook beziehungsweise Meta offiziell als Out-of-Tree-Plattformen bezeichnet: Statt den React-Native-Core-Fork für jede zusätzliche Zielplattform zu forken, definiert React Native seit einigen Jahren stabile Erweiterungspunkte, über die externe Teams eigene Plattform-Implementierungen andocken können, ohne den Kern selbst zu verändern. React Native Windows und React Native macOS werden beide primär von Microsoft gepflegt und nutzen genau diese Architektur, ebenso wie inzwischen auch React Native VisionOS für Apples Vision Pro.

Der entscheidende Unterschied zu einem klassischen Community-Fork ist die Update-Kompatibilität: Weil beide Projekte gegen dieselben offiziellen Erweiterungspunkte wie TurboModules und die Fabric-Renderer-Architektur entwickeln, die auch iOS und Android nutzen, bleiben sie strukturell näher an aktuellen React-Native-Versionen als ein unabhängiger Fork es typischerweise wäre. Das bedeutet allerdings nicht, dass neue React-Native-Core-Versionen sofort auf Windows und macOS verfügbar sind, in der Praxis liegt zwischen einer Core-Version und der entsprechenden Windows- beziehungsweise macOS-Version regelmäßig ein Versatz von mehreren Wochen bis Monaten.

2. React Native Windows: Architektur auf Basis von WinUI 3

React Native Windows rendert Komponenten nicht über eine Web-View oder eine eigene Zeichen-Engine, sondern bildet sie auf echte native Windows-Steuerelemente ab, in aktuellen Versionen über das Windows App SDK mit WinUI 3 als UI-Schicht, in älteren Versionen über UWP-XAML. Native Module werden in C++/WinRT geschrieben, was für Teams mit reiner iOS- und Android-Erfahrung eine echte dritte native Sprache zusätzlich zu Swift und Kotlin bedeutet, sofern plattformspezifische Windows-Funktionalität über den Standardumfang hinaus benötigt wird.

Die Fabric-Renderer-Architektur, die React Native seit den neueren Versionen als Standard-Rendering-Pipeline nutzt, bildet auch unter Windows die Grundlage, wodurch viele der Performance-Verbesserungen aus dem New-Architecture-Umbau von React Native gleichermaßen auf Windows durchschlagen. In der Praxis bedeutet das, dass ein auf Fabric und TurboModules umgestelltes React-Native-Projekt tendenziell reibungsloser auf Windows läuft als ein Projekt, das noch auf der alten Bridge-Architektur basiert.

// windows/MyApp/NativeModules/BatteryModule.h
#pragma once
#include "NativeModules.h"

namespace winrt::MyApp {

REACT_MODULE(BatteryModule)
struct BatteryModule {
  REACT_SYNC_METHOD(GetBatteryLevel)
  double GetBatteryLevel() noexcept {
    return 1.0;
  }
};

}

3. React Native macOS: Näher am iOS-Code als Windows an Android

React Native macOS teilt sich strukturell deutlich mehr Code mit React Native iOS als React Native Windows mit React Native Android, weil beide Apple-Plattformen dieselbe zugrunde liegende Objective-C- und Swift-Toolchain sowie große Teile der Rendering-Infrastruktur nutzen. Statt WinUI oder UWP rendert React Native macOS auf AppKit, dem klassischen macOS-UI-Framework, wodurch viele native iOS-Module mit vergleichsweise geringem Anpassungsaufwand auch unter macOS funktionieren, sofern sie nicht auf reine iOS-spezifische APIs wie Touch-Gesten angewiesen sind.

Microsoft nutzt React Native macOS intern unter anderem für Teile von Office- und Messenger-Anwendungen, was dem Projekt eine ungewöhnlich stabile Produktions-Referenz innerhalb desselben Unternehmens gibt, das auch die Weiterentwicklung finanziert. Das ist ein relevanter Unterschied zu vielen anderen Community-Projekten im React-Native-Ökosystem, bei denen die Wartung von einzelnen Maintainern in der Freizeit abhängt, statt von einem Unternehmen mit eigenem produktivem Interesse an der Stabilität des Projekts.

4. Was zwischen den Plattformen geteilt wird, und was nicht

Der überwiegende Teil der eigentlichen App-Logik lässt sich zwischen Mobile- und Desktop-Zielen teilen: React-Komponenten, State-Management, API-Clients und Geschäftsregeln bleiben plattformunabhängiger JavaScript- beziehungsweise TypeScript-Code, sofern sie nicht direkt auf mobile-spezifische APIs wie Kamera oder GPS zugreifen. Die TurboModule- und Fabric-Architektur sorgt dafür, dass dieselbe Komponentenschnittstelle auf allen unterstützten Plattformen konsistent bleibt, auch wenn die dahinterliegende native Implementierung komplett unterschiedlich ist.

Plattformspezifisch bleiben dagegen praktisch immer die Verpackung und Auslieferung: Unter Windows wird die App typischerweise als MSIX-Paket für den Microsoft Store oder als Sideload-Installation gebaut, unter macOS als klassisches .app-Bundle mit Apple-Notarisierung für die Verteilung außerhalb des Mac App Store. Auch UI-Detailanpassungen wie Tastaturkürzel, Menüleisten-Integration unter macOS oder das native Kontextmenü unter Windows verlangen in der Regel eigenen, plattformspezifischen Code, den es unter iOS oder Android in dieser Form nicht gibt.

{
  "name": "shared-business-logic",
  "main": "src/index.ts",
  "dependencies": {
    "zustand": "^4.5.0"
  }
}

5. Reifegrad und Community-Größe realistisch einschätzen

Die Release-Kadenz von React Native Windows und React Native macOS folgt dem React-Native-Core-Release, liegt aber typischerweise einige Wochen bis Monate dahinter zurück, weil jede neue Core-Version erst gegen die jeweilige Plattform validiert und angepasst werden muss. Für Teams, die stets die allerneueste React-Native-Version nutzen wollen, ist das ein relevanter Planungsfaktor, weil eine brandneue Core-Funktion nicht sofort auf Windows oder macOS verfügbar ist, sondern erst mit zeitlichem Versatz nachgezogen wird.

Die Community-Größe beider Projekte liegt deutlich unter der von iOS und Android, messbar an GitHub-Sternen, Anzahl aktiver Contributor und der Geschwindigkeit, mit der Drittanbieter-Bibliotheken Windows- oder macOS-Unterstützung nachrüsten. Das bedeutet in der Praxis, dass man bei der Auswahl von npm-Paketen aus dem React-Native-Ökosystem regelmäßig prüfen muss, ob eine Bibliothek überhaupt eine Windows- oder macOS-Implementierung mitbringt, statt sich wie bei iOS und Android automatisch darauf verlassen zu können.

6. Praxisbeispiel: Ein internes Desktop-Tool auf Basis der bestehenden App

Ein realistischer Anwendungsfall für React Native Windows ist ein internes Verwaltungswerkzeug, etwa ein Lagerbestand-Dashboard für Mitarbeiter, das denselben API-Client, dieselben Datenmodelle und große Teile der Komponentenbibliothek nutzt, die bereits für die mobile React-Native-App existieren. Statt ein komplett neues Desktop-Projekt in einem anderen Framework aufzusetzen, bindet man React Native Windows als zusätzliches Target in ein bestehendes Monorepo ein und teilt den überwiegenden Teil des Anwendungscodes zwischen mobiler App und Desktop-Tool.

Dieses Szenario funktioniert besonders gut, wenn die betroffene Funktionalität überwiegend aus Formularen, Listen und Datenanzeigen besteht, die ohnehin plattformunabhängig gestaltet sind, und wenig auf mobile-exklusive Interaktionsmuster wie Touch-Gesten oder Kamerazugriff angewiesen ist. Für ein reines internes Tool mit überschaubarer Nutzerzahl rechtfertigt sich der zusätzliche Build- und Wartungsaufwand einer weiteren Plattform meist schneller als bei einer öffentlich vertriebenen Consumer-App.

7. Praktische Einschränkungen im Alltag

Nicht jedes React-Native-Drittanbieter-Paket funktioniert automatisch unter Windows oder macOS, selbst wenn es für iOS und Android einwandfrei läuft. Viele Bibliotheken gehen implizit davon aus, dass nur ios- und android-Unterordner existieren, und das Autolinking-System von React Native Windows beziehungsweise macOS erwartet zusätzliche, explizit benannte windows- oder macos-Verzeichnisse mit eigener nativer Implementierung, die viele Paket-Autoren schlicht nie ergänzt haben.

In der Praxis bedeutet das, dass Teams vor der Einführung von React Native Windows oder macOS jede bestehende Abhängigkeit einzeln prüfen müssen, ob eine kompatible Implementierung existiert, ob sich die fehlende Funktionalität einfach durch eine bedingte Plattform-Weiche im eigenen Code umschiffen lässt, oder ob im schlimmsten Fall ein eigenes natives Modul für die fehlende Plattform nachgezogen werden muss, was den ursprünglich erhofften Zeitgewinn durch Code-Wiederverwendung teilweise wieder aufzehrt.

8. Wann sich der zusätzliche Plattform-Support wirklich lohnt

Der zusätzliche Aufwand für Windows- oder macOS-Support rechtfertigt sich vor allem dann, wenn eine bestehende, produktiv genutzte React-Native-Codebasis bereits einen hohen Anteil plattformunabhängiger Geschäftslogik enthält und ein echter Desktop-Anwendungsfall existiert, der einen Großteil dieser Logik wiederverwenden kann. Teams mit tiefer React-Native-Erfahrung im Haus profitieren zusätzlich davon, dass sie keine komplett neue Technologie erlernen müssen, sondern dieselben React-Konzepte und einen Großteil des bestehenden Werkzeugkastens weiterverwenden.

Für ein greenfield-Desktop-Projekt ohne bestehende React-Native-Mobile-App ist die Rechnung dagegen meist anders zu bewerten: Frameworks wie Electron oder Tauri, die explizit für Desktop-only-Anwendungsfälle entworfen wurden, bringen oft eine reifere Desktop-Werkzeugkette und eine größere Auswahl an Desktop-spezifischen Bibliotheken mit, ohne die zusätzliche Komplexität einer Cross-Mobile-Desktop-Architektur, die bei React Native Windows und macOS strukturell mitgeschleppt wird.

9. Einrichtung und Tooling im Entwickleralltag

Der Einstieg läuft über die Kommandos npx react-native-windows-init beziehungsweise npx react-native-macos-init, die einem bestehenden React-Native-Projekt die jeweilige Plattform-Konfiguration und die notwendigen Ordnerstrukturen hinzufügen. Für React Native Windows ist zusätzlich eine vollständige Visual-Studio-Installation mit dem C++-Desktop-Entwicklungsworkload notwendig, für React Native macOS reicht die ohnehin für iOS-Entwicklung vorhandene Xcode-Installation aus, was den Einstieg für bestehende iOS-Teams spürbar erleichtert.

Der eigentliche Build- und Debug-Zyklus läuft über npx react-native run-windows beziehungsweise npx react-native run-macos, jeweils mit demselben Metro-Bundler und Fast-Refresh-Verhalten wie bei iOS und Android, was die Entwicklererfahrung erfreulich konsistent hält. Für plattformspezifisches Debugging von nativen C++/WinRT- oder Objective-C/Swift-Modulen bleibt aber weiterhin ein Wechsel in Visual Studio beziehungsweise Xcode notwendig, genau wie bei nativen Modul-Problemen unter iOS oder Android auch.

npx react-native-windows-init --overwrite
npx react-native run-windows

npx react-native-macos-init
npx react-native run-macos

10. Zusammenfassung

11. FAQ: React Native Windows und macOS: Das Wichtigste auf einen Blick