Kotlin Multi-Platform Vs Cross-Platform (Flutter)

• What is the difference?
  • Definition: Multi-Platform
  • Definition: Cross-Platform
  • Strengths and Weaknesses
    • Superficially
    • Under the Cover
• Koltin Mulit-Plaform vs Multiple Platforms
• Multi-Platform as the foundation of cross platform
• Combination: Multi AND Cross Platform

What is the difference?

There is no universal definition of these two terms, so definitions to be used here must be identified. In a way, I am using the ‘google definitions’, as defined in two environments supported by Google: Kotlin Multiplatform and Flutter.

Multi-Platform Definition: (as with Kotlin Multiplatform)

Multiplatform is the process of building ‘native apps’ while sharing platform independent code.

In other words, a system where a program for multiple platforms (eg iPhone and Android) makes use of both code specific to each platform, together with common code shared by both platforms. Common code can call platform specific code, where there is an implementation of that code for each platform. With two platforms, as with iOS and Android, there will be three pools of source code:

• common
• android
• iOS

Cross-Platform Definition: (as with using Flutter)

A system allowing an application to be deployed on multiple platforms (eg. iPhone and Android) using the exact same application code. A flutter application for both Android and iOS is comprised of only a single ‘pool’ of source code. All application code is effectively common.

Apparent and Underlying Strengths.

• Apparent Strengths:
  • Multi-Platform
    • More flexible adaptation to each platform with full platform API available
  • Cross Platform
    • Faster Development as only one code set is required
• Underlying Strengths
  • Multi-Platform
    • Can implement cross-platform, multi-platform or mix
    • Uniform environment for libraries and applications
  • Cross-Platform
    • Enforced Cross-Platform Libraries

Multi-Platform vs Multiple Platforms

With mobile development prior to Kotlin Multi-Platform, the choice has been between cross- platform (eg. Xamarin, React Native, Flutter) and two entirely separate developments:

• one for Android (written in Kotlin/Java and developed using Android Studio
• another for iOS (written in Swift and developed using XCode)

An entirely different languages and development environment for each application. There are many mobile development comparisons, even some labelled cross-platform vs multi-platform, that at actually comparing cross-platform vs multiple platforms.

Multi-Platform, using the same code and development tools for a common part of the application is new to mobile development, although well established outside the world of mobile.

The ‘Common’ box, with a single codebase and set of development tools is the new part. Being new to mobile means that in the mobile world even when using Kotlin for ‘Common’ code shared between both Android and iOs, part or even of the iOS ‘actual implementation’ is written in either Swift or Objective-C, and thus still introduces a second language and set of development tools.

While the goal of Kotlin Multi-Platform is for all code, even for iOS, to be able to be written in Kotlin with a single set of development tools, there is also a focus on allowing the use of other languages and tools for parts of the project.

While articles such as this one ‘Multi vs Cross Platform in the age of Flutter‘ (love the a modern and mature programming language) are really considering ‘multiple platforms’ rather than ‘multi-platform’, largely because in January 2019, Kotlin multiplatform was in complete infancy.

The comparison is however still useful:

Building the same app twice is a reality for native development. Aside from the additional effort and cost, it is also challenging to keep feature parity for two apps over time. However, stories from the trenches reveal that cross platform code does not achieve a one-size-fits-all promise.

From ‘Multi vs Cross Platform in the age of Flutter‘

This balance of native vs ‘one size fits all’ is still relevant although building the same app twice is no longer fully the reality for native development, with even the quoted example of AirBnB, who moved from Cross-Platform to, firstly fully separate native platforms, but are also now moving to Kotlin Multiplatform. The dream of multi-platform is to allow reducing any duplication of effort to only remain when developers choose to provide differences between platforms.

Multi-Platform as the Cross-Platform Foundation

Consider writing a Flutter application to be deployed on both Android and and iOS. A single application can generate both programs, because the application makes calls to functions that are in libraries which, by nature of being cross platform, have an implementation of every function within the library for each platform.

But now consider writing libraries for each platform. At some point code must interface to the native APIs of each platform, and that code will vary from platform to platform. Libraries consist of a mixture of code which is by nature common to all platforms, but will also have code specific to each platform.

Writing the libraries requires a multi-platform system. Some code will always be required that is platform specific, although with cross-platform, all the platform specific code resides within the libraries.

When only a very limited number of libraries must deal with the multiple source sets required to deal with the mixture of platform specific and common code, it is more efficient to simply deal with a less streamline ecosystem for multi-platform while coding those libraries, than to produce a specific tool chain to enable more streamlined production of multi-platform programs and libraries.

In fact, any language that can be compiled to produce code for multiple operating systems can be used for multi-platform development. Both the Dart (the language of the Flutter system), and Kotlin provide for multi-platform compilation. The C/C++ languages have been the dominant Multi-Platform Languages for many years, as C or C++ compilers have been available for almost every platform, and there have been few competitor languages compiling to native code.

Multi-Platform is not new, it is just new to Kotlin.

Multi-Platform is required as a foundation before a Cross-Platform system can be built.

Cross Platform: A Framework as a Virtual Platform.

One of the most popular cross platform systems of computing over the last 25 years has been the Java Virtual Machine (JVM). The JVM system provides a complete virtual computer with a virtual CPU as well as virtual peripherals and the promise of “write once, run anywhere”.

Between the JVM and the popularity of “dynamic” or “scripting languages”, there has been a long period of popularity of ‘non-native’ cross platform solutions (Java, Python, Ruby etc all provide for cross platform), but with the recent rise of languages compiling to native code and providing alternatives to C/C++, many newer cross platform solutions provide the ‘virtual platform’ where applications only write to the cross platform framework display coms and other peripherals, but produce a specific application version for each target platform.

With cross platform code, the application is written in terms of the API of the framework. Even if the target platforms are Android and iOS, the application is not written in terms of the Android or iOS APIs, but instead, the application only uses the API for framework. From the perspective of the application, the framework is the target platform.

The ‘Native Code’ Revolution.

Java, PHP, JavaScript, Perl, Ruby, Python, C#, Scala, Groovy, Clojure, and even Kotlin and Dart: All at some level interpreted or a VM. Most also cross platform. For a significant period, ‘native code’ was simply not in favour, and it seemed all the emerging languages were at some level were interpreted, with a further trend was towards dynamic languages.

Implementing interpreted or virtual machine based languages requires a native compiler, and C/C++ reigned supreme. All of the languages on that list relied in part on C or C++ code as part of their development. None of the languages made being a viable alternative to C or C++ a key part of their goals. Coders of system utilities, Operating Systems, and language implementation requiring a language that produced native code, generally used C or C++, or the Apple preference, Objective C.

Then a revolution: Native Code and Static types returned to being in fashion.

As pendulums do, the compiled/static vs interpreted-vm/dynamic pendulum began to swing back. First Golang 2009), Rust(2010) and later(2104) and Swift all emerged as new native code languages that provided a new alternative to the C based C, C++ and Objective C language and through the V8 Javscript engine(2008), JavaScript could now also compiled to native code. Languages (Including both Dart and Kotlin) previously only running on VMs, or interpreters added ‘native’ capability.

At the time of writing in 2020, there is a clear trend to both native code, and statically typed code.

Kotlin Multi-Platform: What’s New?

As already stated, multiplatform is not a new thing.

The Java JVM, Python, Ruby and the other dynamic languages have multiplatform implementations build on C/C++. Multiplatform builds in C/C++ are mature and well tested.

Clearly, Kotlin does bring language advances over C/C++. I searched for a language comparison, but could not find anything useful. I will post a comparison, but in summary, while C/C++ has its strong points, coding in C/C++ takes longer than with Kotlin. C/C++ is most at its best when coding device drivers and systems code, and C/C++ is at its worst when coding applications.

Kotlin Multiplatform firstly provides a modern language alternative to C/C++ for multiplatform code, and in particular multiplatform applications.

Further, Kotlin Multiplatform adds the JVM as a platform, an option not really viable with C/C++ or any other multiplatform option. This not only enables applications with roots in Java/JVM code to branch into multiplatform, brings Gradle and other elements of the JVM ecosystem along for the ride.

Flutter: A Cross Platform for 2020

Cross platform: complete applications that can run on different platforms, is not exactly new either. The catch-phrase of Java was “write once, run anywhere”, because the promise of Java was to deliver cross-platform. Flutter delivers cross-platform native code, which is not new either, as this has been possible using Qt since 1991, and is available for iOS, Android, desktop and the web. Flutter brings a reactive GUI. This leaves the most obvious competitor as React-Native. The overview is that the appeal of Flutter vs React-Native is more about details than one single point of difference.

Dart may not be the perfect language for writing code (although the combination of just-in-time compilation and ahead-of-time compilation does aid rapid development), but just as ‘Rails’ providecd a ‘hero’ framework for the language Ruby, Flutter provides a hero framework for the language Dart.

A significant number of the head to head comparisons of Flutter in comparison with other cross-platform, mobile capable, development environments, suggest Flutter is the best choice for a project in the current environment.

At this moment, Flutter has a claim to being ‘king’ of environments for rapid production of multi-platform mobile apps.

Kotlin Multiplatform: Are We There Yet(1.3)?

Today: Kotlin multiplatform is still actually in Beta, but is in use in many largescale mobile applications providing common code between iOS and Android.

Despite large organisations (such as Autodesk, VMWare etc) already using Kotlin Multiplatform, current use has limitations.

The ‘tier structure’ as of release 1.3 only allows for either code common to all platforms and code unique to each platform. The reality is there can be a need for sharing code between some platforms but not all. This is planned to be addressed for release 1.4, but is not yet available.

Further, while current applications share code between iOS and Android mobile apps, code specific to iOS is still often written in Swift. Providing for full iOS applications in Kotlin, and thus a completely Kotlin multiplatform mobile solution is close at time of writing, but not quite ready. However, it has been announced that during 2020 a release is planned that will allow complete iOS apps written in Kotlin, and there are tools already to allow complete cross platform UI code for both iOS and Android.

. oes not yet allow for shared code common to some modules but between and /coprovides a i which Qt does not provide, but then, react-native does.

KDE

Choice: Flutter or Kotlin Multiplatform?

Unfortunately, there is no universal answer. Currently there is a case for Kotlin Multiplatform and a case for Flutter cross-platform. In theory, once multiplatform and Compose reach the mainstream, Kotlin will also be a viable cross platform choice. Until that time, the choice is between multiplatform and cross-platform.

The Case For Kotlin Multiplatform.

The first key point is that multiplatform enables cross platform. Multiplatform can deo everything cross platform can do, and more.

IceRock development is a team that has chosen Kotlin Multiplatform, and presented at KotlinConf. As an early mover, they created their own cross-platform libraries for GUI and Sockets, which are now open sourced community projects. Java has provided strong background on how how there are points where cross-platform reaches limitations, providing no application access to platform specific features and enforcing views how to make things cross-platform. Multiplatform gives control over how things become cross platform and access to all native APIs. The larger the scale the project, the longer continuous development and updates will continue, the more relevant these points. Over 40 developers working for over 5 years on 80 projects, together with profiles of some the clients, suggests IceRock targets major developments.

In summary, the points in favour of multi-platform are:

• A Multi-Platform foundation can provide a choice of cross platform frameworks and libraries, including the power to ‘build your own’.
• time and time again it has been shown there are limits to cross-platform
• Coding in Kotlin provides advances over coding in Dart, particularly for larger projects

The Case for Flutter.

Consider the adage from Python: There should be one-- and preferably only one --obvious way to do it. Why other why bother with a choice between frameworks, over one single framework with the benefits from all efforts supporting the one single framework.

Kotlin Multi-Platform is too new to yet boast a single Framework as mature as Flutter. Flutter and mature and straightforward.

While the Dart language may not have the appeal of the newer and more popular native development languages of either Kotlin or even Swift, it does have just in time compilation which delivers an unrivalled ability to have the impact of changes show live during development. With the code relegated to the ‘glue between library calls’, Dart is a perfect match for rapid development.

The main points become:

• A mature full framework available now- less time lost making choices
• Rapid Development
• Flutter programs written in Dart support live updates views what the code does

Conclusion

Both Flutter and Kotlin are useful choices. The shorter term the project, the better fit Flutter would seem to be. Kotlin Multiplatform does appear to have a better potential, but being the less mature product than Flutter, less of that potential is realised at this time.

Flutter is a Framework build on foundations of the Dart ecosystem. The foundation is not as strong as Kotlin, but who checks out the foundation? Given growing popularity, perhaps the foundation will also improve?

Kotlin Multi-Platform is a foundation with no Flutter equivalent ready made framework for cross-platform. The foundation seems the best, but the frameworks to fully realise potential are either very new or still being built.