Hi all! Is the xcode-kotlin plugin still active? I'm a little confused how it works.

# touchlab-tools

[Peter Hsu]

Hi all! Is the xcode-kotlin plugin still active? I'm a little confused how it works.

[Peter Hsu]

I'm building a framework and including that in my XCode project. I'm really unsure of how adding the source files separately to xcode will help me to debug

[Peter Hsu]

I'm also hesitant to try it out, as we have a highly modularized project, so it seems I would need to add the source files from each individual project

[kpgalligan]

Is the xcode-kotlin plugin still active?

Yes

[Landry Norris]

I’m currently using xcode-kotlin in a modularized project. You should be able to right click on the top folder and select ‘add files to <name>’ and select each module folder.

[Landry Norris]

XCode doesn’t do a good job of syncing changes that get created or deleted in IJ, though.

[kpgalligan]

I’m really unsure of how adding the source files separately to xcode will help me to debug

It’s not Kotlin or plugin specific. LLVM builds add absolute path info into the debug build. You need to add the files to Xcode to set breakpoints, but they do nothing else. You want to add them in a way that Xcode doesn’t think they should be bundled, btw

[kpgalligan]

as we have a highly modularized project, so it seems I would need to add the source files from each individual project

You need to add files for which you want to directly add breakpoints. If you “step into” some source, if lldb correctly follows the path, it’ll just open the file.
Now, when you say “highly modularized”, are you building all of the Kotlin on your machine, or pulling in pre-build frameworks that are assembled, say, on CI? The debug info for LLVM/DB uses absolute paths, so without some magic, you can’t debug code that was built somewhere else.

[kpgalligan]

Also, the “plugin” is really just connecting to lldb and some source highlighting. It does nothing scary or custom. All of this leverages standard lldb.

[Peter Hsu]

building all the kotlin on my machine, into a debug framework that gets added to the xcode project

[Peter Hsu]

highly modularized, as in about 30 different kotlin modules get bundled into this framework

[kpgalligan]

Yeah, so you’d need to add whatever Kotlin files you want to set breakpoints in.

[kpgalligan]

“Add” just means add the reference so you can open them in Xcode. I don’t mean add them so they get pulled into the build and output.

[Peter Hsu]

right

[Peter Hsu]

but could I add the top level android repository directory?

[Peter Hsu]

the example hinted at needing to only add the commonMain / iosMain directories

[Peter Hsu]

as in going through and selecting 60 different folders in my case

[kpgalligan]

I would think you could, again provided that you do it in a way that Xcode doesn’t just throw everything in as resources. I tend to add just Kotlin folders to keep finding the code simple, but there’s no reason you couldn’t just add everything.

[Peter Hsu]

ok that'd be easier as we often regenerate the project

[kpgalligan]

Yeah, I’d just do that then. I have done that before, but haven’t had 30 modules. Very curious what you’re working on, TBH

[Landry Norris]

I’d recommend adding whole modules (maybe deleting androidMain after), just to avoid having several folders named commonMain/iosMain. That made it difficult to find anything when I tried this.

[Peter Hsu]

thanks for the help (and the plugin)! I'll give it a shot and let you know if I see any issues

[Peter Hsu]

the high number of modules is an architectural decision - nothing really crazy.. clean architecture with a ui/data/domain split, with a module for interfaces and a module for implementations usually (to speed up build times), and also split across various domain functionality

[kpgalligan]

Ah, OK. Gradle to code ratio must be pretty high 🙂

[Peter Hsu]

definitely on the higher side 😄

[Paul Woitaschek]

In our experience for multiplatform, less modules = faster build time.
We went the opposite route and merged all modules into a single one.