Architecture challenge: compile-time KMP property discovery and a more Swift-native projection API

[sonmbol]

KMPObservableBridge already has a production-safe implementation for observing imported Kotlin state from SwiftUI. I would like to invite the Swift, SwiftUI, KMP, SKIE, and compiler-tooling communities to explore whether we can improve two parts of the developer experience without weakening the architecture that already exists.

Current production baseline

Today, observable fields are explicit and compiler checked:

@KMPObservable(
    ArticleViewModel.self,
    fields: \.articleState
)
extension ArticleViewModel: @retroactive KMPStaticallyObservable {}

SwiftUI keeps the original Kotlin ViewModel as the wrapped value, while its projected store exposes current Swift values and bindings:

article.retry()                 // Kotlin action
$article.articleState          // Projected current value
$article.searchText            // Binding for a writable export

This design already provides:

• no runtime reflection or Objective-C interception;
• compiler-checked key paths;
• Kotlin as the single source of truth;
• field-level Observation dependencies on supported platforms;
• correct legacy ObservableObject fallback;
• shared collection for macro-declared static plans;
• deterministic cancellation, rebinding, and ownership;
• no shadow Swift ViewModel or copied business state.

Any new approach should improve upon this baseline rather than move complexity into hidden runtime behavior.

---

Challenge 1: Discover imported observable properties at compile time

Tracking issue: #14

The ideal syntax would be:

@KMPObservable
extension ArticleViewModel: @retroactive KMPStaticallyObservable {}

The macro would discover supported exported state properties automatically.

The hard limitation is that Swift macros receive expansion syntax, but do not currently provide a general semantic API for enumerating every member of an imported Kotlin/Objective-C framework type.

Previously considered approaches include:

• macro-only imported-member discovery;
• freestanding and peer macros that generate external conformances;
• Objective-C selector/runtime discovery;
• Swift Mirror reflection;
• SwiftPM or Xcode source generators;
• hidden DerivedData metadata;
• Kotlin-generated descriptors;
• SKIE-specific compile-time metadata.

Runtime reflection, selectors, swizzling, and objc_msgSend are not acceptable solutions. A generator is technically possible, but must solve build ordering, stale metadata, sandboxing, incremental compilation, and consumer debugging without requiring generated files to be managed in Xcode.

What would a strong proposal explain?

1. How can a compile-time tool enumerate the members of an imported Kotlin type?
2. How does it classify read-only state, writable state, and event streams?
3. How is metadata invalidated when the KMP framework changes?
4. Does it preserve SKIE and NativeCoroutines product isolation?
5. Does it add Kotlin-side dependencies?
6. Does it introduce generated source, and where does that source live?
7. What happens in clean, incremental, archive, and CI builds?
8. Can it prove zero additional work in the per-emission hot path?

---

Challenge 2: Find a more Swift-native projection API

Tracking issue: #15

Some developers would prefer:

Text(article.articleState.title)

to return the projected Swift value directly.

However, article intentionally remains the original imported Kotlin ViewModel, and that type already owns the articleState property. A macro cannot redeclare that member with a different return type.

Likewise:

article.$articleState

would require articleState itself to be a Swift property-wrapper declaration. An imported Kotlin/SKIE property is not a Swift property wrapper, and $-prefixed projected members are compiler synthesized.

Changing the wrapper’s wrappedValue to a proxy could enable value forwarding, but Kotlin methods would no longer remain transparently available:

article.rawModel.retry()

That would break the existing concept that the wrapped value is the real Kotlin ViewModel.

Possible directions include:

$article.state.articleState
$article.binding.searchText

or:

$article.articleState
$article.binding.searchText

or a local named projection:

let state = $article
Text(state.articleState.title)

Macro-generated sibling projections are also possible to investigate, but they introduce hidden identifiers, naming collisions, access-control questions, and code-search complexity.

What would a strong proposal explain?

1. Does article remain the original Kotlin ViewModel?
2. Do Kotlin actions remain article.retry()?
3. How are read-only values visually distinguished from writable Binding values?
4. How does the read register against the correct SwiftUI wrapper identity?
5. Does the design preserve field-level Observation dependencies?
6. Does it allocate a new proxy or namespace during body evaluation?
7. How does it affect rebinding, cancellation, and ARC/Kotlin GC lifetime?
8. Can existing 1.1 source remain compatible?

---

Evaluation criteria for both proposals

Please compare suggestions against the current implementation in these areas:

• SwiftUI View Graph invalidations;
• property-level dependency precision;
• collector and subscription counts;
• heap allocations and object lifetime;
• actor crossings and unstructured tasks;
• deterministic cancellation;
• rebinding and stale-emission protection;
• ARC/Kotlin GC cross-boundary references;
• compiler diagnostics and type safety;
• clean and incremental build behavior;
• source compatibility;
• autocomplete and discoverability;
• behavior across Swift 5.9 through Swift 6.2.

A prototype, macro expansion example, compiler reference, or benchmark is especially valuable.

The objective is not to discard the current solution. It is to discover whether the community can produce an approach that is simpler for consumers and at least as safe, precise, and efficient as the implementation already shipped.

I would love to hear ideas from Swift macro authors, SwiftUI engineers, Kotlin/Native specialists, SKIE users, KMP-NativeCoroutines users, and teams operating KMP applications at scale.