iOS: allow opting out of the private-CoreSVG SVG decoder (exclude_files by default, or an opt-in flag)

Comienza inspeccionando el podspec, ios/SVG/CoreSVG.mm, SvgDecoder.{h,mm} y el registro codegenConfig.ios.modulesConformingToProtocol para comparar los enfoques de exclusión predeterminada y activación mediante opt-in. Confirma el comportamiento elegido con pod install, una compilación de iOS y comprobaciones que verifiquen que las fuentes del decodificador SVG y el registro están ausentes de forma predeterminada, pero siguen disponibles cuando se habilitan.

Summary

ios/SVG/CoreSVG.mm reaches five private CoreSVG functions via dlsym, with the symbol names stored base64-encoded. SvgDecoder is then registered app-wide as an RCTImageDataDecoder through codegenConfig.ios.modulesConformingToProtocol, so this code is linked into and reachable from every app that installs the library — including apps that never render an SVG and use SF Symbols for their tab icons.

This is a hard blocker for us, and I suspect for other App Store publishers, so I would like to ask for a supported way to opt out rather than keep patching it locally.

Why it matters

App Store Review Guideline 2.5.1 is about use of private API and carries no obfuscation carve-out. Separately, the Apple Developer PLA distinguishes plain private-API use (§11.2(a), a curable breach with a 30-day cure period) from "hiding or trying to hide functionality from Apple's review" (§11.2(g), which is not). The base64 encoding is what moves this from the first category toward the second, and it was introduced upstream of here — SDWebImageSVGCoder's equivalent change is titled "Change to hidden the symbols and follows App Store Submit rule".

To be clear about what we did and did not find: we have no evidence of any rejection caused by this library, and there is a good deal of precedent for the obfuscated form passing review (expo-image ships the same construction transitively, at scale, and has for years). Our concern is not the likely case — it is that the unlikely case is not a resubmit.

It also cannot be avoided by configuration today. Choosing SF Symbols stops the private functions being called, but canDecodeImageData: is invoked for every image the app decodes, and +[CoreSVGWrapper isSVGData:] runs +initialize and all five dlsym lookups on first use. The symbols are in the binary either way.

What we are asking for

Either would fully solve it, and the first is a one-line change:

1. s.exclude_files = "ios/SVG/**/*" in the podspec by default, with an opt-in (subspec, or a $RNBottomTabsEnableSVG Podfile flag) for the apps that actually want SVG tab icons.
2. An opt-in flag for the whole SVG decoder, covering both the sources and the codegenConfig.ios.modulesConformingToProtocol registration.

Our reading is that most consumers do not use the SVG path at all, so defaulting it off costs those users nothing and removes the question from their review submission entirely.

What we are doing meanwhile

Carrying a patch-package patch against 1.4.0 that deletes ios/SVG/{CoreSVG,SvgDecoder}.{h,mm} and removes the modulesConformingToProtocol entry. Verified on RN 0.84 with the new architecture: pod install produces an identical pod count, the app builds, the generated imageDataDecoderClassNames array is empty, and a string scan of the linked binary finds zero occurrences of CoreSVGWrapper, SvgDecoder, CGSVGDocument, _imageWithCGSVGDocument or the base64 literals (with unrelated symbols from the same library present in the same image as controls). Nothing broke — the decoder only ever served SVG bytes handed to RN's image loader.

Happy to send this as a PR if the maintainers would like it in either shape.

Environment

• react-native-bottom-tabs@1.4.0, @bottom-tabs/react-navigation@1.4.0
• React Native 0.84, new architecture enabled, iOS, CocoaPods, Xcode 26.6