Turbo Modules

In a project, a Turbo Module shows up as a codegenConfig key in its package.json (with type: "modules" and a jsSrcsDir) and a spec file whose name starts with Native, for example specs/NativeLocalStorage.ts. On iOS the class is a .mm file adopting the generated protocol; on Android it extends the generated abstract class and is registered in a BaseReactPackage. Codegen runs on every build (a Gradle task on Android, a script phase during pod install on iOS), so a spec that does not compile breaks the native build, not the app at runtime.

The most common pitfall is getEnforcing in an optional library. If the native module is not linked (broken autolinking, a misconfigured monorepo), the app crashes on first import with an unhelpful message. get returns null and leaves room for a fallback. Types are the other one: a method returning Promise<Object> in the spec becomes an NSDictionary or a WritableMap on the native side; rich types do not cross as-is.

For a new module today the choice is between a plain Turbo Module (worth it if you have C++ to share), the Expo Modules API (Swift/Kotlin DSL, less boilerplate), and Nitro Modules (native Swift/Kotlin over JSI, fastest for chatty calls). All three sit on JSI; the React Native docs recommend Turbo Modules if you plan to write C++.