You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(shared-core): wrap the framework in a Swift target (#1297)
* fix(ed25519): embed the C library into the cinterop klib
`binaries.linkerOpts` only reaches the binaries this module itself produces, so
the ed25519 objects never travelled into a downstream framework -- the shared-core
XCFramework exported `_ed25519_sign`/`_ed25519_verify` as undefined and left every
consumer to supply them. The iOS app happens to compile the same C reference
implementation, which is why nothing had failed yet; a standalone SPM consumer
fails to link.
`-staticLibrary`/`-libraryPath` on the cinterop puts the archive in the klib, so
anything built from it carries the symbols.
* feat(shared-core): wrap the framework in a Swift target
The Kotlin/Native ObjC surface is not something an app should have to hold: byte
payloads arrive as `KotlinByteArray`, objects come through `.shared`, and default
arguments don't survive the export at all. Adding a `SharedCoreKit` Swift target
over the binary framework moves that translation into the package -- iOS calls
`KikCode.svg(payload:)` with `Data` and named defaults, and the framework itself
is no longer a product.
The Swift sources live here rather than in the Swift Package repo so the glue and
the Kotlin it wraps move in one commit; the publish job copies them across, which
also means `Package.swift` is ours now (KMMBridge rewrites only its variables
block). The job builds the staged package against the framework it just uploaded
before moving the tag, so a mismatch between the two can't reach a consumer.
0 commit comments