Mapbox Version
default
React Native Version
0.86.0
Platform
iOS
@rnmapbox/maps version
10.3.1
Standalone component to reproduce
import Mapbox from '@rnmapbox/maps';
import { StyleSheet } from 'react-native';
const BugReport = () => (
<Mapbox.MapView style={styles.map}>
<Mapbox.Camera centerCoordinate={[15.97, 45.81]} zoomLevel={14} />
</Mapbox.MapView>
);
const styles = StyleSheet.create({ map: { flex: 1 } });
export default BugReport;
Observed behavior and steps to reproduce
Build fails while compiling the rnmapbox-maps pod, with:
'rnmapbox_maps/rnmapbox_maps-Swift.h' file not found
The failing code (rnmapbox_maps-Swift.pre.h):
#if RNMBX_USE_FRAMEWORKS
#import <rnmapbox_maps/rnmapbox_maps-Swift.h>
#else
#import <rnmapbox_maps-Swift.h>
#endif
Setup:
- Expo SDK 57.0.2, React Native 0.86.0, New Architecture on
- Xcode 26, CocoaPods 1.16.2
- useFrameworks: static (required - project also uses @react-native-firebase, which needs static linkage)
During pod install, Expo's build logs show:
[Expo] Disabling USE_FRAMEWORKS for 89 pods (... rnmapbox-maps ...)
So rnmapbox-maps is being compiled as a plain static library, not a framework. But RNMBX_USE_FRAMEWORKS still evaluates true, so the code looks for the framework-style header path, which doesn't exist under this setup.
I tried forcing RNMBX_USE_FRAMEWORKS=0 via GCC_PREPROCESSOR_DEFINITIONS in a Podfile post_install hook (both early and late in the hook, to rule out an ordering issue). No effect either way, the macro still resolves true at compile time, suggesting it isn't controlled by that build setting.
Separately: with useFrameworks: static, rnmapbox-maps's own Podfile hook forces MapboxCommon / MapboxCoreMaps / MapboxMaps / Turf to dynamic frameworks, which trips CocoaPods' no-static-dynamic-mixing validator. Worked around with a custom Podfile patch, but that just gets you to this next error.
Expected behavior
rnmapbox-maps should compile under useFrameworks: static + RN 0.86 + Expo SDK 57, taking the non-framework Swift header import to match how it's actually being built.
Notes / preliminary analysis
Question: is there a supported way to force the non-framework header path for rnmapbox-maps when the project requires static linkage? Or is static linkage + New Architecture + Expo SDK 57 not yet supported for this library?
Additional links and references
No response
Mapbox Version
default
React Native Version
0.86.0
Platform
iOS
@rnmapbox/mapsversion10.3.1
Standalone component to reproduce
Observed behavior and steps to reproduce
Build fails while compiling the rnmapbox-maps pod, with:
'rnmapbox_maps/rnmapbox_maps-Swift.h' file not found
The failing code (rnmapbox_maps-Swift.pre.h):
#if RNMBX_USE_FRAMEWORKS
#import <rnmapbox_maps/rnmapbox_maps-Swift.h>
#else
#import <rnmapbox_maps-Swift.h>
#endif
Setup:
During pod install, Expo's build logs show:
[Expo] Disabling USE_FRAMEWORKS for 89 pods (... rnmapbox-maps ...)
So rnmapbox-maps is being compiled as a plain static library, not a framework. But RNMBX_USE_FRAMEWORKS still evaluates true, so the code looks for the framework-style header path, which doesn't exist under this setup.
I tried forcing RNMBX_USE_FRAMEWORKS=0 via GCC_PREPROCESSOR_DEFINITIONS in a Podfile post_install hook (both early and late in the hook, to rule out an ordering issue). No effect either way, the macro still resolves true at compile time, suggesting it isn't controlled by that build setting.
Separately: with useFrameworks: static, rnmapbox-maps's own Podfile hook forces MapboxCommon / MapboxCoreMaps / MapboxMaps / Turf to dynamic frameworks, which trips CocoaPods' no-static-dynamic-mixing validator. Worked around with a custom Podfile patch, but that just gets you to this next error.
Expected behavior
rnmapbox-maps should compile under useFrameworks: static + RN 0.86 + Expo SDK 57, taking the non-framework Swift header import to match how it's actually being built.
Notes / preliminary analysis
Question: is there a supported way to force the non-framework header path for rnmapbox-maps when the project requires static linkage? Or is static linkage + New Architecture + Expo SDK 57 not yet supported for this library?
Additional links and references
No response