Summary
The cross-language bridging layer (README → "Mixed iOS / React Native / Expo bridging") covers Swift↔ObjC auto-bridging, the React Native legacy bridge, TurboModules, RN event channels, Expo Modules, and Fabric/Paper views — but not Kotlin Multiplatform: the Kotlin → generated ObjC framework → Swift seam that every KMP mobile monorepo lives on. On such a repo, a shared Kotlin symbol's callers/impact never include its Swift consumers, so blast-radius answers on exactly the symbols both platforms depend on are silently incomplete.
Repo shape
A typical KMP monorepo: shared/src/commonMain/kotlin/** compiled into an Apple framework (via the Kotlin/Native ObjC export), consumed from iosApp/**/*.swift as import SharedKit. Both sides are already indexed individually — Kotlin edges resolve well, Swift symbols/files resolve — but no edge crosses the boundary in either direction.
Why this looks feasible in the existing architecture
The bridge channels already synthesize edges from mechanical naming rules and tag them provenance:'heuristic' with metadata.synthesizedBy. Kotlin/Native's ObjC export rules are similarly mechanical, and the Swift→ObjC prepositional rules you already implement do half the work once the Kotlin→ObjC name is derived:
- Class/interface/object names surface with the framework or
@ObjC* name; top-level functions attach to a <FileName>Kt facade class.
@ObjcName / @ObjCName and @HidesFromObjC annotations override or remove exposure — parseable from the Kotlin source, same as you verify @objc exposure on the Swift↔ObjC channel.suspend fun foo(bar: T) exports as a completionHandler: method — a deterministic transform of the Kotlin signature.- Interop-invisible constructs (sealed hierarchy details, default args expanding to overload sets) can simply not emit candidates — a bridge that only claims the mechanical subset is still a large win over no edges.
A kmp-objc-bridge channel emitting the Kotlin-symbol → derived-ObjC-selector candidates, then reusing the existing ObjC→Swift reverse-bridge matching, would connect the seam for the common cases.
Impact / motivation
The failure mode is the dangerous kind: an agent asked "is this shared Kotlin symbol safe to delete" gets a confident, wrong "no callers" because the only callers are Swift (we have hit exactly this, via a renamed Swift binding, before adopting codegraph). We currently mitigate procedurally (repo guidance: treat the KMP boundary as invisible; cross-language name search before any unused/impact conclusion), but the graph is the right place for these edges, and issue #765's point about explore/edge reliability on multi-language repos applies doubly when a whole language boundary has no channel.
Happy to test a build against a real ~2,200-file KMP monorepo (Kotlin + Swift + generated framework) and report resolution rates if that helps.
Summary
The cross-language bridging layer (README → "Mixed iOS / React Native / Expo bridging") covers Swift↔ObjC auto-bridging, the React Native legacy bridge, TurboModules, RN event channels, Expo Modules, and Fabric/Paper views — but not Kotlin Multiplatform: the Kotlin → generated ObjC framework → Swift seam that every KMP mobile monorepo lives on. On such a repo, a shared Kotlin symbol's callers/impact never include its Swift consumers, so blast-radius answers on exactly the symbols both platforms depend on are silently incomplete.
Repo shape
A typical KMP monorepo:
shared/src/commonMain/kotlin/**compiled into an Apple framework (via the Kotlin/Native ObjC export), consumed fromiosApp/**/*.swiftasimport SharedKit. Both sides are already indexed individually — Kotlin edges resolve well, Swift symbols/files resolve — but no edge crosses the boundary in either direction.Why this looks feasible in the existing architecture
The bridge channels already synthesize edges from mechanical naming rules and tag them
provenance:'heuristic'withmetadata.synthesizedBy. Kotlin/Native's ObjC export rules are similarly mechanical, and the Swift→ObjC prepositional rules you already implement do half the work once the Kotlin→ObjC name is derived:@ObjC*name; top-level functions attach to a<FileName>Ktfacade class.@ObjcName/@ObjCNameand@HidesFromObjCannotations override or remove exposure — parseable from the Kotlin source, same as you verify@objcexposure on the Swift↔ObjC channel.suspend fun foo(bar: T)exports as acompletionHandler:method — a deterministic transform of the Kotlin signature.A
kmp-objc-bridgechannel emitting the Kotlin-symbol → derived-ObjC-selector candidates, then reusing the existing ObjC→Swift reverse-bridge matching, would connect the seam for the common cases.Impact / motivation
The failure mode is the dangerous kind: an agent asked "is this shared Kotlin symbol safe to delete" gets a confident, wrong "no callers" because the only callers are Swift (we have hit exactly this, via a renamed Swift binding, before adopting codegraph). We currently mitigate procedurally (repo guidance: treat the KMP boundary as invisible; cross-language name search before any unused/impact conclusion), but the graph is the right place for these edges, and issue #765's point about explore/edge reliability on multi-language repos applies doubly when a whole language boundary has no channel.
Happy to test a build against a real ~2,200-file KMP monorepo (Kotlin + Swift + generated framework) and report resolution rates if that helps.