Optional playback-only iOS build without microphone APIs

Abierto
#1,398 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
cpp, ios, objective-c, react-native, swift

Línea de trabajo

Start by reviewing the attached v0.13.6 patch and the iOS recorder implementations named in the issue: IOSAudioRecorder, NativeAudioRecorder, IOSRecorderCallback, and AudioRecorderHostObject. Trace how the iOS build is configured for CocoaPods, Swift Package Manager, and Expo config plugins, then define and verify the disabled build behavior: playback and synthesis remain available, while recording requests return an unsupported-operation error. The issue reports a working local proof of concept but no comprehensive validation.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

feature-request ios
Feature Request
Problem

Some applications use react-native-audio-api exclusively for audio playback and synthesis, without requiring microphone input or audio recording.

However, the iOS binary still includes recording-related implementations and references to microphone permission APIs, even when the application never uses these features.

This can complicate App Store privacy audits and introduces native functionality that is unnecessary for playback-only applications.

Proposed solution

Introduce an optional build-time configuration to disable audio recording on iOS.

For example:

RNAudioAPI_ENABLE_RECORDING=false

The option would:

  • Exclude iOS recorder implementations from compilation.
  • Remove references to microphone permission request/check APIs from the playback-only build.
  • Preserve audio playback, synthesis, decoding, and the existing audio engine.
  • Return a clear unsupported-operation error if recording is requested.
  • Keep recording enabled by default for full backward compatibility.

Ideally, the configuration would support CocoaPods, Swift Package Manager, and Expo config plugins.

Existing implementation

I maintain a React Native application that uses this library exclusively for synthesized workout audio cues.

For react-native-audio-api 0.13.6, I implemented a local Yarn patch that:

  • Excludes IOSAudioRecorder, NativeAudioRecorder, IOSRecorderCallback, and AudioRecorderHostObject implementations from the iOS CocoaPods build.
  • Removes calls to AVAudioApplication / AVAudioSession microphone permission APIs.
  • Preserves the JSI recorder factory but makes recording attempts fail explicitly.
  • Uses MA_NO_DEVICE_IO=1 for miniaudio while retaining decoding and playback through AVAudioEngine.

The patched version builds and runs on iOS, and audio playback works. This is not yet a comprehensive validation of every audio scenario.

Related implementation patterns

I have implemented optional native build configurations in two other React Native libraries:

react-native-file-hash

https://github.com/Preeternal/react-native-file-hash

Supports build-time engine selection across Android, CocoaPods, SwiftPM, and Expo, compiling and linking only the selected implementation.

react-native-document-scanner-plugin

https://github.com/Preeternal/react-native-document-scanner-plugin

Supports optional Android analysis features through Gradle properties and an Expo config plugin.

Contribution

Would you be interested in supporting an optional playback-only iOS build?

I’ve attached my current Yarn patch against v0.13.6 as a proof of concept. It is application-specific and not intended as a ready-to-merge solution, but it demonstrates the changes needed for a playback-only iOS build. I’m happy to help adapt it into a configurable upstream implementation.

react-native-audio-api-npm-0.13.6-3169d14b69.patch

Lenguaje dominante
C++
Estrellas
856
Forks
100
Merge medio
2 d 1 h
PR fusionados (30 d)
34

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de software-mansion/react-native-audio-api

Todos los issues de software-mansion/react-native-audio-api

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.