Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

feat(bridge): Kotlin Multiplatform channel — Kotlin → generated ObjC framework → Swift edges

Aperta
  • Qualcosa non va?
#1,676 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
kotlin, objective-c, swift
Ambito
devtools

Direzione di ricerca

Start by reading the README section “Mixed iOS / React Native / Expo bridging” and the existing bridge-channel implementations that synthesize heuristic edges. Trace how those channels derive names, attach provenance and metadata, and match ObjC to Swift. Done means common Kotlin/Native exports can connect Kotlin symbols through derived ObjC selectors to Swift consumers, while unsupported or hidden constructs do not produce candidates.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
73.2k
Fork
4.7k
Merge medio
11h 28m
PR unite (30g)
596

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di colbymchenry/codegraph

Tutte le issue di colbymchenry/codegraph

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.