@DaveR - The inability to use dynamically linked code in the iOS App Store is a technological limitation, with legal limitations (in regard to the LGPL) only as a side effect.
The way the App Store DRM works, your copy of any particular app, sold/assigned to your AppleID, has a chunk of the executable encrypted in a method related to your AppleID.
If you attempted to modify an App Store app's executable (somehow) after it was downloaded and installed on your non-jailbroken device, the signature of the app would change and decryption would fail - resulting in the modified app refusing to run. As a result, this cryptographic signing serves as a guarantee of sorts that says: "This app, as it was written when submitted to us, has been approved as SAFE". Tampering with the app invalidates the signature and denies execution.
Since a dynamically linked library makes it very trivial to have parts of your app that you can "swap out" with updated/alternate versions (a main requirement of the LGPL), it just turns into an even larger security headache for Apple's choice of DRM. Either they have to sign every little dynamic library in your app as well - or they can go the route they did and ban it altogether.
You cannot create dynamically linked iOS apps without patching the linker. If you do make one and submit it to Apple, it will be denied for publication on the App Store. In addition, any attempt to trigger a dynamic library load for anything other than iOS-provided system libraries will cause your app to immediately self-terminate.
omz can't do any .so / .dylib loading for you, folks - PERIOD. And yes, I mean ctypes and all the rest. So stop asking!
The Android ecosystem is a different beast entirely. Since the UI application layer is Dalvik (basically a Java VM), an app doesn't get any hardcore speed unless it links in native code libraries via NDK. Since Dalvik/Java bytecode and native ARM code are two separate beasts, by their very nature they're in separate pieces of the application (wrapped up in an apk bundle, but still separate files inside).
http://developer.android.com/tools/sdk/ndk/index.html
So instead of banning it, they embraced it and did their DRM / licensing in a different fashion. As a result, linked libraries DO exist in the Android realm.
As I don't do Android dev for a living, I can't tell you if "let users load their own .so files" -style applications exist, however.
TL;DR: Please stop bugging omz about including third-party modules, unless they have very small native code components and are liberally (MIT, etc.) licensed. He just can't do it, folks.