Sharing logic, native UI across platforms

WHAT THIS TESTS The interviewer wants the architectural instinct to draw the reuse boundary at logic, not pixels. Sharing too much (the UI) sacrifices native feel; sharing too little duplicates rules.

A GOOD ANSWER COVERS Factor the component into two layers. A shared core holds the business logic and state, such as the favorite toggle, validation, and any networking, expressed in a platform-neutral way. Kotlin Multiplatform is a natural fit, compiling shared Kotlin to a library consumable by JVM/Android, native iOS, and JS/web; the shared layer exposes a presenter or observable state plus intents. Each platform then builds its own fully native UI on top: SwiftUI on iOS, Jetpack Compose on Android, and a React component for web, each binding to the shared state and dispatching intents. The contract between layers is data and actions, never UI widgets, so each platform renders idiomatically while the rules live in one place.

COMMON WRONG ANSWERS Sharing the UI layer (for example React Native everywhere) to maximize reuse, which violates the fully native requirement. Duplicating the favorite logic in all three codebases, risking divergence. Leaking platform UI types across the shared boundary.

LIKELY FOLLOW-UPS How do you expose shared state to SwiftUI versus Compose idiomatically? What are the build and tooling costs of Kotlin Multiplatform? How do you test the shared logic once for all platforms?

ONE CONCRETE EXAMPLE A shared CardViewModel in Kotlin Multiplatform exposes an isFavorite state flow and a toggleFavorite() intent. The iOS app wraps it in an ObservableObject and renders SwiftUI; Android collects the flow in a Composable; web binds it in a React hook. All three call the same toggle logic, so a rule change to favoriting ships once, while each platform keeps a genuinely native look and feel.