I asked Claude to update PeopleInSpace sample to u...

# swift-export

[John O'Reilly]

I asked Claude to update PeopleInSpace sample to use Swift Export instead of SKIE.....it got pretty far but ran in to some issues. More details in github.com/joreilly/PeopleInSpace/pull/524. I'll keep digging...

[John O'Reilly]

ok, result of further investigation in comments in that PR....seems to be issue with probably known issues around use of generics

[John O'Reilly]

trying to limit what's exposed to see if it makes a difference

[Sam Rayner]

FWIW I did a similar exercise and found this to be the ultimate blocker. Everything else could be worked around.

https://youtrack.jetbrains.com/issue/KT-85981/Swift-Export-generic-property-with-specified-type-generates-uncompilable-bridges

With ObjC export all generics were treated as id, relaxing constraints at the boundary but allowing upcast at runtime. With Swift Export it's all compile time so couldn't find a way around 🙁

[John O'Reilly]

some progress with Kotlin 2.5.0-Beta1....this is summary from Claude

Fixed in 2.5.0-Beta1:
- ViewModel vtable crash: gone. Kotlin compiles and Swift Export generates the Swift code.
- Duplicate @_spi stubs from kotlinx-serialization (KT-87791): fixed. I disabled the build-file workaround and the only errors left came from the Koin duplicates below. I cut the workaround down to that one part.

Still broken:
- Koin Module.module() stubs: still emitted as duplicate unavailable declarations (3 × invalid redeclaration of 'module'), so the reduced workaround stays.
- Runtime crash on the ISS Position tab: passing the Swift factory into Kotlin throws ClassCastException: iOSNativeViewFactory cannot be cast to dev.johnoreilly.common.ui.NativeViewFactory. Changing the parameter to the class type fails the same way, so the Kotlin object behind a Swift subclass doesn't know its Kotlin supertypes. The 2.5.0-Beta1 changelog lists KT-88042, a ClassCastException when Kotlin calls an interface method on a Swift subclass, as fixed. This case isn't covered by that fix, and it's the new blocker;

[John O'Reilly]

also btw get different issues if I switch to new swiftexport build config

┌──────────────────────────────────┬──────────────────┬─────────────────────────────────────────────────────────────────────────┐
│                                  │ swiftExport { }  │                          export { swift { } }                           │
├──────────────────────────────────┼──────────────────┼─────────────────────────────────────────────────────────────────────────┤
│ Kotlin modules exported to Swift │ 7                │ 13 (adds Kermit, Stately, Koin annotations, Koin ViewModel, SavedState) │
├──────────────────────────────────┼──────────────────┼─────────────────────────────────────────────────────────────────────────┤
│ Generated Swift                  │ about 6.7k lines │ about 29k lines                                                         │
├──────────────────────────────────┼──────────────────┼─────────────────────────────────────────────────────────────────────────┤
│ Xcode build                      │ succeeds         │ fails                                                                   │
└──────────────────────────────────┴──────────────────┴─────────────────────────────────────────────────────────────────────────┘

The failures are in generated code that the old DSL never produced. In the generated stdlib, an unqualified Int(...) now resolves to the exported <http://kotlin.Int|kotlin.Int>, and the ViewModel module has subscript override errors. The new DSL only offers moduleName, rootPackage and xcodeIntegration(), so there's no way to narrow what it exports.

[Artem Olkov]

Hello there 🙂 Thanks for the report! I'm happy to report that we have fixed everything in this thread for Beta2. It should be already be merged as of yesterday, and I hope that earliest Beta2 builds would become available this week.

Thanks again for the report, we have missed those bugs and are very happy to fix them 🙂

[Artem Olkov]

Well, everything, exccept for youtrack.jetbrains.com/issue/KT-85981/Swift-Export-generic-property-with-specified-type-generates-uncompilable-bridges - this will require the whole implementation of Generics support 🙂

[Artem Olkov]

>

The new DSL only offers moduleName, rootPackage and xcodeIntegration(), so there's no way to narrow what it exports

That's actually was a half backed feature in Beta1, and in Beta2 one would be able to hide a dependency fully from the export like this

xcodeIntegration{
        configure(projects.subproject) {
        visibility = SwiftExportVisibility.HIDDEN
        moduleName = "Subproject"
        rootPackage = "com.github.jetbrains.library"
    }
}

[Artem Olkov]

And for Full or Transitive export we now rely on api/implementation info on the exported module, so no more duplication of dependencies between dependency block and export block 🙂

[John O'Reilly]

@Artem Olkov tried Beta2 dev build and looking very good. Following branch updated (and PR comment added with findings....thanks to Claude 😃 ) github.com/joreilly/PeopleInSpace/pull/524

[John O'Reilly]

this branch is also based on having a new ios-export module....I asked Claude to see if we could go back to consuming common from iOS and ran in to a few issues (it added comments for what it tried to PR in case useful)

[John O'Reilly]

in general if there are any things you think should be changed in the project when using Swift Export then of course am very happy to incorporate

[John O'Reilly]

also wrote small article on changes made....again if anything doesn't look right I can update johnoreilly.dev/posts/peopleinspace-swift-export

[Artem Olkov]

also wrote small article on changes made....again if anything doesn't look right I can update johnoreilly.dev/posts/peopleinspace-swift-export

Oh that's great! I will ping you with some links with official docs and other stuff as soon as we are ready with them, so that you can update the article, if that alright with you 🙂 This will happen somewhere close to the actual release of 2.5.0

[Artem Olkov]

this branch is also based on having a new ios-export module....I asked Claude to see if we could go back to consuming common from iOS and ran in to a few issues (it added comments for what it tried to PR in case useful)

Yeah, I've tried to read all the comments in that PR, but it's a lot of words, I will have another go at it after my vacation 🙂

One thing that stand out - your Claude (at least in the first comments there) is unaware of the fact that it can @HiddenFromObjectiveC any user defined declaration to hide it. I saw a lot of complaint that it cannot mark something as internal, because it's needed for other targets.

[Artem Olkov]

Oh and by the way thanks A LOT for your article with benchmark of Swift Export. Because of that we have already found and fixed a quirk of our kotlin code generation, reducing compilation of kotlin bridges almost by 2.5 times(that is already in the Beta2 branch), and we are working on improving the caching altogether. I cannot promise we will be able to cherry pick other improvements to the 2.5.0 release, but even if not - 2.5.20 will be much faster thanks to you and your work.

[John O'Reilly]

Nice!