The Fundamental Problems with cross-platform frameworks
The idea of true cross-platform development is lucrative. That’s probably why there are so many attempts trying to make it work, latest being flutter. However, I believe that there are fundamental problems with the approach and creating a truly successful cross-platform stack might be impossible.
Not one team but three
A CTO might see cost cutting potential in cross-platform in form of a single team instead of hiring separate teams for iOS and Android. Sooner or later in almost every project reality will fight back. iOS and Android phones have a lot of native components that must be accessed in most projects. These might be things like detailed battery use optimisation, location management, security systems etc. The result is going to be that the project will eventually need three teams instead of the planned one: cross-platform team, Android team and iOS team.
Always behind
Development speed of, especially UI-frameworks, is really fast in the native environments. For example on Android the Material Components, Motion Layouts, Constraint Layouts, etc have been introduced very recently expanding the native developers’ toolkit simultaneously upping the expectation level of design on the platform.
Similar changes or support to these new systems will take time until they are supported in the available cross-platform tools.
As cross-platform tools need to support both iOS and Android UI implementations the tools are always bound to the lowest common denominator. If the same code must run (or compile to) on both platforms the result can only very rarely utilise the best and unique features of the individual platform.
Young, naive framework
My background, before Android, was J2EE backend development. In that world we saw rise of a new framework nearly every month. These new frameworks always promised easier, faster and more maintainable code. Almost without exception the claim was true for limited set of examples but when the frameworks were moving towards feature completion the creators realised why the other, more mature, frameworks were complex and required more code. In reality, in real projects, the complexity was needed and it was built into the more mature frameworks for a good reason, solving real world issues.
The demo effect
I’m not talking about the famous demo effect of your demo 100% working but immediately failing when you’re trying to show it to someone else. I’m talking about something pretty much exact opposite of that.
It has become too common to see a demo of a cross-platform framework in a conference talk or online demonstrating how easy and fast it is to get started and how clean the syntax is by by building a simple app as live coding. The value of this kind of demonstration is fairly superficial. No matter what the framework, real issues raise with real apps. A demonstration use case is usually (always) chosen to be something the framework supports really well. Great, we learn that the demoed tool works really smoothly for something simple. It is usually compared to native tools and explained how much easier that use case was to do on the cross-platform framework. However, the devil lies in the details. The native platforms, both iOS and Android, have been evolving for a long time. The mature tools have already solved issues that the new frameworks have not even encountered. The illusion of complexity is actually maturity of solving the difficult use cases. Complexity-to-work curve is front loaded but flat on native tools making real projects actually simpler.
Cross-platform as a replacement for a website
Maybe the suitable domain for cross-platform is not so much in replacing apps but replacing websites? There is a lot of debate going on about web vs. apps. Which is better, which will kill which etc. I believe both will live on. Web has its place and app have theirs. Cross-platform tools feel like they exist somewhere in between or in the overlap of the two.
Web apps are becoming very good. PWAs (progressive web apps) are the hot topic and for a good reason. That said, I’m convinced that a lightweight app can sometimes do a better job than a PWA. You have to choose carefully though. When web is better do not force it into an app. Browsers are awesome! But what about a conference or event companion. I feel more comfortable having the schedule available in an app. Maybe it changes and I get notifications (I know that the web also supports them) or maybe location based system can do something interesting and useful. It just feels that an app would be a good addition to the event website.
Flutter
Some of the reasons I wrote this article are coming from the popularity of flutter, a cross-platform framework from Google. I see flutter as the best try todate to tackle the problem of having to write apps twice. It’s not without faults though and I see all of what I wrote above applying to it.
Google’s long term goal for flutter is not really clear yet. It might be a short term experiment or it might be Google’s bet to the future. We’re certainly keeping our eyes open at Snapp Mobile and might even be trying it on some projects where it feels like a good fit.
Jasper wrote a comprehensive overview of the current state of Flutter. It’s well worth reading even if you weren’t a flutter fan.
https://medium.com/snapp-mobile/multi-vs-cross-platform-in-the-age-of-flutter-6e76920028b6
A Better Approach
My scepticism of React Native, Flutter and others doesn’t mean that I don’t believe there are things we could do better. I think currently Kotlin Multi Platform / Native is the one showing greatest promise.
Why Kotlin multiplatform approach is better?
Kotlin multiplatform is not an all-or-nothing approach. It integrates seamlessly to our current development methods, tools and practices. The idea of Kotlin multiplatform is that we share only platform-independent parts between the platform and write the rest of the project with the best available tools, the native frameworks.
A great place to get started with Kotlin multiplatform is Dmitry Jemerov’s talk at Kotliners conference.
This approach speaks to me. It’s something I have tried before in form of J2objc (https://developers.google.com/j2objc/) and moving complex shared logic into JavaScript and executing it in a container. Neither approaches worked. The reason wasn’t the fundamental idea of sharing logic but the technical implementation. J2objc was too limited and the JS approach was way too much work. I think Kotlin multiplatform solves the technical limitations of the attempts that came before it.
TL;DR
Right tools for the right job. Cross-platform frameworks have an intriguing promise. Past tries like Cordova or React Native are just bad. However, we tend to learn from past mistakes. Someone, someday will get it right. If it is Flutter or not remains to be seen. Until then I, personally, will be boosting my native Android skills amended with new developments in Kotlin multiplatform. But I’ll be keeping my eyes open for sure and encourage my business partners to dive into things like Flutter to get first-hand experience on the promise.
