Presumably your closed-source library has an API that you can document. This is how I handle some hardware-access DLLs for proprietary hardware; the distribution gives you the full source for the main program and the non-proprietary hardware access modules, plus the .DLL with the secret sauce for my own hardware. When you run the app, it loads all of the API-compliant DLLs and adds them to the device-selection menu. Anyone can build their own .DLL with the header files provided, or recompile the existing "open" ones if desired.

For an iOS project, you'd provide a link to the GitHub/Sourceforge page or whatever. It's true that the end user would have to get a signing key from Apple to exercise their rights under the LGPL, but IMHO that still meets the spirit of the law. As far as I'm concerned my obligation ends when I provide the code. Some will disagree (hence GPLv3), but the same problem would exist if I had used a language (or targeted a platform) for which there were no free compilers, and nobody seems to have a problem there.

Previous discussion on HN of the mail app Sparrow and their approach in complying with LGPL on iOS:

https://news.ycombinator.com/item?id=4302517

May be helpful to you.

Its not helpful, they aren't complying with the relinking clause. I don't think there's any way to use LGPL with closed source on mobile app stores.

I'm assuming you didn't read it. I will give you benefit of the doubt since the Sparrow page was pulled after Google acquired them.

Sparrow made available on a website the necessary binaries for the user to relink if they so chose thus complying with the terms of LGPL.