fix(iOS): replace racy RaTeXFFI modulemap-strip script with an explicit-modules opt-out

[chrfalch]

fix(iOS): replace racy RaTeXFFI modulemap-strip script with an explicit-modules opt-out

Summary

The [ios] react-native-enriched-markdown job in react-native-community/nightly-tests went red against react-native@0.88.0-nightly-20260717 (run):

error: Clang dependency scanner failure:
  …/Debug-iphonesimulator/include/module.modulemap:1:8: error: redefinition of module 'RaTeXFFI'
  …/Debug-iphonesimulator/ReactNativeEnrichedMarkdown/include/module.modulemap:1:8: note: previously defined here

What's going on

Xcode materializes the RaTeX binary target's xcframework into both the platform-wide products dir and the pod's own build dir — two identical module.modulemaps defining RaTeXFFI, both on the pod target's search paths. That duplication has always existed; the existing Fix RaTeXFFI Module Redefinition script phase sed-strips the platform-wide copy before_compile.

Two things changed:

1. React Native's VFS-overlay removal (the prebuilt/SwiftPM stack, first shipped in 0.88.0-nightly-20260717) removed the -ivfsoverlay flag that had been disqualifying this pod target from Xcode 26's default explicit modules mode. The target now builds with -explicit-module-build, whose dependency scanner loads every reachable module map eagerly and hard-errors on the duplicate — where classic implicit modules tolerate it (verified: an implicit-modules compile against both duplicate maps prints the diagnostic but exits 0).
2. The script-phase approach races the scanner: it mutates a build product mid-build. On Xcode 26.3 (what CI runs) the scanner reads the modulemap before the script's edit lands and the build fails even though the script ran; on 26.6 the script happens to win and the build passes. A workaround whose correctness depends on undocumented scan scheduling isn't stable across Xcode releases.

The fix

Set SWIFT_ENABLE_EXPLICIT_MODULES = NO in the pod's pod_target_xcconfig when math is enabled, and drop the now-redundant strip script (the signature-dedup phase stays). Under implicit modules the duplicate definition is benign — no build products need patching at all.

This is declarative (no mid-build mutation, no race), works on every RN version, and takes effect at pod install time.

Related: react-native side ships the same opt-out for every spm_dependency consumer in react/react-native#57589 — but this library shouldn't need to wait for an RN release, and dropping the racy script is worthwhile regardless.

Test plan

Fresh RN app on react-native@0.88.0-nightly-20260717-b33de750b + react-native-enriched-markdown@0.8.0-nightly-20260716 with the prebuilt-core flags CI uses (RCT_USE_RN_DEP=1 RCT_USE_PREBUILT_RNCORE=1), Xcode 26.6, stock React Native spm.rb (i.e. without the RN-side fix), this podspec swapped into node_modules:

• pod install: SWIFT_ENABLE_EXPLICIT_MODULES = NO lands on both configurations of the pod target; the strip phase is gone from the generated project.
• Build: the pod target's SwiftDriver invocation no longer contains -explicit-module-build; BUILD SUCCEEDED with both duplicate module.modulemap copies deliberately present.

[hryhoriiK97]

LGTM! @chrfalch thank you for the fix!

[hryhoriiK97]

@chrfalch CI (rn-build-ios) was failing on Xcode 26.3 - the fix needs 26.6. I've pushed a commit bumping CI Xcode to 26.6.