Dieses Kapitel schreibt KEIN eigenes natives Modul (das würde Xcode/Android Studio und "Bare Workflow"/expo prebuild voraussetzen, außerhalb des Rahmens dieses Tutorials) – es erklärt KONZEPTIONELL, was passiert, wenn eine Bibliothek wie expo-camera oder @react-native-async-storage/async-storage JavaScript mit nativem Swift-/Kotlin-Code verbindet, damit Sie fremden nativen Modul-Code LESEN und EINORDNEN können.

Wann braucht man überhaupt ein eigenes natives Modul?

Fast alles, was eine typische App braucht (Kamera, Standort, Speicher, Benachrichtigungen), gibt es bereits als fertige Expo-/Community-Bibliothek – useCart/cartStore aus unserem Projekt greifen z. B. NIE direkt auf natives Zeug zu, sondern nutzen die fertige AsyncStorage-Bibliothek. Ein EIGENES natives Modul braucht man nur für: (1) plattformspezifische SDKs ohne fertigen JS-Wrapper (z. B. eine firmeneigene Bezahl-SDK), (2) extrem performance-kritischen Code, der besser direkt in Swift/Kotlin/C++ lebt, oder (3) den Zugriff auf natives Verhalten, das React Native selbst nicht abbildet.

Die TurboModule-Spezifikation

In der neuen Architektur (Kapitel 8) beginnt ein natives Modul mit einer TypeScript-"Spec"-Datei – GENAU diese Datei ist es, die Sie am ehesten in fremdem Code zu Gesicht bekommen, auch wenn Sie selbst nie ein Modul schreiben:

// NativeMyModule.ts - rein deklarativ, kein Implementierungscode
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getBatteryLevel(): number;
  showToast(message: string): void;
}

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

Aus dieser TypeScript-Datei generiert React Native beim Build AUTOMATISCH C++-Code, der die Brücke zur nativen Implementierung schlägt – Sie schreiben die Schnittstelle EINMAL in TypeScript, der native Code auf beiden Plattformen muss sich exakt daran halten.

Die native Seite: konzeptionell, nicht zum Abtippen

Auf iOS (Swift) und Android (Kotlin) implementiert je eine Klasse die in der Spec definierten Methoden – JSI ruft diese Methoden dann DIREKT auf, ohne die alte JSON-Bridge. Der Rückgabewert getBatteryLevel(): number in der Spec bedeutet KONKRET: die native Swift-/Kotlin-Implementierung MUSS synchron eine Zahl zurückgeben können – anders als beim alten Bridge-System, wo praktisch ALLES über einen Promise/Callback laufen musste.

Zurück zu unserem Projekt: warum AsyncStorage schnell ist

Jetzt lässt sich erklären, WARUM AsyncStorage.getItem(...) aus Kapitel 1/2 performant ist, obwohl es nativen Dateisystem-Code aufruft: die moderne Version der Bibliothek implementiert GENAU dieses TurboModule-Muster – eine TypeScript-Spec-Datei, native Swift-/Kotlin-Implementierungen, die über generierten C++-Code via JSI verbunden sind. Als Nutzer der Bibliothek sehen wir davon NICHTS außer der ganz normalen getItem/setItem-API – das ist genau der Sinn einer guten Abstraktion.

Fremden nativen Modul-Code lesen: worauf achten

• Eine *.ts-Datei mit extends TurboModule – das IST die öffentliche API-Vereinbarung, unabhängig von der Implementierung.
• Ein ios/-Ordner mit .swift/.m-Dateien und ein android/-Ordner mit .kt/.java-Dateien – die eigentlichen, plattformspezifischen Implementierungen.
• Eine *.podspec-Datei (iOS) bzw. build.gradle (Android) – die Build-Konfiguration, die dem jeweiligen nativen Build-System sagt, wie das Modul kompiliert wird.