but Spotlight never indexes DerivedData because there is a .noindex directory inside
The only non-index (.noindex) folder inside the DerivedData folder is the folder with intermediate files - Intermediates.noindex.
My final path to the application is - /Users/username/DD/DebugProblemApp-fucfslzxpotphfeaohzvxfbkkvkh/Build/Products/Debug-iphonesimulator/DebugProblemApp.app ( Custom DerivedData path )
LLDB will only find the .dSYM in the DerivedData folder when it's directly next to the executable/dylib
Yes, I know about these two methods. Just thought that in my example dSYM is located next to the executable file (next to the framework). But apparently it is not.
Where should I put .dSYM so that it will be automatically found and loaded?
I tried to put it inside the application in the Framework folder (next to the framework), but that didn't work either.
May I ask what it is that you are actually trying to achieve?
From your steps it sounds like you might be testing whether your app is debuggable after moving it to a different machine, but there are lots of other reasons (Clang modules mostly) why this won't necessarily work at this point in time.
Sure.
Almost so. I'm trying to achieve reuse and debugging of the framework builded on another machine.
The difference is that only dynamic frameworks are reused, the application itself is always builded only locally.
In the end, the idea is similar to this article - Attaching sources to iOS/macOS binaries compiled on another machine. I am developing a solution that will be built into the project from the developers and, during the build process, download the dynamic frameworks builded on the remote machine and link them to the application and to another local builded frameworks.
As far as I know this is possible. I did some research and the only problem is the problem from this topic.
I also based on several articles and documents:
Symbols on macOS
Attaching sources to iOS/macOS binaries compiled on another machine
Support -fdebug-compilation-dir - alternative way
Improving swift-lldb support for Path Remappings
I also know that a similar problem has already been solved in other build systems: facebook/buck and bazelbuild/bazel. But as far as I know, completely different approaches are used there (including patching the paths to the sources in the binary)
@Adrian_Prantl I would be very grateful if I could suggest how to bring the current solution to a working state or an alternative solution that will work.