Am I misunderstanding things or are there architec...

# swift-export

[Siggi Gunnarss]

Am I misunderstanding things or are there architectural issues with Swift export and distributing compiled Swift packages?

Will we need to switch to embedSwiftExportForXcode to use Swift export for the foreseeable future?

https://kotlinlang.slack.com/archives/C073GUW6WN9/p1750342126794569

https://youtrack.jetbrains.com/issue/KT-78747/Swift-export-for-SPM

[Guilherme Delgado]

I don’t know if I understood your question, but to use swift export, yes, you do have to change the project.pbxproj shellScript to use embedSwiftExportForXcode

[Guilherme Delgado]

after a successful build, you’ll find inside the module’s build folder all the SPM you have exported depending on you export configurations

[Guilherme Delgado]

(those SPM are auto imported in the xcode project, don’t need to do anything further)

[Siggi Gunnarss]

Thanks. To clarify, today we compile an XCFramework within the KMP project. Then we publish that to be consumed by the ios project. There's no direct integration via embendAndsignForXcode.

Is this library publishing approach not possible with swift export?

[Guilherme Delgado]

@Artem Olkov is the best person to answer, but with my understanding, embedAndSignAppleFrameworkForXcode and embendAndsignForXcode are not compatible. Thus, in theory, if you switch to embendAndsignForXcode the SPM export and import will be automatic (assuming you import via direct linking setup).
Be aware that depending on your code you may have situations where Swift Export is not yet supported (ex: coroutines). Also, any lib that you depend on, must also embendAndsignForXcode (ex: SKIE will not work since it’s create for objc/swift-interop)

[Guilherme Delgado]

If you export your SPM into a remote repo and then consume it in you xcode, I would say it’s the same, but without the spm generation configs step in the middle (gradle configs) since embendAndsignForXcode those that for you.

[Siggi Gunnarss]

We don't use embendAndsignForXcode today. We do not use direct linking. Does swift export require direct linking?

[Artem Olkov]

today we compile an XCFramework within the KMP project

That is currently an unsupported case. Swift Export at an experimental stage of a technology and currently it supports only direct source based integration.

there are architectural issues with Swift export and distributing compiled Swift packages

Would you mind elaborating? What architectural issues do you foresee?

[Artem Olkov]

Please vote for the ticket you have linked, maybe leave a comment with your use case 🙂

[Artem Olkov]

Also, just out of curiosity - why do you pack your kotlin into xcframework and not use it as source-based dependency on iOS side? Have you considered the move to the source based dependency?

[Siggi Gunnarss]

So direct linking is required right now, thanks.

My other question was if this was planned and simply not implemented yet, or if you saw some architectural issues with it and I should prepare for it to never be possible?

We use "Remote integration" https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-spm-export.html today.

I assume this setup was chosen because:
• It allowed us to keep our 2 repo structure
• Keep our current CI.
• iOS devs do not need to install jvm or learn anything new.
• CI on the iOS side does not have to compile KMP every time
I hope we can move to a source based setup in the future since it has many benefits. But it will be a big task, either going to a monorepo or some git submodule system.

The question of Swift export is relevant to this discussion. If Swift export not planned for Remote integration projects, that would be a strong indicator that source based dependencies are the preferred way from Jetbrains for example?

[Artem Olkov]

If Swift export not planned for Remote integration projects

We do not have specific plans for this right now. There are lot's of problems to solve with this approach. Currently the team is focused on the actual Swift Export as a technology, not the integration with different build tooling.

for it to never be possible

It is possible to do it, in theory, but we do not have this project on our roadmap for the nearest future.

that source based dependencies are the preferred way from Jetbrains for example?

Our documentation does not highlight any approach as preferred, all of them have their pros and cons and serve well in different teams and setups.

[Artem Olkov]

Our documentation does not highlight any approach as preferred

That said, with source based setup one would get
1. Swift Export
2. KMP plugin for IDEA
3. Ease of experimenting, as our project wizard would produce a project with the same setup
😉

[Marco Righini]

I could be wrong but with direct integration:
• we lose KMM SPM package remote caching mechanism
• the KMM framework will be visible to all the packages of a multimodule XCode project, breaking modularization and isolation

[Artem Olkov]

Well, as I said - pros and cons 🙂