Hello :wave:, I’ve recently been exploring the ne...
# swift-export
g
Hello 👋, I’ve recently been exploring the new Swift Export feature and created a small sample module with a foo class and a bar function. While reviewing the generated Swift Export code, I noticed that it seems to be essentially the Objective-C output wrapped with Swift code. Could you clarify if that’s actually the case, or if Kotlin code is being directly converted into Swift syntax? I also have a couple of related questions: 1. Do you have an estimated timeline for when this feature will become stable? At the moment, configuration feels quite complex, and from what I’ve read, each opt module needs to be exported separately. 2. In my sample, the module contains Compose code, and I encountered errors regarding mismatched input names (along with a few other related issues). Thanks in advance for your clarification and guidance!
a
Hello there! Thanks for your questions 🙂 > it seems to be essentially the Objective-C output wrapped with Swift code I'm not sure I understand what do you mean. Can you please clarify? > Do you have an estimated timeline for when this feature will become stable? We do not have a public timeline for the stability of the feature. > At the moment, configuration feels quite complex Can you please share a more detailed feedback? What part was complex? What was not obvious? > from what I’ve read, each opt module needs to be exported separately. I'm not sure what do you mean. Can you please provide a link to the documentation that we are talking about? And what resulted configuration did you build? > I encountered errors regarding mismatched input names Please provide a code sample, as I did not understand what do you mean.
g
Answer to Q1: What I meant is: when Kotlin generates Objective-C headers, did you wrap those Objective-C APIs with Swift-friendly code so that the consumer interacts with them using Swift syntax? Or did you completely drop Objective-C headers and directly generate Swift code from Kotlin? Answer to Q3 (configuration complexity): By complexity I meant the Gradle configuration — we have to explicitly declare which modules should be exported, and which opt-in modules require additional compiler options. This makes the setup a bit harder to follow. Regarding the last point (mismatched input names): The issue I faced is the one described here: KT-80185: KMP: wrong input name mapping
a
1. No, if you are asking if swift export is a wrapper for current objective-c export - than no, it is not. Swift export is a new technology. We were able to reuse some parts of Objective-C export, for example the garbage collection mechanism is the same, but not very much beyond that. 2.
we have to explicitly declare which modules should be exported
- yes, it's the same as it was before. There is a transitive export - meaning that leaked declarations would be automatically pulled into the "public api surface". But otherwise - how would you want it? Please keep in mind, that the bigger exported API, the less we are able to remove at the "dead code elimination" step, the bigger is the final binary. 3.
which opt-in modules require additional compiler options
that part of configuration did not change and does not relate to swift export. It was always there. 4. mismatched input names - oh yes, that was a bug, it is already fixed. It is available either in dev builds, or it would be available in 2.3.0 Regarding 1 - feel free to watch

my talk from kotlinconf

, it provides a nice overview of things under the hood 🙂
K 1