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:
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.
- 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
Summary
ios/SVG/CoreSVG.mmreaches five private CoreSVG functions viadlsym, with the symbol names stored base64-encoded.SvgDecoderis then registered app-wide as anRCTImageDataDecoderthroughcodegenConfig.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-imageships 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+initializeand all fivedlsymlookups 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:
s.exclude_files = "ios/SVG/**/*"in the podspec by default, with an opt-in (subspec, or a$RNBottomTabsEnableSVGPodfile flag) for the apps that actually want SVG tab icons.codegenConfig.ios.modulesConformingToProtocolregistration.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-packagepatch against1.4.0that deletesios/SVG/{CoreSVG,SvgDecoder}.{h,mm}and removes themodulesConformingToProtocolentry. Verified on RN 0.84 with the new architecture:pod installproduces an identical pod count, the app builds, the generatedimageDataDecoderClassNamesarray is empty, and a string scan of the linked binary finds zero occurrences ofCoreSVGWrapper,SvgDecoder,CGSVGDocument,_imageWithCGSVGDocumentor 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