Why we need iOS developers on board with Kotlin/Multiplatform

Last week, we published the testimony of Robbie Hanson, whom we’ve been working with for several months on the Phoenix-KMM multiplatform application. We thank him again for his valuable feedback.

In this post, I want to share my thoughts after reading his, and express my feelings about the state of Kotlin/Multiplatform for iOS developers.

First of all, I want to reiterate that we believe that Kotlin/Multiplatform can only thrive with the support of iOS developers. Seeing Kotlin/Multiplatform as “just another React-Native”, is a big mistake. In Kotlin/Multiplatform, Android apps are developed with official Android Kotlin APIs and compiled with Android Studio ; while iOS apps are developed with official iOS Swift APIs and compiled with XCode. Kotlin/Multiplatform focuses on what is truly common to these apps : their business. It does not try to provide a unified application model.

This is important, because it means that you do need expertise in both Android and iOS native applications to create the best experience on each platform.

It goes beyond navigation & UI: notifications, background work, permissions, battery optimization, configuration changes, sensor data retrieval, and more APIs, are exposed in very different ways on iOS and Android. If you want a quality iOS application, get an iOS expert. Kotlin/Multiplatform is not going to change that, and that’s a very good thing.

The first question we often get when presenting Kotlin/Multiplatform, and specifically from iOS developers is “How safe is it to invest in it?”. After all, there’s one tool to develop iOS apps that will never disappear : XCode. Our very short tech field history is littered with examples of amazing tech being dropped in a heartbeat. RoboVM was developing an amazing AoT compiler for the JVM to target iOS (a precursor of GraalVM), only to be bought by Microsoft and killed without so much as a warning or a migration strategy. If you worked with RoboVM, you bet on the wrong horse. Your loss.

Robbie expressed this concern in his feedback. He wrote that Apple & Google don’t have any incentive to provide multiplatform application technologies because it is their business model to lock the user into their ecosystem. While I think that’s definitely true for Apple, I don’t think that’s the case for Google. Google is trying to push their services to iOS users, whether its location & recommendation, advertisement, productivity suite, and many other services. That’s why Google provides native material design components for iOS, or a host of iOS APIs, or J2ObjC, or even Flutter.

That being said, I believe there’s little chance Google would ever want to acquire Jetbrains. Jetbrains is quite a massive company, with business interests that are nowhere near Google’s. It is interesting to see Kotlin becoming “larger” than Jetbrains itself. The Kotlin Foundation was, I believe, created specifically to show that the Kotlin language is handled outside of Jetbrains. However, the way the foundation is governed basically boils down to:

• Only Jetbrains, Google, & the University of Texas are allowed (if you, as a company, want to integrate the foundation, they are “discussing” how that can happen).
• The foundation board appoints a lead language designer, which does whatever (s)he wants with the language, as long as (s)he does not break existing code.
• That’s it.

The real question is therefore “Can Kotlin/Multiplatform survive Jetbrains loss of interest?”. We’ve seen a lot of companies (Google being their leader) launching technology previews, only to kill it without so much as a shrug. If JetBrains decides that Kotlin/Multiplatform is not profitable, there’s little chance that it would ever survive.

Let’s be honest : Kotlin/Multiplatform is not profitable at the moment. There’s just no way that it is. Jetbrains is investing a lot of effort into making it a viable Open Source product. They are continuously improving the tooling (yes, it is slow), improving the compiled code performance, and trying to lower the barrier of entry.

It is still a bleeding tech, though, which makes it impossible to monetize properly, and also leads to two questions when you decide to use it.

Q1: How much are you going to bleed?
You are, there’s no question about it. Kotlin/Multiplatform is not Swift (nor is it regular Kotlin for that matter). The good news is that we already bled a lot so that your blood contribution could be lower. Jetbrains listens to its community, and does orient its development accordingly. Rough edges are far from softened, though. You are going to yell at IDEA for not helping you figure out why on earth your app crashes with a FrozenObjectException, or why some iOS APIs are exposed to Kotlin but do not work as intended. Robbie sees it as “short term pain for long term gain”. We created Kodein Koders to specifically help you through that pain.

Q2: Can Jetbrains pull sufficient work and support to make it complete?
The answer, to me, is by far the most uncertain of this post. Jetbrains has invested a lot in Kotlin/Multiplatform, and is still investing a lot in its tooling. We were interviewed by them to give our feedback on future possible tooling they are creating for Multiplatform and we saw the investment the team is pulling at every new release. Also, JetBrains has no history of dropping a product they invest into.
There’s a first for everything, though, and as said earlier, it all boils down to Kotlin/Multiplatform becoming a viable product, or at least a viable factor of conversion to paid products.
My guess is that if there’s one company that can pull it off, it’s definitely JetBrains. However, that’s all it is: a guess.

Which leads to:

Q3: Should we invest in Kotlin/Multiplatform ?
Well, I created a company just to help you implement this technology, so you may need to take my answer for what it is: the answer of a true enthusiast.
That being said. Yes.

Next pain point that Robbie Hanson describes for iOS developers : Gradle.

This is going to be quick : I really like Gradle. Instead of using a UI to configure your compilation chain (which is only efficient for basic usage), you get to program it. To me it’s way more powerful, and makes simple and complex use cases consistent. The advent of the Kotlin language inside Gradle build scripts brought code completion and in-IDE correctness checks.

There’s a very important difference between Gradle and Makefiles. Makefiles are a declarative language (much like Maven POMs) while Gradle uses a full programming language to let you describe your model.

I’d choose Gradle over XCode anytime, because I feel the XCode UI for compilation configuration is messy and clunky. However, that’s an affect-informed opinion. Nothing more. In the end, if you take the time to learn it, there’s no reason not to master it.

Robbie and I do agree on one thing, though: that’s an investment, and iOS developers are not used to investing in understanding build tool-chain configuration.

While Robbie does end his testimony by recommending the use of Kotlin/Multiplatform, he still feels like iOS developers are second class citizens. This is an argument I find very hard to argue against.

We (as Kodein Koders), have advocated repeatedly that iOS developers should be more considered regarding the development of Kotlin/Multiplatform mobile projects. Here are some differences between Android dev and iOS dev experiences with Kotlin/Multiplatform:

• Android developers can open the project and have both the shared library and the Android app in the same IDE. Changing the library API is instantly reflected in the application code, whether Java or Kotlin. iOS developers need to have two IDEs (IntelliJ & XCode). After changing the library API, you need to compile it to see the changes reflected in XCode.
  EDIT: There is now Kotlin support in AppCode, with "near-instant" reflection of Kotlin code change in Swift API. Now we "just" need to convince iOS developers to use AppCode. Sight.
• Android developers do not need XCode installed to work on the shared library or on their application. They only need it should they want to compile the iOS shared library. Until they do, no iOS toolchain is needed whatsoever. iOS developers need an Android SDK installed to work on the shared library, or even just to compile it for iOS. The IDE needs it, and so does the Kotlin/Multiplatform Gradle plugin. This means that you cannot even checkout the code and compile it for iOS from the command line without a 10GB+ Android SDK being needed. This might be symbolic, but to iOS devs, I can understand how frustrating this can be.
• Android developers get to use the full power of the Kotlin language while iOS developers are limited to its features that are interoperable with Objective-C. Not Swift: Objective-C. While the generated interop header provides Swift annotations, it’s still an Objective-C header (so, for example, you can have generic classes, but not generic interfaces). Yikes.
• Don’t even get me started on the Kotlin/Native (and therefore iOS) specific multithreaded memory model!

There are some issues that Jetbrains is actively working on (such as changing the multithreaded memory model), some that are “postponed for later” in the Kotlin roadmap, and some are just not addressed.

Being able to load and compile for iOS without an Android SDK does not seem to be any concern (probably because JetBrains is focusing on Android Studio to be the go-to IDE for Kotlin/Multiplatform Mobile). We showed how it can be done manually in two different ways, but it does involve some pretty hacky Gradle workarounds.

All in all, iOS developers feeling second class citizens in Kotlin/Multiplatform is a reality. Jetbrains is working on alleviating that feeling, but it does not look like they are making it a priority.

Why do we need iOS developers on board with Kotlin/Multiplatform?
After all, isn’t the point of KMM to get rid of platform specific developers? If KMM focuses on abstracting the business, all that’s left for the platform is only the UI… we don’t need platform experts, we just need KMM experts!

That’s a grave misconception, and I argue the exact misconception that prevented React-Native or Xamarin from becoming reasonable alternatives. Dividing application code in either business or UI is an error. There’s a third category: platform integration (notifications, background work, permissions, battery optimization, configuration changes, sensor data retrieval, etc). Kotlin/Multiplatform only abstracts the business code, not UI, and not platform integration. This latter category is a complicated topic, and requires a deep understanding of the platform you are trying to integrate your experience into.

So that’s one reason: we need iOS developers on board with Kotlin/Multiplatform because their expertise remains 100% relevant and needed in a KMM application, should we want to create quality iOS experiences.

Another important reason is advocacy. Take a random CTO who needs both an iOS and an Android application. The perfect target for KMM advocates (which I proudly associate with). Let’s say he/she pitches his/her needs to the mobile developer team. The Android person may reply : “Oh! By the way, have you heard of Kotlin/Multiplatform? It’s amazing! It compiles Kotlin business code to iOS, so that the code is only written once. Since Kotlin is already the official Android language, the code will be written anyway!”.

The push back from the iOS developer will be immediate: “Yeah, but I’ve heard iOS developers are poorly supported, and that it makes iOS development more difficult. I like my simple XCode, and I master Swift. This will probably make me unhappy.”.

As I’ve said many times: developers are, by far, the most precious resources in a development process. When selecting a technology, developers’ affect is an important factor that should not be overlooked. If I were this CTO, I’d probably dismiss Kotlin/Multiplatform, because I’d want my iOS person to be happy at work.

Of course that’s an oversimplification of the technology selection process, and yeah, I’d still try to convince this CTO and this iOS developer that Kotlin/Multiplatform will make them both very happy and productive. You get the gist: we need iOS developers on board with Kotlin/Multiplatform because we need their voice, should we want to build a unified, inclusive, performant multiplatform mobile community.

Right now, the Kotlin community is mainly composed of three groups: the backend devs, the Android devs, and the multiplatform mobile devs. There are very few who identify as iOS developers being attracted to the Kotlin/Multiplatform narrative. This may be why, when I wrote about Robbie’s frustration with needing an Android SDK in order to compile for iOS on the community Slack, my post was mainly met with “This is not important!” replies. The iOS developers are under-represented in the Kotlin/Multiplatform community.

So, if, like Robbie, you’re an iOS developer who’s interested in what Kotlin/Multiplatform could be for you: join the conversation!
We need your voice.

This article is brought to you by Kodein Koders, a European service & training provider focused on Kotlin & Kotlin/Multiplatform. You can visit our blog, or our Youtube channel for more content.