[iOS] Non-public API usage

[dragan682]

Description
[iOS] Non-public API usage - The app references non-public symbols in XXX: _locale_charset. If method names in your source code match the private Apple APIs listed above, altering your method names will help prevent this app from being flagged in future submissions. In addition, note that one or more of the above APIs may be located in a static library that was included with your app. If so, they must be removed. email from App Store Connect

Expected behavior
The static libraries libiconv.framework/libiconv and libcharset.framework/libcharset contains '_local_charset' API which is in conflict with the non public symbols from Apple API and in my opinion should be renamed.

Current behavior
The static libraries libiconv.framework/libiconv and libcharset.framework/libcharset contains '_local_charset' API which is in conflict with the non public symbols from Apple API. As result, app cannot be released nor distributed to Apple App Connect.

Screenshots

Logs
command executed in terminal "grep -Rnis '_locale_charset' *"

Binary file Pods/mobile-ffmpeg-audio/libiconv.framework/libiconv matches
Binary file Pods/mobile-ffmpeg-audio/libcharset.framework/libcharset matches

Environment

• Platform: [IOS]
• Architecture: [arm64-v8a]
• Version (if applicable) [4.2.2.LTS for audio library]
• Source branch (if applicable) [master]
• Xcode version (if applicable) [10.3]
• Cocoapods version (if applicable) [1.7.5]

[tanersener]

App Store submissions are regularly tested using the test applications under the ios/test-app folder. Unfortunately, none of the applications received this complaint from Apple.

Can you compare your application with pods-with-tooltips test application please? You must be doing something different that triggers Apple's complaint.

[dragan682]

I've compared my app with pods-with-tooltips.
After performing "pod install" on ios/test-app/pods-with-tooltips, the same search result came after "grep -Rnis '_locale_charset' *".

From previous version on TestFlight to this version, I've only added "mobile-ffmpeg-audio" pod and implemented the code for m4a to speex conversion and vice versa.
The app has been denied several times in the last 2 days. The issue/conflict is that the app references non-public symbols: _locale_charset.
I've also tried with "mobile-ffmpeg-full", but the result is the same.

Is there any way to manually import only the frameworks required for m4a-speex conversion and will it help to resolve the issue? Is there anything else i can try to avoid the issue?

Thank you for your time
Have a nice day :]

[tanersener]

Some packages of mobile-ffmpeg (audio, full and full-gpl) depends on libiconv library. This library comes with a second library named libcharset which defines a symbol named _locale_charset. You can see it using nm utility.

nm -a Pods/mobile-ffmpeg-audio/libcharset.framework/libcharset 

Pods/mobile-ffmpeg-audio/libcharset.framework/libcharset(localcharset.o):
...      
0000000000000000 T _locale_charset
...

ITMS-90338 occurs because iOS already includes libiconv and libcharset as system libraries. When Apple sees _locale_charset symbol in a library it thinks that a symbol from its non-public libcharset system library is used. Which is not true and actually a false positive.

Besides, I need to repeat that ITMS-90338 warning is not received by all applications. As I've said in my earlier post, test applications are regularly submitted to App Store, with different packages and none of them receives this warning.

When I asked about comparing your application with pods-with-tooltips, I was expecting to see the differences in Podfile and Xcode build settings. I know that last committed version of pods-with-tooltips depends on the full package. I'm saying that if I depend on audio package and submit that application I don't receive a complaint from Apple.

So, to understand why your application is receiving this error, comparing the settings of these two applications is necessary.

If you don't have time or can't see a difference then you can manually import audio package using Importing Frameworks guide and exclude libiconv and libcharset frameworks.

If it does not work for you, another option is to build your own mobile-ffmpeg package without libiconv library using the build scripts provided.

[dragan682]

Greetings,
I did manage to fix the issue with an alternative solution.
I did it by manually importing the audio package using Universal Binaries, then removed libiconv and libcharset from Build Phases -> Link Binary With Libraries section. It works as it should be and the app passed App Store Connect submission.

Thank you very much for your time and the community effort for the library. It's been a pleasure.

[tanersener]

I'm glad to hear that it worked for you. It is better to leave this issue open until we understand why some applications fail and others do not.

[ztimc]

locale_charset Same name apple private API, you can replace locale_charset to xx_charset in libiconv and libcharset then build
I have the same problems，It is feasible to use this method，Now it's approved by Apple.

[tanersener]

@ztimc thanks, yes it is one of the alternative solutions.

I'm eager to understand the reason. That's why I'm keeping this issue open.

[kliffy]

Also getting this issue using full-gpl on ios, apple won't allow the project to be pushed up. Going off of the universal binaries solution has shown to be very problematic because I also use MobileVLCKit.

Any guidance on how to properly replace locale_charset to xx_charset in the libiconv and libcharset files properly? Those files included look like some sort of compiled source code and replacing any instances of locale_charset to xx_charset doesn't seem to do the trick.

[tanersener]

@kliffy As I've explained in my previous messages, this error is not received by all applications. For example, test applications in this project do not receive this. I think an option or setting is triggering this error.

I expect you to compare your project with test-applications are extract that option/setting. I can do that comparison too if you provide me a sample application which includes this issue.

If you don't have time for that you can try to build your own mobile-ffmpeg version by excluding libiconv.

[ju5td0m7m1nd]

@ztimc
Could you elaborate on how you replace them and rebuild
I've tried it
But I got cannot resolve libconv libconv_open libconv_close error
Thanks

[kliffy]

Update:
I tried out a couple different settings with no luck, due to some time constraints I didn't really have the time to keep on trying all the different options. Instead my plan was to remove MobileVLCKit from my project and import ffmpeg universal binary manually instead of as a Pod.

Went along with replacing MobileVLCKit but kept mobile-ffmpeg as a Pod, sent it up and it got approved by Apple. The only setting I changed then was bitcode enabled to true (MobileVLCKit required it to be disabled). What's weird is during my initial testing with the settings I tried enabling bitcode and it still got rejected by Apple.

Anyway, it works now for me just as a Pod and no MobileVLCKit

[tanersener]

@kliffy Thanks for the update 👍

[tanersener]

Since v4.3.1, iOS and tvOS packages started to use iconv system library instead of iconv external library. This change should resolve this issue. Can someone test and verify this?