Cross-Platform? We Don’t Say That Around Here Anymore

Touchlab is a mobile innovation consultancy with Kotlin Multiplatform expertise.

This is the 1st post in a 2 post series.

Post 2: “The Future of Cross-Platform is Native” by Touchlab Director of Project Strategy, Justin Mancinelli.

If you’re interested in learning more, we’re hosting a Kotlin Multiplatform webinar on Thursday, March 28th, 1–2 PM EST. You can register here.

In the application development world, you hear the term cross-platform all the time. The idea of “write once, run anywhere” is like an unreachable promised land for management stakeholders, and an unrealistic and frustrating reality for developers.

At Touchlab, we don’t use the term cross-platform. We prefer “multiplatform” — for a couple of important reasons.

Baggage

First, cross-platform has a lot of baggage because of existing development platforms. PhoneGap, Titanium, Xamarin, Ionic, RubyMotion… the list is long. Initially, these solutions went through a phase of exuberance, followed by disappointment. Developers were frustrated with not being able to express the UI how they wanted, unavailability of features on their wish list, and invariably, teams would end up managing three platforms — cross-platform, iOS and Android. For product owners — and ultimately, the end-users — the UX was rarely satisfying.

Note: If your organization doesn’t care about native, traditional cross-platforms solutions might be okay. Context matters.

Wide Net

Second, cross-platform really is a super-inaccurate term because the solutions that are lumped under it are wildly different. We believe you need much more nuanced terminology to describe coding for a variety of platforms. The way we see it, at one level, when a native developer sees anything that isn’t Java, Kotlin or Swift, they’ll lump all alternatives into cross-platform and immediately (without pause) classify them all as bad based on a singular bad experience with a solution. “If it’s not native, it’s bad. I would know, we tried PhoneGap once.”

And while the world has always been ready for shared code, it’s rarely been implemented well. The good news? There are now better options to make things really work.

Multiplatform

At Touchlab, we’re about shared logic that interops natively with the platform you’re working with, homogenized logic and libraries — all of which should occur below the UI and be performant. Simply put, our multiplatform approach can’t and shouldn’t be compared to “cross-platform.” It’s not an apple-to-apple comparison.

We call it “post-platform thinking”. It doesn’t matter what platform you’re delivering on, because the ultimate goal is to have a well-tested and well-architected backend, middle communication layer, and front-end architectural layer that’s all homogeneous.

So, if as developer can build the logic from the back-end to the front-end, and model the logic for the UI in a microservices model, the developer’s job becomes one of service aggregator rather than implementer. The iOS developer can focus on UI and UX, not on implementing the services themselves.

Kotlin Multiplatform

And that’s what Kotlin Multiplatform does: natively shared, performant, tested architecture with a fantastic developer experience and ecosystem. It enables you to do runtimes efficiently, and have the ability to test — all of which makes shared logic a lot more possible. The architectural stuff is well tested, it’s well engineered, it’s economical and efficient from a development standpoint, so it’s an easy platform to move to another UI.

So why is Kotlin the way to go? Here’s the thing: anything that requires you to make large decisions and potentially large rewrites, perform large retrainings and rehirings, or anything that has to share UI or doesn’t work well with a native platform is, well, very risky. The fact is, Kotlin Multiplatform is not risky in that same way, and that’s why we’re working with it at Touchlab.

Kotlin Multiplatform is a modern language with enthusiastic community support that allows native optional interoperability with the platform on which you’re working, with straightforward logic and architecture. Android, iOS, desktop platforms, JavaScript, and WebAssembly. For me, the idea behind Kotlin Multiplatform is that you can invest in this way of building logic, and you don’t have to guess which way the industry is going to progress in the next 5 or 10 years. If everything moves to the Web, you can support that that. If it all goes mobile, you can support that too. And that’s true multiplatform.