Add (runtime) loadable library/bundle/module support to iOS

Originator:ewmailing
Number:rdar://8473578 Date Originated:2010-09-24
Status:open Resolved:
Product:iOS Product Version:
Classification:feature Reproducible:
 
This is a request for (runtime) loadable libraries/bundles/modules. This is similar to my request for dynamic library support. (Bug ID:  8473551) With the new license term changes to section 3.3.2, it appears that this is no longer forbidden by the terms of agreement. The intention is to use only modules provided in the app bundle and not downloaded later to be in compliance with the iOS license terms. 

There are two useful reasons for this ability.

First, the GPL and LGPL licenses cause issues for developers writing commercial/closed source apps. Loadable modules can sometimes avoid the viral licensing issues, but since iOS currently only allows static linking, this limitation makes (L)GPL off-limits.

Also addition, many projects often prefactor their design and build systems to use loadable libraries, so changing their design and build systems to a dynamic library or static library is a pain.


Second, since RAM is limited on iOS, sometimes it is nice to not load all the code that you don't always need and save some RAM. For example, perhaps I want to include OpenFeint support which is a huge library. But maybe my end users don't always want to use the networking components of my app. Well, maybe I can lazily load it only if it is actually needed. 


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.

-----

Another example I just thought of is that dlopen is very handy for technologies like BridgeSupport and building language bridges to Cocoa. (I will file another request for BridgeSupport shortly.)

Comments


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!