Open Radar

 
This is a feature request to allow creating/building and using 3rd party dynamic libraries and frameworks on iOS. With the new license term changes to section 3.3.2, it appears that dynamic linking is no longer forbidden by the terms of agreement. However, the Xcode toolchain has been crippled for iOS so it is not possible to build dynamic libraries and frameworks (unlike on Mac) even though we can dynamically link to built in Apple provided frameworks.

This feature is very important because of licenses like the LGPL. There is vast quantity of already written, high quality, tested/debugged software out there that is LGPL, but for commercial, closed source projects, LGPL is untouchable on iOS because we can only currently statically link and the LGPL is viral in this case.


Please bring dynamic library support to iOS. You already provide it for the built in Apple frameworks. Please expose it for the rest of us. There shouldn't be any more security concerns than allowing interpreted languages on IOS (which everybody seems to be obsessed with in the new license terms).



This is the new clause:

3.3.2 An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework.


This is the previous version:

3.3.2 An Application may not itself install or launch other executable code by any means,including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple's Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.




I have additional reasons to want this feature. 

1) Objective-C categories are causing havoc with static linking. This requires the use of -ObjC or worse -all_load. The latter flag is particularly problematic for projects that expect duplicate symbols to be thrown away. 

2) Using code from multiple projects. The problem is often these larger projects depend on common dependencies and create code duplication. For example, the Facebook code for iOS is commonly embedded into projects. This creates multiple problems. 

a) First, it encourages developers to embed the code into their libraries instead of taking the time to properly setup the dependencies as a separate (dynamic) library. 

b) Second, there is version drift where different projects may be using different versions of the same library.

c) Third, embedding the code also encourages library developers to be sloppy and they will more likely break the API or ABI. This combined with (b) makes it really hard to deal with.

With dynamic libraries and judicious use of @rpath should minimize or eliminate all of these problems.

Objective-C namespaces might solve this problem, but that's another discussion. Dynamic libraries are proven and simply need to be uncrippled on iOS.