Reviving this because the answer here, that iOS is incompatible with the LGPL because the build is static, was true in 2017 but may no longer be. Qt 6.10.3 can be built for iOS as dynamic frameworks, and we have a working prototype of a closed-source app with Qt linked dynamically: it runs on the arm64 simulator and links for devices. That's the same shared-library route the original question asked about.
In short:
configure -shared -xplatform macx-ios-clang works in 6.10.3 (6.3.2 still refused it). Core, Gui, Widgets, Xml and Svg come out as @rpath frameworks.
The one part Qt still forces static is the iOS platform plugin, qios, because it calls the app's main(). Our Qt code draws nothing, so it runs on the minimal platform plugin instead.
The App Store rejects loose dylibs, and Qt only looks for plugins as loose files. So the two plugins we need are relinked as framework dylibs and registered with qRegisterStaticPluginFunction after dlopen. The app ends up with only frameworks, and no Qt code in its own binary.
Since App Store copies are signed and encrypted, users would get an unsigned .app per release in which to replace Qt and re-sign.
@sierdzio , or anyone from The Qt Company reading this: does the "iOS is incompatible with LGPL because it's static" position still hold now that a shared build is possible? And has anyone shipped an App Store app this way, and did validation accept Qt as embedded frameworks?