dlopen on development iPhone codesign issue

Hi,

For the purposes of iteration speed in development builds, on an iPhone in development mode, I am attempting to use hot reloaded dylibs. The goal is that the app is rarely fully restarted and small code changes can be applied quickly, drastically reducing iteration speed.

For this purpose I have a socket server on my Mac that sends changed dylibs to my app on my iPhone. This works great on Mac, however on iOS i am running into codesigning problems.

I am using the following to codesign the dylib:

codesign -f -s *** --timestamp=none testlibrary-ios.dylib

I am placing the downloaded dylib in this folder: const char* cachedirectoryPath = [NSSearchPathForDirectoriesInDomains(NSCachesDirectory, NSUserDomainMask, YES)[0] UTF8String];

dlopen gives me the following error:

dlopen(/var/mobile/Containers/Data/Application/67A3D31B-6F72-4939-9E7F-665FC78CDC61/Library/Caches/testlibrary-ios.dylib, 0x000A): tried: '/usr/lib/system/introspection/testlibrary-ios.dylib' (no such file, not in dyld cache), '/var/mobile/Containers/Data/Application/67A3D31B-6F72-4939-9E7F-665FC78CDC61/Library/Caches/testlibrary-ios.dylib' (code signature invalid in <78A101AD-D756-3526-8754-8B7F4925DE90> '/private/var/mobile/Containers/Data/Application/67A3D31B-6F72-4939-9E7F-665FC78CDC61/Library/Caches/testlibrary-ios.dylib' (errno=1) sliceOffset=0x00000000, codeBlobOffset=0x0000C2E0, codeBlobSize=0x00004990), ....

Is loading a dylib like this on iPhones in development mode possible? Any idea what is going wrong with codesigning or installing the dylib?

(Obviously this code is never deployed in an app that goes on the AppStore)

Answered by DTS Engineer in 822718022
Is loading a dylib like this on iPhones in development mode possible?

No. While iOS does support dlopen, you can only open a library that’s either built in to the OS or embedded within your app.

While I appreciate your motivation here, I don’t think you’re going to make much progress on your current path. The iOS security model is actively trying to prevent you from doing exactly what you’re trying to do. And while Developer Mode punches holes in the firewall to allow development, those holes are tightly constrained to the requirements of Xcode.

Note that the above applies to native code. Your overall goal is quite feasible for interpreted code. And with tools like SwiftWasm, the line between the two is blurrier than ever.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

One curious thing I am seeing is that:

codesign -vv -d --verbose testlibrary-ios.dylib

outputs:

Executable=/Users/joe/sources/Curiosity/hotreload/cmake-build-debug/testlibrary-ios.dylib Identifier=testlibrary-ios Format=Mach-O thin (arm64) ...

It surprised me that my dylib has an Executable= with the path to the dylib. Is this expected and could it be related to my problem?

Is loading a dylib like this on iPhones in development mode possible?

No. While iOS does support dlopen, you can only open a library that’s either built in to the OS or embedded within your app.

While I appreciate your motivation here, I don’t think you’re going to make much progress on your current path. The iOS security model is actively trying to prevent you from doing exactly what you’re trying to do. And while Developer Mode punches holes in the firewall to allow development, those holes are tightly constrained to the requirements of Xcode.

Note that the above applies to native code. Your overall goal is quite feasible for interpreted code. And with tools like SwiftWasm, the line between the two is blurrier than ever.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn,

I can confirm that loading the dylib when it is copied into the app bundle works correctly, so it seems like it is not a codesigning issue but rather from where the dylib is loaded.

Interpreted code is unfortunately not an option because this is for rather high performance code. Wasm could be a possibility but as far as I can see there is no functionality in iOS to execute wasm code inside of an iOS app.

Can you give some more details on what holes in the firewall Xcode punches for development purposes. Maybe some of that could be used for a better dev workflow on iOS.

Also is this a new restriction in iOS? Do you know which version of iOS prevented doing this in developer mode iPhones?

dlopen on development iPhone codesign issue
 
 
Q