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?

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?

Hi Quinn, From my investigation it appears that this functionality (dlopen of a dylib outside of the app directory) used to work while running with xCode attached in developer builds on iOS 17. But it appears to no longer work in iOS 18. I see nothing in the release notes about this change. Can you please confirm if this has in fact changed from iOS 17 to iOS 18. And if it has if it was intentional and why? There are a couple of quite useful open source tools for runtime hotreload in the iOS ecosystem relying on this functionality. Inject sample & video Injection Next