Building a Production-Ready Kotlin Multiplatform Platform Kit: Lessons from My BlrKotlin x InMobi Talk
How I built an open-source Kotlin Multiplatform reference project to help Android teams move beyond tutorials and start thinking about production-ready architecture.
Last weekend, I had the opportunity to speak at the BlrKotlin x InMobi Android Meetup in Bengaluru, where I shared something I've been working on over the past few months—a practical Kotlin Multiplatform Platform Kit.
Rather than giving another introduction to Kotlin Multiplatform, I wanted to focus on a question many Android teams eventually ask once they move past the excitement of "Hello World" examples:
"We understand what Kotlin Multiplatform is—but how do we actually structure a project we'd be comfortable maintaining in production?"
To answer that question, I built kmp-platform-kit, an open-source reference repository that demonstrates how to organize a Kotlin Multiplatform codebase with clean architecture, modular boundaries, and engineering decisions inspired by real production projects.
What made the evening memorable wasn't just presenting the repository—it was the discussion that followed. Instead of debating whether Kotlin Multiplatform is "the future," the audience wanted to talk about something much more valuable:
- How should teams start adopting KMP?
- What should actually live inside the shared module?
- What should remain platform-specific?
- How do you avoid creating an architecture that's harder to maintain than two native applications?
Those conversations inspired this article.
Rather than summarizing the meetup, I wanted to capture the engineering principles behind the repository so anyone exploring Kotlin Multiplatform can benefit from them.
Table of Contents
- 1. Why I Built This Repository
- 2. The Philosophy Behind the Platform Kit
- 3. What We Discussed During the Talk
- 4. Common Mistakes Teams Make
- 5. Why Reference Repositories Matter
- 6. What I Learned From Speaking
- 7. Thank You BlrKotlin & InMobi
- 8. Explore the Repository
- 9. FAQ
1. Why I Built This Repository
If you've ever started learning Kotlin Multiplatform, you've probably noticed that most tutorials are intentionally small.
They teach a concept.
They demonstrate an API.
They show how expect/actual works.
They're excellent learning resources.
But there's one problem.
Real applications aren't built from isolated examples. They're built from dozens of modules, hundreds of classes, multiple engineering teams, and years of evolving requirements.
Once you start thinking beyond a sample project, entirely different questions begin to appear:
- How should modules be organized?
- Where should business logic actually live?
- Should networking always be shared?
- What belongs in commonMain?
- What responsibilities should stay on Android or iOS?
- How can dependency injection remain clean?
- How do you prevent the shared module from becoming a giant dumping ground?
None of those are Kotlin questions.
They're architecture questions.
And architecture becomes even more important once code is shared across platforms because every poor decision now affects multiple applications instead of one.
That's exactly why I built kmp-platform-kit.
The repository isn't meant to be another sample app. It's meant to become a reference project that developers can clone, inspect, experiment with, and adapt to their own products.
Instead of teaching APIs, the repository tries to teach engineering decisions.
2. The Philosophy Behind the Platform Kit
When building the repository, I kept asking myself one simple question:
"What would I want to clone if I were evaluating Kotlin Multiplatform for a real production application?"
That question shaped every architectural decision.
The objective wasn't maximizing shared code.
It was maximizing maintainability.
Every module exists for a reason.
Every dependency follows a deliberate direction.
Platform-specific code remains platform-specific.
Business logic stays independent.
Interfaces define contracts.
Implementations remain replaceable.
One of the biggest misconceptions around Kotlin Multiplatform is the idea that success is measured by the percentage of code you manage to share.
I don't think that's the right metric.
Instead of asking,
How do I make Android and iOS share everything?
I believe teams should ask,
What should actually be shared?
That small shift completely changes how you approach architecture.
The goal is no longer aggressive code sharing.
The goal is clean ownership, scalable modules, and a shared layer that remains pleasant to maintain years later.
3. What We Discussed During the Talk
One thing I intentionally avoided during the session was spending too much time introducing Kotlin Multiplatform itself.
Most developers attending the meetup already knew what KMP is. They've watched conference talks. They've read the documentation. Many had already experimented with small sample applications.
The more interesting discussion wasn't "What is KMP?"
It was:
"How do experienced engineering teams actually build applications with it?"
That completely changes the nature of the conversation.
Instead of focusing on language features, we explored the architectural decisions that determine whether a Kotlin Multiplatform project remains maintainable six months later.
Some of the key discussions included:
-
Shared Business Logic
How much business logic should actually live inside the shared module, and where platform boundaries should naturally exist. -
Platform Responsibilities
Understanding why platform-specific APIs, UI implementation, and operating system capabilities should continue to remain native instead of being unnecessarily abstracted. -
Module Design
Designing modules that scale with growing applications rather than collapsing into one massive shared library. -
Dependency Inversion
Using interfaces and abstractions to keep the shared layer independent from platform implementations. -
Incremental Adoption
Why successful KMP migrations almost never happen as complete rewrites.
One theme kept appearing throughout the discussion:
Successful Kotlin Multiplatform projects don't maximize shared code. They maximize maintainability.
That distinction matters.
A project that shares 95% of its code but becomes difficult to evolve isn't necessarily better than one that shares 60% while remaining clean, modular, and easy to reason about.
Engineering is always a balance of trade-offs. Kotlin Multiplatform is no different.
4. Common Mistakes Teams Make
While building the repository—and from conversations with other Android developers—I noticed several patterns that appear repeatedly when teams start experimenting with Kotlin Multiplatform.
Most of these aren't framework limitations.
They're architectural decisions that slowly introduce complexity over time.
Sharing Too Much
One of the biggest misconceptions is that everything should live inside commonMain.
It sounds attractive.
More shared code feels like greater success.
In reality, excessive sharing often produces the opposite result.
Android and iOS are different platforms with different user experiences, APIs, lifecycle models, and design philosophies.
Trying to hide every platform difference behind abstractions usually introduces unnecessary complexity.
Instead, I prefer asking a much simpler question:
Does this logic genuinely represent business rules, or is it platform behavior?
If it's business logic, sharing probably makes sense.
If it's platform behavior, it probably belongs on the platform.
Weak Module Boundaries
Another common mistake is treating the shared module as one giant library.
As applications grow, every feature begins depending on every other feature.
Eventually the architecture becomes difficult to understand because ownership disappears.
Instead of one large shared module, I prefer clearly separated responsibilities.
- Core utilities
- Domain models
- Business logic
- Networking
- Persistence
- Platform implementations
Smaller modules create better boundaries, better testing opportunities, and easier long-term maintenance.
Treating KMP as a Migration Project
Perhaps the biggest mistake is assuming Kotlin Multiplatform requires rewriting an entire application.
That's rarely necessary.
Most successful teams start with a single use case.
They share one feature.
Validate the architecture.
Understand the developer experience.
Only then do they expand gradually.
Incremental adoption dramatically reduces risk while allowing teams to continuously learn from real production feedback.
Start small. Learn continuously. Expand intentionally.
5. Why Reference Repositories Matter
One realization I had while preparing this talk is that documentation, conference talks, and sample applications each solve different problems.
Documentation explains APIs.
Conference talks inspire ideas.
Reference repositories connect the two.
They're where developers answer practical questions that documentation often can't:
- Where should this interface live?
- Which module should own this responsibility?
- How should dependency injection be organized?
- How should networking be separated from business logic?
- What belongs in commonMain?
- How should platform implementations communicate with shared code?
These questions don't usually have one correct answer.
That's exactly why reference repositories are valuable.
They don't claim to represent the only architecture.
They demonstrate one well-reasoned approach that developers can learn from, challenge, and adapt.
That was the objective behind kmp-platform-kit.
Not another sample application.
A practical reference project built around engineering decisions rather than framework features.
Hopefully it becomes something developers can clone, experiment with, and modify for their own products instead of simply reading once and forgetting.
6. What I Learned From Speaking
Every time I prepare for a conference talk, I walk away learning as much as the audience does.
One of the biggest misconceptions about public speaking is that it's primarily about sharing knowledge.
In reality, it's about refining your own understanding.
When you're responsible for explaining an architectural decision to a room full of experienced engineers, you quickly discover which ideas are genuinely simple and which ones only make sense because you've been living with them for months.
Preparing this talk forced me to remove unnecessary complexity.
It challenged me to explain architecture without relying on buzzwords, diagrams filled with arrows, or "best practices" that aren't backed by real engineering trade-offs.
That process reminded me of something I've learned repeatedly while building Android applications and developer tools:
Developers rarely ask for more features.
They ask for more clarity.
People don't just want to know what works.
They want to understand:
- Why does this architecture exist?
- What problems does it actually solve?
- What trade-offs come with it?
- When should I avoid it?
Those questions lead to far more valuable discussions than simply showing code.
If attendees leave the room with a stronger mental model instead of just another GitHub repository bookmarked for later, I consider the talk a success.
7. Thank You, BlrKotlin & InMobi
A huge thank you to the BlrKotlin community and InMobi for organizing such a fantastic meetup.
Community events like these are one of the reasons I enjoy being part of the Android ecosystem.
They create opportunities for engineers from different companies and backgrounds to openly discuss challenges, exchange ideas, and learn from one another without worrying about company boundaries.
What I appreciated most about this meetup was the quality of the conversations after the session.
The audience wasn't interested in whether Kotlin Multiplatform is "better" than native development.
Instead, they wanted to discuss architecture.
They wanted to understand trade-offs.
They wanted practical advice they could take back to their own teams.
Those are exactly the conversations that make community events worthwhile.
A sincere thank you to everyone who attended, asked questions, shared feedback, and continued the discussion afterward.
8. Explore the Repository
If you're beginning your Kotlin Multiplatform journey—or if your team is evaluating KMP for production applications—I hope kmp-platform-kit serves as a useful reference.
Rather than providing another toy example, the goal is to demonstrate architectural thinking that can scale as products grow.
Feel free to clone the repository, explore the module structure, experiment with the architecture, and adapt it to your own needs.
If you discover better approaches or have ideas for improving the project, I'd genuinely love to hear your feedback.
Open-source projects become better through conversations with the community, and this repository is no exception.
Key Takeaways
- ✅ Kotlin Multiplatform is an architectural decision—not just a code-sharing tool.
- ✅ Focus on sharing business logic, not everything.
- ✅ Strong module boundaries matter more than maximizing shared code.
- ✅ Incremental adoption is usually safer than a complete rewrite.
- ✅ Reference repositories accelerate learning far better than isolated code snippets.
- ✅ Architecture should optimize maintainability, not simply reduce duplicate code.
Useful Links
FAQ
Is this repository intended for beginners?
Yes. While some familiarity with Kotlin Multiplatform is helpful, the repository is designed to be approachable for Android developers who want to understand how KMP projects can be structured beyond simple tutorials.
Does the project use Clean Architecture?
Yes. The repository follows Clean Architecture principles with clearly separated responsibilities, dependency inversion, and modular boundaries to keep the shared layer maintainable.
Should everything be shared in a Kotlin Multiplatform project?
Not necessarily. Business logic often benefits from sharing, while UI, platform APIs, and operating system-specific behavior are usually better kept native. Sharing the right code is more important than sharing the most code.
Can I use this repository as a starting point for my own application?
Absolutely. The project is intended to be cloned, explored, and adapted rather than treated as a finished framework.
Why did you build this repository?
Most KMP resources explain language features but stop short of discussing production architecture. This repository aims to bridge that gap by demonstrating practical engineering decisions that teams can build upon.
⭐ Explore kmp-platform-kit on GitHub
If this article helped you, consider sharing it with your team or someone exploring Kotlin Multiplatform. The more we share practical engineering knowledge, the stronger our developer community becomes.
Thanks for reading ❤️
If you'd like to see more content on Android Architecture, Kotlin, Performance, Developer Tooling, and Kotlin Multiplatform, stay connected through DroidUnplugged.
Happy Coding! 🚀
.png)
Comments
Post a Comment