[Won’t Do] 📢 Heads-up: Dropping NitroModules in v5.0.0 — TurboModule-only going forward

[hyochan]

TL;DR
We fixed and iterated on several Nitro-related reports — including #662, #673, and #675 — but NitroModules kept breaking across real-world setups. To prioritize stability and velocity, we’re removing NitroModules in the next major release (v5.0.0) and standardizing on TurboModule only. The JS API remains the same.

---

Why we’re making this change

While addressing user reports, we repeatedly ran into Nitro-specific failure modes that are difficult to avoid or document around:

• End-user codegen & packaging confusion — In [#662](https://github.com/hyochan/react-native-audio-recorder-player/issues/662), users hit “Cannot find module …/nitro/AudioRecorderPlayerNitro” and “nitro-codegen” guidance that shouldn’t apply to app consumers. We removed codegen steps from the README and adjusted packaging, but confusion kept resurfacing whenever projects’ Nitro setups differed.

• Peer-dependency churn — In [#673](https://github.com/hyochan/react-native-audio-recorder-player/issues/673), react-native-nitro-modules version skew caused ERESOLVE conflicts. Aligning peer ranges helped some users but broke others depending on their workspace constraints.

• iOS build/link errors — In [#675](https://github.com/hyochan/react-native-audio-recorder-player/issues/675), teams saw:

  • Could not build Objective-C module 'AudioRecorderPlayer'
  • Missing folly/experimental/coro/Coroutine.h
  • duplicate symbol link errors when combined with other Nitro libs (e.g. react-native-video)
  • Fragility with use_frameworks! :linkage => :static (common when Firebase/other pods require it)

• Environment sensitivity — Some clean RN 0.80 apps built fine, but the moment another Nitro module or static-framework requirement entered the graph, builds regressed again. This made Nitro behavior non-deterministic across projects.

We did land multiple fixes in 4.x and validated them against the example app, but the operational cost and user friction around Nitro remained high. This slowed down features and bugfixes unrelated to build tooling.

---

What’s changing in v5.0.0

• 🔁 TurboModule-only implementation for New Architecture
• 🚫 NitroModules removed (no nitro.json, no app-side codegen steps)
• ✅ Public JS API stays the same — most apps won’t need code changes

For early users

npm install react-native-audio-recorder-player@next

This command installs the latest pre-release version, starting from v5.

Huge thanks to everyone who reported, reproduced, and stress-tested builds — especially the folks in #662, #673 #675. Your feedback directly shaped this decision. 🙏

[monilraycha]

Getting shift error when install new latest version

[hyochan]

@monilraycha I am thankfully continuing working on nitromodule with help by the maintainer @mrousavy. So this plan may not continue if nitromodule works fine!

https://github.com/hyochan/react-native-audio-recorder-player/pull/680#issuecomment-3184879633 should be discussed before we actually migrate nitromodule.

[monilraycha]

I got the solution using the old version of Library 3.6.12 with latest react native version by minimal code

[hyochan]

We'll focus on Nitromodule! It works well recently from 4.3.0!