I'm publishing a XCFramework that I create from Ko...

# multiplatform

[mkrussel]

I'm publishing a XCFramework that I create from Kotlin. There are several cases of functions and classes that are useful from using from Kotlin but not from Swift or Objective-C. Are there any compiler plugins that will strip classes/functions from the header file created for the frameworks. I still want the symbols there since they are likely used internally by the library, I just don't want them to be part of my public API.

If there is not a plugin out there, any help finding information about creating a plugin that changes the header that gets created would be appreciated.

[kpgalligan]

I’ve thought about this quite a bit. Short answer right now, no plugins. The problem is worse than just the header, though. Anything exposed to the iOS framework may increase the binary size because an objc adapter needs to be added by the compiler, which can add up.

[kpgalligan]

Structurally, you can make things internal (if possible). IN a lot of cases, that’ll trim the interface and binary. If that doesn’t work, have a “Kotlin platform” sourceset above “common”, and put those classes/functions there, so the iOS side simply won’t see them.

[kpgalligan]

We tried making a plugin a while ago that would make some things internal, just for the iOS build (if possible), but at the time we couldn’t change visibility with the plugin, so that stalled. I’ve thought about making some kind of compiler extension that would impact the header generation, but I would not expect the native team would want that, so I think for the near term if you wanted to touch the header, it would need to be some kind of plugin. The good news is modifying the header itself shouldn’t be too bad. We’ve thought about that to modify the Swift names, etc. No efforts yet, though.

[mkrussel]

Some of the stuff is things I need to be public so that classes in other modules can access them but not code outside the library suite. They're annotated with an OptIn but that gets lost.

Also some protected methods (if all the children are in the same module).

I'm not sure the higher level source set would work, because I still want to be able to call them from my common and iOS source sets, just not export them out.

[kpgalligan]

Yeah, there’s no way that I know of to do that now. I’d like to suppress the suspend functions from being exported because we use our own reactive adapters for that, but haven’t gotten around to advocating for some way to control that stuff. Similar problem (I want kotlin code to see them, but I don’t want to have them in the iOS header). Anyway, it’s a hard problem. I don’t have easy answers, but I understand your pain 🙂

[mkrussel]

The suspend functions were some of what I wanted to get rid of, since I already provide a solution for Java and iOS apps.

[kpgalligan]

I’d like to push for a flag to just skip generating them. They used to not get added.

[Paul Woitaschek]

Hmm what about making them internal in commonMain, adding an @JvmExpose and using KSP to generate proxies in androidMain?

[mkrussel]

A flag for that, and one for some of the data class functions. copy and the componentX functions are not that useful from Objective-C.

[mkrussel]

Many of them I still need to access from commonMain inside other modules.