Sharing logic, native UI across platforms
separating shared logic from native UI.
shared module (e.g. Kotlin Multiplatform) for state/business rules, platform-native UI consuming it, and a clean interface boundary.
forcing shared UI and losing native feel.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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?
A 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.
Interview question
Where should the reuse boundary sit for a cross-platform component that needs native UI but shared logic?
- a.Expose platform UI widget types across the shared module boundary
- b.Share the business logic and state; build the UI natively per platform against that contractCorrect
- c.Share a single UI layer and generate platform logic separately
- d.Duplicate both logic and UI per platform for full independence
Why? this is the answer
Sharing logic via a module like Kotlin Multiplatform keeps rules in one place while SwiftUI, Compose, and React render natively. Sharing UI breaks the native requirement, duplicating logic invites drift, and leaking widget types couples the layers.
Just read this? Test yourself on what you have been reading.
Read the original → kotlinlang.org
- #design-systems
- #cross-platform
- #kotlin-multiplatform
- #architecture
- #native-ui
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on design-systems — each one lists the topics its interview covers.
See open roles