it turns out that it's better to publish to two repositories with two different commands. Sharing code towards Kotlin build is supported but publishing to other build systems is challenging and can lead to problems (e.g. different versions might have runtimes incompatibilities, including GC) so it's only safe to do in a constrained environment. Thanks @Konstantin Tskhovrebov for your help!

if it works fine, I can check it as an option as well

But looking at what @David Nedrow said about jfrogs I'm definitelly interested as well.

I guess restated, I’ve only seen internal publishing use private github and a bucket to post the file. Our sample size is not huge, though, so Artifactory for cocoapods may be more common in some orgs.

We are currently doing something “weird” which is building a binary XCFramework zip if the Kotlin code changed, on CI, and pushing that to S3. On each PR merge. Not publishing it like a new version. It gets downloaded and run (basically) like a locally built framework, and you can still debug it, but the iOS dev doesn’t need to install/configure/run Kotlin tools unless they’re editing Kotlin. Some teams wanted to introduce Kotlin without adding a whole bunch of steps the iOS team might object to. Trying it out, anyway. We’re also publishing versioned pods to private repos, but again, not sure what the artifactory is doing in the middle, except hosting the zip?