React Native und TypeScript 2026: Typsichere Architektur und Interviewfragen

Die Typsicherheit von React Native mit TypeScript ist Mitte 2026 deutlich gereift: Version 0.87 macht die Strict TypeScript API zum obligatorischen Standard und schließt eine umfassende Modernisierung der Toolchain ab. TypeScript ist nicht länger nur optionaler Klebstoff zwischen JavaScript und nativem Code. Es bildet den gesamten Vertrag von Komponenten-Props bis zu TurboModule-Schnittstellen ab und fängt Abweichungen bereits zur Build-Zeit ab, statt sie in Crash-Logs der Produktion auftauchen zu lassen.

Warum TypeScript jetzt der Standard für React-Native-Projekte ist

Jeder Aufruf von npx react-native init gerüstet seit Version 0.76 ein TypeScript-Projekt. Der eigentliche Umbruch fand jedoch an der nativen Grenze statt. Vor Codegen schrieben Entwickler manuelle Typzusicherungen beim Übergang von JavaScript zu Objective-C oder Kotlin, ein über Strings definierter Vertrag, der zur Laufzeit stillschweigend brach. Codegen liest TypeScript-Spezifikationsdateien und generiert daraus automatisch C++-, Objective-C++- und Java/Kotlin-Schnittstellen. Deklariert die TypeScript-Spezifikation eine Methode mit Rückgabewert number, erzwingt die generierte native Schnittstelle diese Einschränkung zur Compile-Zeit.

Die React-Native-Dokumentation deckt das Grundsetup ab, doch die typsicheren Muster, die in der Produktion zählen, gehen weiter: typisierte Navigationsstacks, generische API-Hooks, diskriminierte Unions für State Machines und Codegen-gesteuerte TurboModule-Spezifikationen.

Die Strict TypeScript API: Von Opt-in zum Standard

Die Strict TypeScript API wurde in React Native 0.80 als Opt-in-Feature eingeführt. Ab 0.87 ist sie der obligatorische Standard für alle neuen Projekte. Die Typen werden direkt aus dem Quellcode von React Native generiert, statt manuell gepflegt zu werden, was Abweichungen zwischen der dokumentierten API und der tatsächlichen Implementierung eliminiert.

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "strict": true,
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true
  }
}

Mit dieser Konfiguration löst der Import von etwas aus einem Unterpfad wie react-native/Libraries/Text/Text einen Typfehler aus. Alle Importe müssen aus dem Root-Paket react-native stammen. Falls eine Bibliothek oder eine ältere Codebasis noch auf tiefe Importe angewiesen ist, steht ein temporäres Opt-out bis 0.88 zur Verfügung:

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "customConditions": ["react-native", "react-native-legacy-deep-imports"]
  }
}

Dieses Opt-out wird in 0.89 entfernt. Die Migration sollte vorher erfolgen.

Toolchain-Anforderungen in 0.87

React Native 0.87 erhöht die Mindestversionen über die gesamte Build-Kette:

Für Android erfordert AGP 9 zusätzliche Konfiguration:

# android/gradle.properties
android.builtInKotlin=false
android.newDsl=false

Diese Anforderungen gelten für alle Projekte, die auf 0.87+ abzielen. Der Migrationsguide zur New Architecture behandelt den breiteren Kontext dieser Änderungen.

Typsichere Navigation mit React Navigation 7

React Navigation 7.x bietet erstklassige TypeScript-Unterstützung. Das zentrale Muster: einen Typ RootStackParamList definieren, der jeden Bildschirmnamen auf seine erwarteten Params abbildet, und diesen Typ dann durch Navigatoren und Bildschirmkomponenten reichen.

export type RootStackParamList = {
  Home: undefined;
  Profile: { userId: string };
  Settings: undefined;
  ArticleDetail: { articleId: string; source: 'feed' | 'search' };
};

export type AppTabParamList = {
  Dashboard: undefined;
  Explore: { category?: string };
  Notifications: undefined;
};

Bildschirmkomponenten erhalten dann typisierte Props ohne manuelles Casting:

import type { NativeStackScreenProps } from '@react-navigation/native-stack';
import type { RootStackParamList } from '../navigation/types';

type Props = NativeStackScreenProps<RootStackParamList, 'ArticleDetail'>;

export function ArticleDetailScreen({ route, navigation }: Props) {
  // route.params.articleId ist string — durch den Typ garantiert
  // route.params.source ist 'feed' | 'search' — keine Laufzeitprüfung nötig
  const { articleId, source } = route.params;

  // navigation.navigate('Profile', { userId: '123' }) — typgeprüft
  // navigation.navigate('Profile', {}) — Compile-Fehler: userId fehlt
  return (
    <ArticleView id={articleId} referrer={source} />
  );
}

Das beseitigt eine ganze Klasse von Laufzeitfehlern: Die Navigation zu einem Bildschirm mit falschen oder fehlenden Params schlägt bereits zur Build-Zeit fehl.

Ein typsicheres TurboModule mit Codegen bauen

TurboModules ersetzen das alte Native-Modules-System. Die TypeScript-Spezifikationsdatei dient als einzige Quelle der Wahrheit, denn Codegen generiert daraus die nativen Schnittstellen. Weichen Spezifikation und native Implementierung voneinander ab, schlägt der Build fehl.

import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceModel(): string;
  getBatteryLevel(): Promise<number>;
  getStorageInfo(): Promise<{
    totalBytes: number;
    freeBytes: number;
    usedPercentage: number;
  }>;
  onBatteryChange(callback: (level: number) => void): void;
}

export default TurboModuleRegistry.getEnforcing<Spec>('DeviceInfo');

Der Aufruf von npx react-native codegen erzeugt die entsprechenden C++-, Objective-C++- und Java-Schnittstellen. Die native Implementierung muss jede Methodensignatur exakt einhalten. So muss getStorageInfo ein Objekt mit drei numerischen Feldern zurückgeben; eine abweichende Form führt auf nativer Seite zu einem Compile-Fehler.

class DeviceInfoModule(reactContext: ReactApplicationContext) :
    NativeDeviceInfoSpec(reactContext) {

    // Rückgabetyp durch generiertes NativeDeviceInfoSpec erzwungen
    override fun getDeviceModel(): String {
        return Build.MODEL
    }

    override fun getBatteryLevel(): Promise<Double> {
        val bm = reactContext.getSystemService(Context.BATTERY_SERVICE)
            as BatteryManager
        val level = bm.getIntProperty(
            BatteryManager.BATTERY_PROPERTY_CAPACITY
        ).toDouble()
        return Promise.resolve(level)
    }
}

Dieser Ansatz beseitigt das Parsen von ReadableMap und NSDictionary, das in der alten Architektur stille Bugs durch Typumwandlung verursachte. Für einen tieferen Einblick in das Native-Module-System siehe die Interviewfragen zu Native Modules.

Generisches Daten-Fetching mit typisierten API-Hooks

Ein wiederverwendbares Muster für typisierte Hooks vermeidet doppelte Fetch-Logik über Bildschirme hinweg und bewahrt zugleich die vollständige Typinferenz:

import { useQuery, UseQueryOptions } from '@tanstack/react-query';

interface ApiResponse<T> {
  data: T;
  meta: { page: number; totalPages: number };
}

export function useApiQuery<T>(
  key: readonly string[],
  endpoint: string,
  options?: Omit<UseQueryOptions<ApiResponse<T>>, 'queryKey' | 'queryFn'>
) {
  return useQuery<ApiResponse<T>>({
    queryKey: key,
    queryFn: async () => {
      const response = await fetch(`${API_BASE}${endpoint}`);
      if (!response.ok) throw new ApiError(response.status);
      return response.json() as Promise<ApiResponse<T>>;
    },
    ...options,
  });
}

// Verwendung — T wird als Article[] abgeleitet
interface Article {
  id: string;
  title: string;
  publishedAt: string;
}

const { data, isLoading } = useApiQuery<Article[]>(
  ['articles', 'latest'],
  '/articles?sort=latest'
);
// data.data ist Article[] — vollständig typisiert
// data.meta.totalPages ist number

Der generische Parameter T fließt durch die gesamte Kette: von der Aufrufstelle des Hooks über die Query-Funktion bis zur Komponente, die das Ergebnis konsumiert. Keine as-Casts, keine any-Typen.

Diskriminierte Unions für State Machines

Komplexe Bildschirmzustände wie Laden, Fehler, Leer und Geladen lassen sich am besten als diskriminierte Unions modellieren, statt als Sammlung optionaler Felder:

type ScreenState<T> =
  | { status: 'idle' }
  | { status: 'loading' }
  | { status: 'error'; error: string; retryCount: number }
  | { status: 'empty'; message: string }
  | { status: 'loaded'; data: T; refreshedAt: Date };

// components/DataScreen.tsx
function renderContent<T>(state: ScreenState<T>, renderItem: (data: T) => ReactNode) {
  switch (state.status) {
    case 'idle':
      return null;
    case 'loading':
      return <LoadingSpinner />;
    case 'error':
      // state.error ist hier string — TypeScript grenzt automatisch ein
      return <ErrorBanner message={state.error} retries={state.retryCount} />;
    case 'empty':
      return <EmptyState message={state.message} />;
    case 'loaded':
      // state.data ist T — vollständig typisiert
      return renderItem(state.data);
  }
}

Dieses Muster macht unmögliche Zustände nicht darstellbar. Ein loading-Zustand kann nicht versehentlich veraltete data mitführen, und ein error-Zustand enthält stets Kontext zum Debuggen.

Interviewfragen zu React Native und TypeScript

Diese Fragen spiegeln wider, was erfahrene Mobile-Engineering-Teams 2026 in Interviews stellen, nachdem die New Architecture und TypeScript zum Standard geworden sind.

Wie erzwingt Codegen Typsicherheit über die JavaScript-nativ-Grenze hinweg?

Codegen liest TypeScript- (oder Flow-)Spezifikationsdateien und generiert daraus C++-, Objective-C++- und Java/Kotlin-Schnittstellencode. Die generierten nativen Schnittstellen erzwingen exakt die Methodensignaturen, Parametertypen und Rückgabetypen, die in der Spezifikation definiert sind. Weicht die native Implementierung ab — gibt sie Int zurück, wo die Spezifikation Double deklariert, oder lässt ein Feld eines Structs weg —, lehnt der native Compiler den Build ab. Das verschiebt Typfehler von Laufzeit-Crashes zu Build-Zeit-Fehlern.

Was ist die Strict TypeScript API und warum ist sie wichtig?

Die Strict TypeScript API generiert Typen direkt aus dem Quellcode von React Native, statt handgeschriebene .d.ts-Dateien zu pflegen. In 0.87 wurde sie zum obligatorischen Standard. Sie beschränkt Importe auf das Root-Paket react-native und depreciert tiefe Importe. Damit definiert sie eine stabile öffentliche API-Oberfläche: Interne Refactorings können Consumer-Code nicht brechen, solange Consumer nur strikte Typen nutzen. Ein temporäres Opt-out über customConditions bleibt bis 0.88 verfügbar.

Wie typisiert man React-Navigation-Params über verschachtelte Navigatoren hinweg?

Pro Navigator einen ParamList-Typ definieren und diese mit NavigatorScreenParams zusammensetzen. Für einen in einen Stack verschachtelten Tab-Navigator referenziert die ParamList des Stacks die des Tabs: type RootStack = { Main: NavigatorScreenParams<TabParamList>; Modal: { id: string } }. Jeder navigate()-Aufruf wird dann durch die gesamte Verschachtelungshierarchie typgeprüft und fängt falsche Bildschirmnamen oder fehlende Params zur Compile-Zeit ab.

Welches Problem lösen diskriminierte Unions im State-Management von React Native?

Diskriminierte Unions modellieren sich gegenseitig ausschließende Zustände (Laden, Fehler, Geladen) als getrennte Zweige eines Union-Typs, geschlüsselt über ein status-Feld. TypeScript grenzt den Typ in jedem Zweig einer switch-Anweisung ein, sodass der Zugriff auf state.data nur möglich ist, wenn state.status === 'loaded'. Das verhindert unmögliche Zustände wie einen Ladeindikator, der neben Fehlerdaten angezeigt wird — eine Fehlerklasse, die optionale Felder und boolesche Flags nicht verhindern können.

Erkläre den Unterschied zwischen TurboModules und dem alten Native-Modules-System.

Native Modules kommunizierten über die asynchrone Bridge und serialisierten alle Daten zu JSON. TurboModules nutzen JSI (JavaScript Interface) für synchrone, direkte C++-Aufrufe — ohne Serialisierungs-Overhead. Sie laden zudem verzögert (bei erster Nutzung statt beim App-Start, was die Kaltstartzeit reduziert) und verwenden Codegen, um typsichere Schnittstellen aus TypeScript-Spezifikationen zu generieren. Das alte System setzte auf das Parsen von ReadableMap / NSDictionary mit Typumwandlung zur Laufzeit; TurboModules erzwingen Typen zur Compile-Zeit.

Welche APIs wurden in React Native 0.87 entfernt?

0.87 entfernte InteractionManager (stattdessen requestIdleCallback verwenden), die Typen NativeMethods / NativeMethodsMixin (stattdessen HostInstance verwenden) und mehrere StatusBar-Props. Tiefe Importe zu src/private/-Pfaden sind jetzt Typfehler. Das useTurboModules-Flag wurde ebenfalls entfernt, da TurboModules nun immer aktiviert sind.

Weitere React-Native-Interviewfragen behandelt der vollständige Leitfaden zu Architektur, Performance und Debugging-Themen.

Quellen

• React Native 0.87 Release Notes — Strict TypeScript API als Standard, Toolchain-Anforderungen, API-Entfernungen
• React Native TypeScript-Dokumentation — Offizieller TypeScript-Setup-Guide
• React Navigation TypeScript-Guide — Typisierte Navigationsmuster
• TanStack Query-Dokumentation — Daten-Fetching mit Typinferenz

Das Wichtigste zu React Native TypeScript 2026

• Die Strict TypeScript API (obligatorisch in 0.87) beschränkt Importe auf die stabile öffentliche Oberfläche und verhindert Brüche durch interne Änderungen. Das Opt-out für veraltete tiefe Importe ist nur bis 0.88 verfügbar
• Codegen generiert native Schnittstellen aus TypeScript-Spezifikationsdateien und verschiebt Typfehler über die JS-nativ-Grenze hinweg von Laufzeit-Crashes zu Build-Zeit-Fehlern
• Toolchain-Mindestversionen in 0.87: Node.js 22.13+, Kotlin 2.0+, AGP 9, compileSdk 34+
• Typisierte Navigations-Params über RootStackParamList und NativeStackScreenProps fangen falsche Bildschirmnamen und fehlende Params ab, bevor die App läuft
• Diskriminierte Unions modellieren Bildschirmzustände als sich gegenseitig ausschließende Zweige und machen unmögliche Zustände auf Typebene nicht darstellbar
• TurboModules mit typisierten Spezifikationen ersetzen das alte Parsen von ReadableMap / NSDictionary und erzwingen vollständige Typsicherheit von JavaScript über C++ bis zum plattformnativen Code
• Generische API-Hooks mit TanStack Query bewahren die Typinferenz vom Endpunkt bis zur Komponente ohne manuelle Casts