Ios release build "Recording setup failed: Failed to prepare recorder"

[h3knix]

Before submitting a new issue

• I tested using the latest version of the library, as the bug might be already fixed.
• I tested using a supported version of react native.
• I checked for possible duplicate issues, with possible answers.

Bug summary

When using the library to attempt to record audio, our users get this following generic error coming from react-native-nitro-sound : "Recording setup failed: Failed to prepare recorder" on IOS devices with release build

This is very difficult to troubleshoot because the recorder does not exhibit the same behavior in the ios simulator or when run on device directly from xcode development build - only occurs with a release build on device.

Library version

0.2.10

Project type

React Native (bare workflow)

React Native version

0.83.1

Expo SDK version (if applicable)

No response

Environment info

System:
  OS: macOS 15.7.4
  CPU: (10) arm64 Apple M1 Max
  Memory: 235.80 MB / 64.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.17.1
    path: /Users/xxx/.nvm/versions/node/v22.17.1/bin/node
  Yarn:
    version: 1.22.22
    path: /Users/xxx/.nvm/versions/node/v22.17.1/bin/yarn
  npm:
    version: 10.9.2
    path: /Users/xxx/.nvm/versions/node/v22.17.1/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.16.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.5
      - iOS 18.5
      - macOS 15.5
      - tvOS 18.5
      - visionOS 2.5
      - watchOS 11.5
  Android SDK:
    API Levels:
      - "31"
      - "33"
      - "33"
      - "34"
      - "35"
      - "36"
    Build Tools:
      - 30.0.2
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 34.0.0
      - 35.0.0
      - 36.0.0
    System Images:
      - android-31 | ARM 64 v8a
      - android-31 | Google APIs ARM 64 v8a
      - android-33-ext4 | Google Play ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2025.1 AI-251.25410.109.2511.13752376
  Xcode:
    version: 16.4/16F6
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.12
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.0
    wanted: 20.0.0
  react:
    installed: 19.2.0
    wanted: 19.2.0
  react-native:
    installed: 0.83.1
    wanted: ^0.83.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Steps to reproduce

1. startRecorder() call with options similar to the linked gist on release build IOS
2. error

Reproducible example repository

https://gist.github.com/h3knix/c49753019ed2b4cdc32ea4db6ceb68dc

[h3knix]

i may have gotten it to work again.....

i attached to console stream from device and noticed there were errors from audiomixd about setting the sampling rate to 44100

I saw that the medium quality in https://github.com/hyochan/react-native-nitro-sound/blob/main/ios/Sound.swift#L16 uses 44100 sampling rate

In the gist I linked with sample code, I removed the following lines and recompiled a release build to testflight
AVEncoderAudioQualityKeyIOS: AVEncoderAudioQualityIOSType.medium,
AVNumberOfChannelsKeyIOS: 1,

removing those two looks like it took the defaults back to the high quality preset on https://github.com/hyochan/react-native-nitro-sound/blob/main/ios/Sound.swift#L17 to set sampling rate to 48000 but also set 2 channels instead of 1

does anyone have insight as to why this correct the problem? is there something going on in iOS audio drivers not allowing 44100 sampling rate anymore?

it previously worked in production on release builds using 44100

[masterviana]

I'm experiencing what seems to be the same issue, but with a slightly different setup and additional findings.

• Library version: 0.2.12 (latest)
• React Native: 0.81.5
• Expo: 54
• Hermes enabled
• iOS: 26.3.1 (real device)

Behavior

• Works perfectly in debug (Xcode / expo run:ios)
• Works on Android
• Crashes immediately on iOS TestFlight / release build when calling startRecorder

What I tested

• Minimal config:

const audioSet = {
  AudioQuality: "medium"
};

• Also tried removing all overrides (sample rate, channels, etc.)
• Same crash behavior

Important observation

I also noticed logs from audiomixd before the crash, similar to what was described above.

The finding about:

• 44100 Hz (medium) → failing
• 48000 Hz (high) → working

matches what I’m observing.

Additional finding

There may also be a type issue in the native code:

AVSampleRateKey is being set using an Int, while AVFoundation expects a Double.

Hypothesis

This might be a combination of:

• sample rate / preset mismatch (44100 vs 48000)
• stricter AVFoundation validation on newer iOS versions (iOS 26)
• potential type mismatch (Int vs Double) in Sound.swift

Question

Has anyone confirmed whether this is:

• a sample rate compatibility issue (44100 vs 48000)?
• or a native type / AVAudioSession configuration problem?

Happy to test any patch or provide more details.

[kbqdev]

@masterviana
Can you tell me which audioSets working ?

[masterviana]

I tested multiple combinations, and none of them work in release builds — all of them crash.

For example, I tried:

Minimal config:

const audioSet = {
  AudioQuality: "medium"
};

Also tried:

const audioSet = {
  AudioSamplingRate: 44100,
  AudioChannels: 1,
  AudioQuality: "medium",
  AudioEncodingBitRate: 128000,
  AVFormatIDKeyIOS: "aac"
};

Then setting startRecorder

import Sound from "react-native-nitro-sound";
console.log("[MYAPP]", "Calling startRecorder with path:", path);
const audioSet = Platform.OS === "ios" ? RECORDING_AUDIO_SET_IOS : RECORDING_AUDIO_SET_ANDROID;
await Sound.startRecorder(path, audioSet, true);

I can see log "Calling startRecorder with path:" using idevicesyslog then it crash on startRecord

And other variations (removing fields, changing quality, etc.)

All of them crash immediately in iOS release/TestFlight.

In debug (Xcode / expo run:ios), all of these configurations work fine.

So at the moment, I don't have any audioSet that works in release on iOS.

[syedfaheem27]

Has anyone found a solution to this.

This is the package version I am using
"react-native-nitro-sound": "^0.2.12",
The audioSet that I am using while starting the recording

const audioSet =
                Platform.OS === 'android'
                    ? {
                          AudioEncoderAndroid: AudioEncoderAndroidType.AAC,
                          AudioSourceAndroid: AudioSourceAndroidType.VOICE_RECOGNITION,
                          OutputFormatAndroid: OutputFormatAndroidType.AAC_ADTS,
                      }
                    : {
                          AVEncoderAudioQualityKeyIOS: AVEncoderAudioQualityIOSType.high,
                          AVNumberOfChannelsKeyIOS: 2,
                          AVFormatIDKeyIOS: 'aac' as any,
                      };

            const path = await this.audioRecorderPlayer.startRecorder(filename, audioSet);

Tried everything and interestingly what I found was that the version 0.2.8 works well.

[syedfaheem27]

I think the issue lies with AVFormatIDKeyIOS.
I changed it from 'aac' to 'aac ' with a trailing space and the released application did not crash
but when I tried to record the audio an error was thrown
Cannot convert "aac " to enum AVEncodingOption - invalid value!

Any ideas on how can it be fixed.

[Talha-Jawed]

This issue fixed.

#782 (comment)

[h3knix]

This issue fixed.

#782 (comment)

@Talha-Jawed I don't see how that fixes it, not passing any configuration details (leaving AudioSet undefined) doesn't seem like a sane fix if the whole point is to be able to pass configuration to get certain behavior (number of channels, format, sample rate, etc).

Additionally I don't see how not passing an AudioSet (passing undefined for iOS) causes any change in behavior regarding AVFormatIDKeyIOS

AVFormatIDKeyIOS doesn't appear to be producing a string value in the current nitro sound Sound.swift code . getAudioSettings() https://github.com/hyochan/react-native-nitro-sound/blob/main/ios/Sound.swift#L713 default is set to use an int (see https://github.com/hyochan/react-native-nitro-sound/blob/main/ios/Sound.swift#L721 ) and any other value passes through getAudioFormatID() ( see https://github.com/hyochan/react-native-nitro-sound/blob/main/ios/Sound.swift#L774 ) which only returns ints.

So even if you do not pass an AudioSet in to startRecorder (passing undefined instead on iOS like you mentioned), it looks like it's setting AVFormatIDKey to Int(kAudioFormatMPEG4AAC) regardless https://github.com/hyochan/react-native-nitro-sound/blob/main/ios/Sound.swift#L721

[Talha-Jawed]

@h3knix
Thanks for taking a close look — you’re absolutely right about AVFormatIDKeyIOS. Not passing AudioSet doesn’t change its behavior, and it still resolves to Int(kAudioFormatMPEG4AAC) as per the current implementation.

My suggestion to pass undefined on iOS wasn’t meant as a full fix, but more as a temporary workaround to avoid triggering the unsafe numeric conversions happening with custom values (like sample rate, channels, etc.) in release builds.

The actual fix is in the patch I shared — adding guards (isFinite, bounds checks) around those Int(...) conversions in Sound.swift, which is what was causing the crash in my case.

Happy to align on a cleaner fix if you have a better approach 👍

[mtaher1996]

this is still not solved