In my previous article, I shared how I built a cross-platform AI chat app using Kotlin Multiplatform (KMP) and Cursor:
👉 Building a Cross-Platform AI Chat App with Cursor + Kotlin Multiplatform
The benefits were obvious:
- ✅ One project
- ✅ Two platforms
- ✅ Shared logic
- ✅ Faster iteration
It looked like the perfect setup.
But when I started building OnlyBaby with AI tools, I made a surprising decision:
I didn’t use KMP for the whole app.
This wasn’t ideological. It was practical.
Here’s what happened — and what it taught me about app development in the AI era.
The Promise of Kotlin Multiplatform
The Appeal Is Real
KMP offers something every developer dreams of:
- Write once, run on iOS and Android
- Share business logic
- Reduce duplication
- Maintain consistency
- Ship faster
When building a cross-platform AI chat app, it worked beautifully.
But real-world product requirements are rarely “beautifully symmetric.”
Where Reality Started to Hurt
When building OnlyBaby, I ran into practical friction — not theoretical limitations, but development pain in real scenarios.
Let’s break them down.
1️⃣ Compromising on Libraries
When you choose KMP, you also choose:
- KMP-compatible networking libraries
- KMP-compatible persistence libraries
- KMP-compatible architecture constraints
That means:
- You can’t always use the best native tools.
- You must adapt to what KMP supports well.
- You sometimes sacrifice platform-optimized APIs.
In theory, this is fine.
In practice? It feels restrictive.
Especially when:
- iOS has great native persistence tools
- Android has its own powerful ecosystem
- Platform SDKs evolve faster than KMP adapters
2️⃣ I Wanted Native-First UI Experiences
This was a big one.
I didn’t want a “lowest common denominator” UI.
I wanted:
- iOS-specific design patterns
- Advanced visual effects (like future iOS “liquid glass” styles)
- Native animation behaviors
- Platform-specific UX nuances
And on Android:
- Material-native experiences
- Platform-consistent transitions
- Native component behavior
KMP shines at shared logic.
But UI is where identity lives.
And I didn’t want to compromise that.
3️⃣ iOS-Specific Features Matter More Than You Think
OnlyBaby needed deeper integration with Apple’s ecosystem:
- 📱 Live Activities
- 🏠 Home Widgets
- ⌚ Apple Watch support
These are not “nice-to-haves.”
They’re product-level features.
The deeper I went into iOS system integration, the more friction appeared.
4️⃣ The App Group Nightmare
This is where things broke down.
To share persistence data between:
- The main iOS app
- Home widgets
I needed to use App Groups.
That’s normal in native iOS development.
But:
- The KMP persistence libraries couldn’t support it properly.
- Bridging layers became fragile.
- AI agents tried to fix it.
And here’s the painful part:
Even with Cursor, Codex, and Antigravity… it failed.
The Endless AI Loop
The AI agents did what they’re good at:
- Rebuild the project
- Analyze compiler errors
- Attempt fixes
- Retry
- Retry
- Retry
But instead of solving it:
- It entered an endless resolution loop.
- It consumed a huge number of tokens.
- It still complained about errors.
At that moment, I realized something important.
The Real Question: Why Am I Still Compromising?
AI agents have changed development completely.
With tools like, Cursor, Codex, Antigravity
I can:
- Generate architecture quickly
- Build features rapidly
- Debug efficiently
- Scaffold entire apps in hours
So why am I still sacrificing user experience for cross-platform purity?
The AI Era Changes the Cost Equation
Before AI:
- Writing two native apps meant double effort.
- Cross-platform was a major efficiency win.
Now?
AI has:
- Reduced the cost of duplication.
- Reduced the fear of platform-specific code.
- Reduced time-to-market dramatically.
That changes everything.
If AI can help me build:
- A dedicated iOS app
- A dedicated Android app
Very quickly…
Then the main historical argument for full cross-platform weakens.
So Did I Abandon KMP?
No.
I refined how I use it.
Instead of sharing the whole app, I share:
✅ Core Business Logic Only
KMP now handles:
- Domain logic
- Core use cases
- Shared business rules
- Shared models
But not:
- UI
- Deep platform integrations
- System-level features
In other words:
KMP is responsible for logic — not experience.
A New Pattern for the AI Age
Here’s what I believe will become common:
🧠 Shared Brain, Native Body
- Shared KMP module → core logic
- Native iOS app → full Apple ecosystem power
- Native Android app → full Material & system integration
This hybrid model gives:
- Maximum user experience quality
- Platform-first design
- Shared intelligence
- Reduced duplication where it actually matters
Final Reflection
KMP isn’t the problem.
The assumption was.
In the AI era:
- Development speed is no longer the bottleneck.
- User experience differentiation matters more.
- Platform-native depth wins.
AI agents boost productivity.
So instead of forcing cross-platform everywhere, we can:
- Share what should be shared.
- Specialize what should be specialized.
And that balance feels right.
Comments