Hello, I would like to get some answers from the J...

# multiplatform

[Andrej Martinák]

Hello, I would like to get some answers from the JetBrains team working on KMP, hope this is the right place 🙂.

I work for a company with a large e-commerce platform on web, Android, and iOS. A year ago, I was hired to work on transforming our mobile native solutions to utilize KMP, so we can share common logic in a single codebase (duh). Both mobile apps are quite complex. While our Android team is enthusiastic about the transition, we're facing significant resistance from our iOS team. I'd like to share their feedback and concerns to understand how JetBrains is addressing these issues in upcoming releases.

Developer Experience Issues:
• Poor IDE navigation and code completion functionality in Xcode (lots of the code has "ugly" accessors, underscores, doInit vs init, etc.)
• Needing to rely on third-party libraries (from Touchlab)
• General frustration with the development workflow compared to native iOS development
Resource Allocation Concerns:
• Since the iOS team and their tech lead are not keen on leveraging KMP, nobody is focused on working on the integration of KMP (and making the developer experience better) in the iOS project. The iOS team claims that the implementation and maintenance of KMP takes the focus away from iOS-specific technical tasks. This creates a vicious cycle, where there is no advancement and investment in KMP.
• The learning curve for Kotlin diverts resources from platform-specific improvements
• Input from Android devs is needed if changes in the KMP library are necessary
Long-term Viability Concerns:
• The perception that KMP development from JetBrains has been slow over the past 2 years
• Focus on Compose Multiplatform, which in our understanding is not as important as focus on good developer experience (and using KMP for the domain layer and not the presentation)
• The recent abandonment of Fleet as KMP IDE has raised concerns about JetBrains' commitment
• Uncertainty about investing in a technology that might not receive continued support
The resistance from iOS developers isn't unique to my company. I've talked to multiple tech leads in large companies in my area and gotten basically the same response - Android devs love the idea, iOS devs are against it. Because of this pattern, leaders have decided not to go "all-in" on KMP (storing only some configurations and networking vs implementing actual business logic). I would like to give the iOS team some garranty, that KMP is the right technology to use, but at this stage, it is quite hard to find it (for example the case studies are few and I'd say obsolete).

My questions are:
1. What specific improvements to the iOS developer experience are planned for the next 6-12 months?
2. Following the shift from Fleet to focusing on IntelliJ/Android Studio, what's the roadmap for iOS-specific tooling improvements? Is the focus now on adding Swift support to IDEA Ultimate?
3. When can we expect the first public version of Kotlin-to-Swift export, and what capabilities will it offer initially?
4. Are there plans to simplify the distribution and integration process for iOS applications? E.g. by using Amper or something similar?
5. How is JetBrains addressing the objection that KMP lacks sufficient development momentum?

Thanks for any insights you can provide! Would love to see also some perspective from other people in a similar situation as I am 🙂.

[streetsofboston]

Great questions.
We're lucky our (iOS) team at Accenture doesn't have these resistance. This is mostly because our mobile devs need to be able to develop in multiple frameworks/toolset in the course of their careers already: pure native, Flutter, React Native, Ionic, you name it.

The wonderful folks from Touchlab, @Namnum and @kpgalligan, may have some good answers for you as well.

[Pablichjenkov]

Not associated with JB in any way but I'd like to share my thoughts based on experience. Let them do swiftui and the ViewModel stuff in swift land where they can use all the Apple observability API and xcode preview tooling and such, just share the domain and data layers and if possible don't complicate the domain and data layers with many coroutine stuff. Making it easier to consume on their side.
The problem with sharing the ViewModel in KMP as many suggestions you see on the internet, the problem with this approach is that they lose a lot of speed and tooling while coding.
They don't feel productive bc they have to reach out to Android folks for any minimum change in ViewModels.
Obviously this aspect improves when they start mastering Kotlin but it could take up to a year or more.

[streetsofboston]

We use KMP everywhere but the UI (but we use KMP for navigation using Decompose). This means we do implement our ViewModels (Components in Decompose terms) in KMP and use Skie to help us with the suspend stuff.

[Namnum]

Thanks for tagging us @streetsofboston. Sorry @Andrej Martinák, we're at a conference today, but I'll have someone from the team take a look in the next day or so. I scanned the message and definitely looks like some familiar issues.

[Anton Makeev]

@Andrej Martinák thank you for taking time collecting the concerns! They are extremely valuable. We’ll prepare the answers and get back to you shortly

[Suresh Maidaragi]

@Andrej Martinák
Are you want to re-develop the exist ecommerce app in KMP by deprecating the existing native (ios&android) apps or do you want to build feature's in KMP into existing native apps?
> so we can share common logic in a single codebase (duh).

[Anton Makeev]

@Andrej Martinák, thank you again for sharing your concerns and difficulties with us! Especially now with the stable release of Compose Multiplatform for iOS we expect more teams needing assistance with iOS development. We’ll be working with the feedback to gradually improve the situation. And we would love to reach out to you and your team in DM to better understand, if that works with you.

As for your questions, below we tried to address them as fully as we can, but feel free to follow up.

1. What specific improvements to the iOS developer experience are planned for the next 6-12 months?

We know that integrating with iOS can have friction, both technical and organizational, and we’re working on both of these aspects, for example by:
• Creating onboarding materials for iOS developers and mixed teams
• Engaging with more iOS developers directly at events and online
• Providing Swift Export, which gives a more idiomatic API specifically for iOS developers
While it’s possible to get started with KMP by providing a “black-box” framework for iOS developers to use, we find that it works best when everyone involved buys in to KMP. Forcing iOS developers to use KMP is rarely successful.

Getting a team to use KMP requires active collaboration, education especially for iOS developers, and empathy all around, and of course it does take time. But the result can be a productive, unified “mobile team” and “mobile developers” instead of a strict platform-specific split.

We also heard from many iOS developers who said that KMP is the cross-platform technology that they’re most willing to adopt, given the similar language, and flexible nature of the technology. It’s good to reassure them that their iOS expertise will still be required and they can still write important native integrations (including native UI, if that’s the path you choose), even if there’s parts of the project that are shared with KMP.

2. Following the shift from Fleet to focusing on IntelliJ/Android Studio, what’s the roadmap for iOS-specific tooling improvements? Is the focus now on adding Swift support to IDEA Ultimate?

We changed our plans around IDE support in large part as a response to user feedback, but we’re reusing a lot of the experience from our KMP tooling work in Fleet. You can read more about this in the blog post.

A new KMP plugin is coming soon for both IntelliJ IDEA and Android Studio, and we are fully committed to providing great support in both of these IDEs. This plugin will include support for iOS workflows with working with Swift. Stay tuned for more updates on this very soon!

We’re also fully committed to Kotlin Multiplatform and Compose Multiplatform in general, these are really important technologies for us, and a huge part of what JetBrains and the Kotlin team is working on.

3. When can we expect the first public version of Kotlin-to-Swift export, and what capabilities will it offer initially?

The first experimental release is planned for Kotlin 2.2.20 (autumn 2025).

That release will already cover many core language features like various types of classes (including sealed classes, enums, etc), nullability, collection types, extensions, and more. Support for features like coroutines and Flows is also coming in future releases.

4. Are there plans to simplify the distribution and integration process for iOS applications? E.g. by using Amper or something similar?

The publication flow is not something that we’re actively working on. However, as we’ve mentioned, we’d love to get some contact details from your team in DMs and discuss any difficulties you’re facing in this area (and anything else around multiplatform, of course).

5. How is JetBrains addressing the objection that KMP lacks sufficient development momentum?

We see the number of KMP users and companies adopting it growing constantly, and we’re also advancing the technology itself.

In the KMP ecosystem, there was a 65% increase in the number of KMP libraries just in the last year. Google has announced official KMP support less than a year ago at Google I/O 2024, and they’re releasing more and more multiplatform Jetpack libraries as well. We recently introduced cross-compilation for libraries, which makes it even easier to publish them, and we’re also working on a new publication format.

As already mentioned above, there’s new tooling coming for IntelliJ-based IDEs, as well as Swift Export for a better iOS development experience.

We’re also expanding our documentation with new and updated material all the time. The “Multiplatform journal” section on the KMP portal might have interesting resources for you, such as this page about introducing KMP to a mobile team.

By the way, on the topic of case studies you’ve mentioned: we are indeed a little behind on updating these, but it’s in progress! You can keep monitoring them on this page. We also highlighted some prominent companies in

this video▾

last year, and you can find even more companies sharing their stories this year at KotlinConf - you’ll find KMP talks from Google, Amazon, Duolingo, McDonald’s and more in the schedule. We’ve also recently asked the community to send us their examples of using Compose Multiplatform for iOS in production and got hundreds of submissions - you can see some of these features on the updated Compose Multiplatform landing page.

A lot of our efforts are happening around Compose Multiplatform, as we see a large number of companies looking for solutions that include stable support for full UI sharing. Here, we recently introduced Compose Hot Reload, we’re moving towards beta on the web, and Compose Multiplatform for iOS just became stable - to mention just the highlights.

The web target is maturing too, with Wasm now supported by default in all major browsers, and continuous performance and developer experience improvements in Kotlin/Wasm.

[streetsofboston]

^^^ Great write-up!
In our experience at Accenture, the most most most important thing is the culture of the team(s) of developers. Buy-in, mentoring, coaching and education is super important for a successful cross platform project, whether cross platform is KMP or any other framework/toolset.

All the other things are technical things. They can be annoying, but they can be dealt with relative ease (compared to culture).

[streetsofboston]

In other words, these technical issues will not cause your KMP project to fail (it may slow it down somewhat, though).

But a poor 'culture fit' can cause your KMP project to fail.

[kpgalligan]

various types of classes (including sealed classes, enums, etc),

I really can't find details about this anywhere, but the details are pretty important if Swift export is going to be "a better iOS development experience". I assume enums are proper Swift enums, as value types, although that gets interesting with how Kotlin enum classes work, and how that all works with generics. But, are sealed classes exhaustive and can they do the same thing semantically in swift that they do in Kotlin, or are they just "classes" to Swift?

[zsmb]

The exact scope isn't set yet, but they're almost certainly going to be "just classes" in the first release that was mentioned above, with the exhaustive part coming later.

[kpgalligan]

That whole topic is one of the core things I've been talking about for a few years. Kotlin and Swift are syntactically similar, but semantically very different, so it's not (entirely) that ObjC is dumbing everything down. It's more that Kotlin and Swift build their approaches from the base of Java and ObjC respectively. Java and ObjC, while syntactically quite distinct, are semantically very similar in many ways. Why? They both were originally designed when OOP was the peak of language design. So much so that, infamously, I think Java gets the award for most irrelevant boilerplate to write "Hello World" of any language ever. J2ObjC, which almost universally hated (I would argue very unfairly), was also very practical. Because Java and ObjC, semantically, are very similar. As an analogy, talking about language evolution in terms of biological evolution isn't as much of a stretch as it probably seems. Java and ObjC are much closer to a common ancestor, and "evolved" similar approaches to the same problems. Kotlin and Swift also evolved to solve similar problems, but do so in ways that are quite different. Anyway, if that statement demonstrates anything, it's that I've spent way too much time thinking about this.

[kpgalligan]

On getting teams on board, briefly. I've been focused on that for the last few years. It's a complex topic, and I won't even try to summarize it here. But, I've been very focused on how you arrive at whatever your team goals are by incremental, practical, and low-risk steps. Every KMP adoption starts with a proposal of adopting KMP, and if the first step, and only recommended approach, is radically altering the workflow, repo layout, tooling, and necessary skills of the team members, then, from observation, as team size grows, the success rate of the proposal declines. KMP adoption can be amazing, but you have to get there. The proposal needs a vision of how great "there" can be, but it also needs a map, and a low-to-no-risk one.

[Petter Måhlén]

Java and ObjC are much closer to a common ancestor

ObjC can in fact be considered an ancestor of Java. Though both languages have of course evolved since then, so it's probably more correct to think of the ObjC of the early 90s as their common ancestor.

[Andrej Martinák]

@Pablichjenkov - The thing is that we are not even there yet - we do not intend to share the ViewModels or anything related to the presentation layer. In Kotlin, we use Clean Architecture. We took the simplest business feature of our Android app and moved the data and domain layers into the KMP library - we only provide the Use Cases, that the iOS app can wrap in Services and just use them. The iOS team was not able to get into this due to the forementioned issues.

@streetsofboston - Thank you so much for your insight, I indeed also think that this is a tech culture problem - we are divided into Android and iOS specialists and I don't observe much will getting into more diverse frameworks (e.g. I don't know anyone in the team to have React Native experience or liking it)

@Namnum - I would love to hear some thoughts from you or your colleagues, your feedback would be extremely valuable, since we use a lot of stuff from you guys :)

@Suresh Maidaragi - The idea was to do both - build new business features in KMP and also move some already existing ones to the common library.

@Anton Makeev - thank you so much for the write-up and the insights into the the development and of the overall ecosystem of KMP. Of course I am open to be contacted via DM. I will share what I've learned here with our staff engineers and get back to you if I have some more feedback or questions. I'm grateful for your response.

@kpgalligan - thank you so much, the idea of incremental introduction of the team to the technology is something we have been trying to do for the past year and half. But it seems I am a bit too impatient :)

[Pablichjenkov]

Oh I got you Andrej, well, that strategy you just described I think is the best to keep the iOS team happy and involved. You keep the full presentation layer in swift and just give them the domain and/or data layers.

[kpgalligan]

the idea of incremental introduction of the team to the technology is something we have been trying to do for the past year and half. But it seems I am a bit too impatient 🙂

Well, I'd say incremental is good, and usually necessary, but it also needs steady progress. Otherwise it'll just stall (or not start). I think you'll find some good updates from KotlinConf around progress.
Beyond that, though, I'll add a bit of detail to the introduction process. It might help to be able to introduce some KMP in a no-friction way. That is often the process that teams take. Almost all teams, if they're not bought-in on day one, build some kind of KMP library. Things that aren't changed day-to-day when doing feature dev work. Networking, analytics, maybe some kind of logic module. Instead of requiring the iOS team to install all of the tooling, publish SPM builds (I assume you're using SPM. If not, this is a bit of a different story). Source is ideal, in that iOS devs can see the code, maybe make light edits or track down a bug, but configuring repos and devs' setups is not exactly trivial, and likely to get more pushback.
You can publish SPM dev builds, which iOS devs can include in their project, without really doing anything wild with config. We publish an Xcode Kotlin plugin that does source coloring and allows for debugging in Xcode. SPM, as part of how it works, clones the code itself. So, devs aren't building it locally, and so they don't need to sort out tooling, but they can see and debug Kotlin, without leaving Xcode. https://touchlab.co/spm-kotlin-debugging. Then, some teams either just have a dev branch where this can be demoed and tried without putting it in production, and some actually publish with the KMP code in the app, but behind a feature flag (or something similar). This was more of an issue several years back, when the vague "what if the app just crashes?!" fear was something that was brought up. If you do some kind of incremental roll out plan, like 1%, then 10%, etc, until all users have KMP code in the mix, that's also how some teams roll out.
The idea is to remove as much pushback as you can that is being introduced purely by the disruption of the dev team itself. If you can remove friction, potential for disruption, and risk, the less there is to push back on. If it is quite literally "add this package and call the library code, then maybe install this plugin so you can debug it", I mean, that really is as minimal as it can get. On the other issues (long-term viability, etc), that simply needs to be worked on, but as in all topics with people, the less they like an idea, the more they'll highlight and weigh various aspects of it. I've been doing this "sale" since KMP started, and J2ObjC before that. It's kind of the same story, except KMP is stable and has reasonable adoption at this point. But, removing all pushback except unknowns about long-term viability helps focus the debate. Then it's simply iOS saying they don't think this is a good idea. At that point, well, if that's enough, then I'm not sure what you can do.
Anyway, libraries are pretty common for KMP. You'd be surprised how many apps actually have some KMP in them. Going beyond that, and implementing actual app code, with iOS devs contributing, is where adoption can get stuck. It doesn't have to get stuck, but process helps considerably. Jumping straight to "now we're all editing Kotlin" is a step that is much more difficult to do out of the gate, and that difficultly increases dramatically with team size.
This is getting a bit dated, but explains at least how I think through this stuff: https://touchlab.co/kmp-teams-intro. It was before we figured out debugging Kotlin code from SPM binaries, which sort of reduces the "use source" emphasis as a first step. This explains why libraries are fairly straightforward but moving up the stack gets difficult: https://touchlab.co/kmp-teams-piloting-vs-scaling.
On dev ex for iOS folks, and not wanting to use 3rd party libraries, that one has always seemed odd to me. But, after spending time talking to iOS teams, that is a pretty common story. The Android/Kotlin ecosystem is just different. For years you'd have a really hard time making anything if you weren't using outside libraries. SKIE is, for sure, not a simple library, but it does help quite a bit with the Swift-facing API. The alternative is writing Swift wrappers, which is obviously more work. This is where I'd derail the rest of my day and throw in "have tried AI tools lately?" to help generate those wrappers, but let's not go there...

[Namnum]

would love to hear some thoughts from you or your colleagues,

@Andrej Martinák you're in good hands already, @kpgalligan is my business partner