App Store Rejection: ITMS-90338 - Non-public API usage in TalsecRuntime

[NapasPayu]

Bug Description

Our iOS app was rejected from the App Store with error ITMS-90338 due to non-public API usage in TalsecRuntime.framework.

Error Message from Apple

90338: Non-public API usage. The app references non-public symbols in Frameworks/TalsecRuntime.framework/TalsecRuntime: __dyld_get_shared_cache_range. If any APIs appear mangled, run the xcrun swift-demangle command in Terminal on the mangled API names to convert them to a human-readable form. If method names in your source code match the private Apple APIs listed, alter them to avoid triggering this error in future submissions. One or more of the APIs may come from a static library in your app. If so, remove them.

Environment

• freeRASP version: 8.2.3
• Flutter version: 3.47.5
• Xcode version: 27.0
• macOS: Tahoe 26.6.2
• iOS Deployment Target: 15.6
• Build method: flutter build ipa --release

Investigation

I inspected the TalsecRuntime.xcframework binary and confirmed the presence of multiple private Apple APIs:

$ nm TalsecRuntime.xcframework/ios-arm64/TalsecRuntime.framework/TalsecRuntime | grep "__dyld"
                 U __dyld_get_image_header
                 U __dyld_get_image_name
                 U __dyld_get_image_vmaddr_slide
                 U __dyld_get_shared_cache_range  # <-- Flagged by Apple
                 U __dyld_image_count
                 U __dyld_register_func_for_add_image

The __dyld_get_shared_cache_range symbol is a private Apple API (note the __ prefix) that Apple's review process is now flagging.

Testing

I tested multiple versions of freeRASP to determine when this was introduced:

• 8.2.3 - ❌ Contains __dyld_get_shared_cache_range - REJECTED by App Store
• 8.2.2 - ✅ PASSED App Store review

Impact

This completely blocks App Store submissions for any app using freeRASP 8.2.3. We had to pin our app to version 8.2.2 temporarily.

Request

1. Please recompile TalsecRuntime.xcframework without using private Apple APIs like __dyld_get_shared_cache_range
2. Provide a timeline for when a fixed version will be available
3. If there's a workaround or alternative approach, please document it