React Native und TypeScript 2026: Typsichere Architektur und Interviewfragen

Die Typsicherheit von React Native mit TypeScript ist Mitte 2026 deutlich gereift: Version 0.86 liefert React 19.1, die Strict TypeScript API und eine vollständig bridgeless Architektur auf Basis von Codegen. 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 einrichten

Die mit React Native 0.80 eingeführte Strict TypeScript API beschränkt die öffentliche API-Oberfläche auf Typen, die direkt aus dem Quellcode generiert werden. Das verhindert die versehentliche Abhängigkeit von internen Modulen, die zwischen Minor-Versionen brechen könnten.

{
  "compilerOptions": {
    "strict": true,
    "exactOptionalPropertyTypes": true,
    "noUncheckedIndexedAccess": true,
    "moduleResolution": "bundler",
    "jsx": "react-jsx",
    "types": ["react-native/types/strict"]
  },
  "extends": "@react-native/typescript-config/tsconfig.json"
}

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, im Einklang mit der seit 0.80 durchgesetzten Deprecation tiefer Importe.

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.

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 mit React Native 0.80 eingeführte Strict TypeScript API generiert Typen direkt aus dem Quellcode von React Native, statt handgeschriebene .d.ts-Dateien zu pflegen. Sie beschränkt Importe auf das Root-Paket react-native und veraltet 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. Aktiviert wird sie über "types": ["react-native/types/strict"] in der tsconfig.json.

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.

Weitere React-Native-Interviewfragen finden sich im Deep Dive zu Native Modules, der JSI, Fabric und die bridgeless Architektur im Detail behandelt.

Fazit

• Die Strict TypeScript API (0.80+) beschränkt Importe auf die stabile öffentliche Oberfläche und verhindert Brüche durch interne Änderungen — in jedem neuen Projekt aktivieren
• Codegen generiert native Schnittstellen aus TypeScript-Spezifikationsdateien und verschiebt Typfehler über die JS-nativ-Grenze hinweg von Laufzeit-Crashes zu Build-Zeit-Fehlern
• 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