Kotlin Multiplatform vs React Native: Which Cross-Platform Framework Should You Choose?
May 22, 2025
•8 minutes read
Picking a cross-platform framework is one of those decisions that sounds small until you commit to it. I’ve worked with React Native, native Android in Kotlin, and Kotlin Multiplatform (KMP). Each has trade-offs — here’s what I learned from using them in real projects.
TL;DR
- React Native: fast to prototype, huge ecosystem, works well for CRUD-style apps. Watch out for bridge-related performance issues.
- Native Kotlin: best performance and platform access, but you maintain separate codebases.
- Kotlin Multiplatform: share business logic, keep native UI. A good long-term balance if you can invest in platform expertise.
A short history of my journey
I started as a web developer, moved to React Native for speed, then spent time building native Android apps with Kotlin. KMP came later, and it changed how I think about sharing code across platforms: share what makes sense (logic, networking), keep UI native.
React Native — where it shines
Pros:
- Familiar if you come from the web (JavaScript, React paradigms).
- Rapid iteration with hot reload.
- Massive ecosystem — chances are someone already solved your problem.
Cons:
- The JavaScript-to-native bridge can cause hiccups, especially for heavy animations or CPU-bound work.
- Platform quirks still exist; you’ll write platform-specific code sometimes.
- App size and native module dependencies can be a headache.
When to pick RN:
- You need an MVP or fast prototype.
- The app is UI-simple and mainly CRUD.
- Your team is strong in JS/React.
Native Android with Kotlin — the performance option
Pros:
- Native performance with immediate access to platform APIs.
- Excellent tooling (Android Studio, profilers).
- Strong type safety reduces runtime bugs.
Cons:
- Separate iOS codebase if you need both platforms.
- Slower to iterate across two platforms.
When to choose native:
- Performance-critical apps (games, heavy media processing).
- Deep platform integration required.
Kotlin Multiplatform — share logic, keep UI native
KMP’s idea is straightforward: put networking, business rules, and data handling into shared Kotlin modules, and write UI in each platform’s native framework.
Pros:
- Native UI and native performance.
- Gradual adoption — share one module at a time.
- Better long-term maintainability for teams willing to own both platforms.
Cons:
- Smaller ecosystem than RN; sometimes you write glue code.
- Tooling and DX are improving, but there are rough edges.
- Requires knowledge of both platforms for UI work.
When KMP makes sense:
- Long-term projects where type safety and performance matter.
- Teams that can invest in native UI on each platform.
Performance & developer experience—my quick take
- Performance: Native ≈ KMP > RN for complex UI and heavy processing.
- DX: RN is fastest for small teams/productivity; KMP and Native are better for long-term robustness.
Small code examples
React Native (JS):
interface User {
id: string;
name: string;
email: string;
}
async function fetchUser(id: string): Promise<User> {
const res = await fetch(`/api/users/${id}`)
return res.json()
}
KMP (shared Kotlin):
@Serializable
data class User(val id: String, val name: String, val email: String)
class UserRepository {
suspend fun fetchUser(id: String): User =
httpClient.get("/api/users/$id").body()
}
Shared Kotlin code runs natively on each platform and keeps your business logic consistent.
Recommendation (practical)
- If you need to ship quickly and the app is simple: React Native.
- If you need native performance and deep platform features: native.
- If you want a long-term, maintainable solution with native UI: Kotlin Multiplatform.
Start small with KMP — share one module, measure the payoff, and expand if it helps. No silver bullet exists; pick the approach that matches your team’s strengths and product timeline.
What’s your current stack? If you tell me what you’re building, I can give a more specific suggestion.