> On 3 Dec 2016, at 12:00, Andreas Falkenhahn <andr...@falkenhahn.com> wrote: > > On 03.12.2016 at 00:40 Jens Alfke wrote: > >> dlopen is hardly undocumented; it’s part of the core BSD Unix >> library. It’s got a man page and everything. > > That doesn't mean that it's ok to use it on iOS because of the sandbox. > You aren't allowed to use other standard BSD functions like exit(), > mkstemp(), exec(), system(), etc. on iOS either because of the sandbox. > >> Prior to iOS 8, the sandbox that 3rd party iOS apps ran in blocked >> calls to dlopen, as well as other attempts to load dynamic libraries >> from within the app bundle. That is now no longer the case, so you >> can use dlopen > > Once again, that is your opinion unless there is any document from > Apple explicitly stating that it's allowed. The fact that it works > doesn't count :) > > I don't want to sound overly pedantic here and I really believe you > guys that probably it's really allowed to use dlopen() starting with > iOS 8 and everything is fine. All I'm trying to stress here is that > basically when using dlopen() we are relying on undocumented behaviour > and there is no guarantee that what we're doing is really officially > supported. > >> That’s sort of weird; however, a framework is just a dynamic >> library packaged with its headers in a specific bundle format. You >> can always use a framework target and then add a script build step >> to copy the library out of the framework. > > Once again, that's relying on undocumented behaviour. It's obvious > that a framework is just a bundle containing a dylib but nobody > can say whether manually dlopen()ing this dylib is something that is > allowed on iOS. Maybe future versions of iOS will block manual dlopen() > access to the dylib inside the framework and will only allow the > system dylib loader to open it. Who knows.
Your worries are formally justified: we are all at the mercy of Apple. A lot of features are underspecified, or come with an implicit promise from Apple, not an explicit one. For example, in the written documentation you get no guarantee of being able to create a secret key inside the secure enclave. It is formally written down only as a possibility that Apple reserves to itself to create a secret key inside the secure enclave in some very restrictive cases (some specific key type). Of course, if no secure enclave is available, the specified API can still create secret keys for you. But if your purpose is to ensure that your secret key is inside the secure enclave, you have no guaranty from Apple! > >> I think the lack of a dylib target may just reflect that plug-ins >> of the kind you’re implementing aren’t really very useful on iOS. >> Since there’s no way to install extra plugins (downloading >> executable code is explicitly forbidden), the set of plugins is >> effectively fixed, meaning it would be more efficient to just >> statically link them all into the app. > > What about NSDocumentDirectory? Users could copy additional plugins > as frameworks into the app's documents directory using iTunes. Will > dlopen()ing such dylibs work as well? Or does it only work when the > binaries are stored in the main bundle container? Notably, the App Store Review Guidelines doesn’t specify a formal criteria. https://developer.apple.com/app-store/review/guidelines/ <https://developer.apple.com/app-store/review/guidelines/> However, it seems that your scenario is clearly rejected. (2.1, 2.5.2, 2.5.3). There is no exception, even thru the AppStore (On Demand Resources explicitly exclude executable code). https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/ -- __Pascal J. Bourguignon__ _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
