Do I understand correctly that when I distribute my KMP code as a prebuilt XCFramework, the iOS devs...

# ios

[Jan Skrasek]

Do I understand correctly that when I distribute my KMP code as a prebuilt XCFramework, the iOS devs cannot see the source code during debugging? Or can I bundle the sources to help them during debugging?

[kpgalligan]

This is true for any llvm binary build (I believe). Most iOS libraries are distributed as source, and built on the user's machine, but that is impractical for Kotlin frameworks.
However, although relatively complex, it's possible to debug binary builds. The first problem is that binary builds encode the absolute path of where the source file was when it was built. You'd need to provide a generic root path as an argument, then do some "magic" in a plist file to map that path to where the source is on the user's machine. Also, when we did this as a POC, we needed dynamic frameworks. For static, you'd need to figure out how to map the core binary.
So, possible, but it's not really a "standard" thing, AFAIK.
We had worked on a scheme to do this, but for all practical purposes, its easier to grab the source project, build locally, and debug that.

[Jan Skrasek]

thank you 👍

[Timofey Solonin]

Source mappings are indeed tricky to set up. There is the arcane plist approach, but there is also a slightly easier to use target.source-map setting in lldb.

Here is the general idea to make this work:
• Make sure the debugger picks up the DWARF from your Kotlin binaries. If you are shipping a static library the DWARF will be embedded in the library itself and if you are shipping a dynamic library it will be located in the dSYM bundle.
• Find the absolute paths embedded in DWARF
• Get the sources that were used to build the binary and map the paths using settings set target.source-map
Some other lldb settings that could some in handy are target.debug-file-search-paths and symbols.enable-external-lookup. You can look up the documentation for these using lldb's apropos command.