1

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.

Victor Sergienko
  • 13,115
  • 3
  • 57
  • 91
RK1979
  • 213
  • 5
  • 10
  • 1
    Apple does not allow you to perform dynamic linking in your application. Furthermore *any* use of undocumented methods is grounds for rejection. – borrrden Jul 24 '13 at 08:55
  • I accept this as answer, but i don't have the privilege to do mark this as the answer. – RK1979 Jul 24 '13 at 09:30
  • That's because it is not an answer. This is a comment ;). – borrrden Jul 24 '13 at 09:33
  • Did you have any success linking with baresip? It's a real gem and we're going to rely on it, but now I'm stuck exactly on this issue. If yes, can you share your solution please? – Victor Sergienko Jan 29 '14 at 17:02
  • @VictorSergienko Sorry I have not used SO with my login so not able to see your comments. I have created an xcode ios project with baresip and voice calling is working fine when I tested last year. – RK1979 Jun 04 '14 at 06:56
  • @borrrden: Apple explicitly recommends using `dlopen` when you use embedded frameworks and deploy to an iOS lower than 8.0: https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple_ref/doc/uid/TP40014214-CH21-SW3 – user102008 Nov 12 '14 at 21:41
  • @user102008 Yes, this is a new development as of iOS 8 (before that they forbid the use of dynamic linking inside to user frameworks inside of an iOS app). Note the date on my comment. – borrrden Nov 13 '14 at 01:26

2 Answers2

1

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

Community
  • 1
  • 1
Michael Dorner
  • 17,587
  • 13
  • 87
  • 117
  • 1
    I have marked this as right answer, even though I have got the answer from the comments a year back. – RK1979 Jun 04 '14 at 07:02
  • 1
    Apple explicitly recommends using `dlopen` when you use embedded frameworks and deploy to an iOS lower than 8.0: https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionScenarios.html#//apple_ref/doc/uid/TP40014214-CH21-SW3 – user102008 Nov 12 '14 at 21:39
  • 1
    The apple document says that only use dlopen() when user has conditional ios version checking so that if user has ios 8 and newer he/she can call dlopen to open framework bundle ... using dlopen() to ios older than 8.0 is not still recommend – sujat Mar 29 '15 at 05:56
0

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.

Community
  • 1
  • 1
Jano
  • 62,815
  • 21
  • 164
  • 192