is dlopen use inside a static library in iOS allowed

Question

I am working with a fat static library that uses dlopen() to load interal modules(.so) files inside the static library. On stackoverflow, developers says dlopen() is a private API.

In this case is it fine to use dlopen() or being an private API it shouldn't be used in user libraries irrespective of the library nature i.e static/dynamic.

If I can't use the dlopen() then can someone point to any resource for alternative way to accomplish the same task.

Note: This is regarding baresip BSD library. (http://www.creytiv.com/)

Update: The library is first trying to load all configured modules statically and if it fails then it is trying to load them dynamically using dlopen(). so removing the dynamic loading code will resolve my problem.

Answer 1

dlopen is not allowed on the iOS versions < iOS 8. See e.g. here.

Answer 2

Using dlopen with literal parameters has always been OK.

dlopen is documented, so it’s not a private API. Just type man dlopen in your terminal, or see App Extension Programming Guide > Handling Common Scenarios, or Dynamic Library Usage Guideline >1, 2.

If you try to use dlopen with code signed by you but not included in the app reviewed, you are infringing App Review Guidelines 2.5.2:

2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code, including other apps.

and you may get a message like this:

Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app’s behavior or functionality after App Review approval, which is not in compliance with App Store Review Guideline 2.5.2 and section 3.3.2 of the Apple Developer Program License Agreement.

This code, combined with a remote resource, can facilitate significant changes to your app’s behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes. This includes any code which passes arbitrary parameters to dynamic methods such as dlopen(), dlsym(), respondsToSelector:, performSelector:, method_exchangeImplementations(), and running remote scripts in order to change app behavior and/or call SPI, based on the contents of the downloaded script. Even if the remote resource is not intentionally malicious, it could easily be hijacked via a Man In The Middle (MiTM) attack, which can pose a serious security vulnerability to users of your app.