As you've correctly understood, the intent of the LGPL is that all recipients can modify and replace the LGPL-covered parts of the software. This typically either means linking the LGPL components dynamically, or providing object files or source code for your software so that recipients can re-link or re-compile your software with their modified LGPL components.
Your scenario seems slightly more complex because you only have an indirect dependency on the LGPL component via a library that is otherwise MIT-licensed. But instead of calling this
a MIT library that contains a statically linked LGPL2.1 library
it would probably be better to view this as
a library that statically links MIT-covered and LGPL-2.1-covered components.
From the viewpoint of your entire application, you should effectively treat this entire library as LGPL-2.1 covered. Your idea to use dynamic linking to make it possible for the recipient to replace the entire library (including the MIT components) is therefore appropriate.
From a viewpoint within this library that statically links the different components, you are only required to make it possible for the recipient to replace the LGPL-covered parts. However, given that the other parts are already Open Source as well, there doesn't seem to be any downside in providing the source code for the entire library and letting the recipient replace it entirely. This will likely be the simplest solution to achieve compliance, and will not raise additional security issues compared to just letting recipients replace the LGPL-covered parts.
The second part of your question asks about how to let the user provide their modified library. The LGPL is technology neutral and does not prescribe a particular mechanism – any way that lets the recipient exercise their rights is fine.
But I am not familiar with macOS development, and would expect your solutions to have different security implications. For example, loading executable code from a directory that is writeable by other processes would be a simple attack vector for malware. In contrast, modifying an .app might be impossible if there are write-protections, checksums, or app signatures involved. I am mentioning these concerns because your goal is not just to create software legally, but also to make it comply with the Apple App Store conditions (which are out of scope here). Without further constraints, I'd probably suggest that users directly modify the .app bundle as this seems conceptually simplest.