KMP vs. Flutter - Who Will Win The Cross-Platform Battle?

Summary

In this video, the host compares two leading cross-platform frameworks, Kotlin Multiplatform (KMP) and Flutter, for mobile app development. They delve into code sharing, programming languages, compilation processes, UI rendering, native API communication, performance, and maturity. The host, an Android developer, leans towards KMP due to its native capabilities and Google's official support, despite acknowledging Flutter's stability and widespread use. The video concludes with a recommendation for native Android developers to consider KMP, especially with Kotlin knowledge, while suggesting both frameworks will coexist, catering to different developer needs and goals.

Takeaways

• 📱 Cross-platform development has been a significant aspect of mobile platforms, with native development being equally prevalent.
• 🔍 Two prominent frameworks for building iOS and Android apps with a single code base are KMP (Kotlin Multiplatform) and Flutter.
• 👨‍💻 The speaker, a native Android developer with 5-6 years of experience, finds cross-platform frameworks appealing and will compare KMP and Flutter.
• 📝 The comparison will cover various aspects including code sharing, programming languages, compilation, UI rendering, native API communication, performance, maturity, and future predictions.
• 🔑 Both KMP and Flutter support code sharing across iOS, Android, desktop apps, and web platforms.
• 💬 KMP uses Kotlin, while Flutter uses Dart, with the speaker expressing a preference for Kotlin's syntax and features over Dart.
• 🔄 Compilation in KMP depends on the target platform, compiling to JVM byte code for Android, native binaries for iOS, and JavaScript for web.
• 🖼️ UI rendering in KMP can use native components or shared Jetpack Compose code, whereas Flutter uses a canvas-based approach without native components.
• 🤝 KMP allows direct interaction with native APIs through an expect-actual mechanism, while Flutter requires a bridge layer via platform channels.
• ⚡ Theoretically, KMP may offer better performance due to the lack of a bridge layer, sharing the same memory space and call stack as the platform.
• 🛠️ KMP is considered stable and production-ready, but its UI component, Compose Multiplatform, is still in beta or alpha for non-Android platforms.
• 🔮 The speaker speculates on the future, noting Google's official support for KMP and suggesting it might have a brighter future than Flutter, which is owned by Google.
• 📚 For native Android developers familiar with Kotlin, transitioning to KMP is recommended due to the learning curve and Google's recent support.
• 🌐 The speaker believes that both KMP and Flutter will coexist, catering to different developer preferences and project requirements.

Q & A

What are the two most popular cross-platform frameworks discussed in the video?

The two most popular cross-platform frameworks discussed in the video are Kotlin Multiplatform (KMP) and Flutter.

What are the main aspects compared in the video between KMP and Flutter?

The main aspects compared in the video are code sharing, programming language, compilation process, UI rendering, communication with native APIs, performance, maturity, future assumptions, and personal recommendations.

Which platforms can be targeted for development with both KMP and Flutter?

Both KMP and Flutter allow development for iOS, Android, desktop apps, and web platforms.

What programming language does Kotlin Multiplatform use?

Kotlin Multiplatform uses the Kotlin programming language.

What programming language does Flutter use and what is the speaker's opinion on it?

Flutter uses the Dart programming language. The speaker, being a native Android developer, finds Dart reminiscent of Java and lacking the syntactical sugar found in Kotlin.

How does the compilation process differ between KMP and Flutter?

KMP compiles shared Kotlin code to native binaries for each platform, including JVM bytecode for Android, while Flutter compiles to native machine code for each platform, but does not compile to JVM bytecode on Android, instead compiling directly to machine code.

How does UI rendering work in KMP and Flutter?

In KMP, UI components are drawn from scratch using a native canvas on each platform. Flutter, on the other hand, draws everything defined in Flutter on a canvas on all platforms without the option to write native UI components for each platform individually.

What is the difference in communication with native APIs between KMP and Flutter?

KMP can directly interact with native APIs without a bridge layer, using an expect-actual mechanism for platform-specific logic. Flutter, however, requires a bridge layer through platform channels to communicate with native APIs.

What does the speaker suggest about the performance of KMP and Flutter apps?

The speaker suggests that both KMP and Flutter apps are technically native and should have similar performance, but the lack of a bridge layer in KMP might make it slightly more performant.

What is the speaker's view on the maturity of KMP and Flutter?

The speaker considers KMP to be stable and production-ready, especially without Compose Multiplatform. Flutter is also stable and widely used but is maintained by Google, which the speaker suggests might not be as committed to it as JetBrains is to KMP.

What is the speaker's recommendation for a native Android developer interested in cross-platform development?

The speaker recommends that a native Android developer already familiar with Kotlin should consider learning KMP as it leverages their existing knowledge and has recently gained official support from Google.

What does the speaker predict about the future of KMP and Flutter?

The speaker predicts that both KMP and Flutter will coexist, with KMP having a bright future due to Google's official support and JetBrains' commitment to it, while Flutter, being a Google product, might not be as favored in the long term.

Outlines

00:00

📱 Cross-Platform Frameworks: KMP vs. Flutter

The video introduces a comparison between two popular cross-platform mobile app development frameworks, Kotlin Multiplatform (KMP) and Flutter. The host, an experienced Android developer, expresses interest in cross-platform development and outlines the video's agenda, which includes discussing code sharing, programming languages, compilation processes, UI rendering, native API communication, performance, maturity, future prospects, and personal recommendations. Both KMP and Flutter are highlighted as capable of generating apps for iOS, Android, desktop, and web from a single code base.

05:01

🔍 Deep Dive into Programming Languages and Compilation

This paragraph delves into the programming languages used by each framework, with KMP utilizing Kotlin and Flutter using Dart. The host shares a personal bias towards Kotlin, finding Dart reminiscent of Java but lacking Kotlin's 'syntactical sugar.' The discussion then shifts to how each framework compiles shared code into platform-specific binaries. KMP compiles to JVM bytecode for Android, native binaries for iOS and desktop apps, and JavaScript for web apps. Flutter, while also producing native apps, compiles directly to machine code on Android, avoiding the JVM layer, and uses platform channels to communicate with native APIs, introducing a performance overhead compared to KMP's direct API access.

10:04

🖼️ UI Rendering and Native API Interaction

The host compares UI rendering techniques of KMP and Flutter, noting that while both frameworks redraw UI components natively on each platform, KMP allows for the use of native UI components within a shared codebase, a flexibility not as straightforward in Flutter. When it comes to interacting with native APIs for platform-specific logic, KMP leverages an 'expect-actual' mechanism, enabling direct interaction with native APIs without a bridge layer, unlike Flutter, which requires platform channels, adding an extra layer of data translation and potential performance cost.

15:04

🏁 Performance, Maturity, and Future of Cross-Platform Frameworks

The discussion on performance suggests that while both KMP and Flutter compile to native binaries, the lack of a bridge layer in KMP might offer better performance. Maturity is then addressed, with KMP being stable and production-ready, but its UI component, Compose Multiplatform, still in beta or alpha for some platforms. Flutter is acknowledged as stable and widely used. The host speculates on the future, suggesting Google's official support for KMP might indicate a preference over Flutter, despite owning the latter. The company behind KMP, JetBrains, is portrayed as fully committed to its success.

🚀 Personal Recommendations and Conclusion

In the concluding paragraph, the host provides personal recommendations based on the analysis. For native Android developers familiar with Kotlin, adopting KMP is recommended due to the learning curve being less steep and the recent Google support. The host believes both technologies will coexist, catering to different developer preferences and project requirements. The video ends with an invitation to a course on building cross-platform apps with KMP and a teaser for more KMP-related content in the future.

Keywords

💡Cross-platform development

Cross-platform development refers to the practice of creating software applications that can run on multiple platforms, such as iOS and Android, from a single code base. In the video, this concept is central as the speaker discusses the use of Kotlin Multiplatform (KMP) and Flutter for developing mobile apps that can run on various operating systems, emphasizing the efficiency and convenience it brings to developers.

💡Kotlin Multiplatform (KMP)

Kotlin Multiplatform is a framework that allows developers to share code across different platforms using Kotlin language. The video highlights KMP as one of the two main cross-platform frameworks being compared, noting its ability to compile shared code into native applications for different platforms, thus potentially offering better performance.

💡Flutter

Flutter is an open-source UI software development kit created by Google for building natively compiled applications for mobile, web, and desktop platforms from a single codebase. The script contrasts Flutter with KMP, discussing its use of the Dart programming language and its UI rendering approach, which differs slightly from KMP's.

💡Code sharing

Code sharing is a key feature of cross-platform development frameworks, allowing developers to write code once and deploy it across multiple platforms. The video script discusses how both KMP and Flutter facilitate code sharing, enabling developers to create apps for iOS, Android, desktop, and web from a unified codebase.

💡Compilation

Compilation in the context of the video refers to the process by which the shared code written in a cross-platform framework is converted into executable code for specific platforms. The script explains how KMP and Flutter handle compilation differently, with KMP compiling to native binaries and Flutter using a bridge layer to communicate with native APIs.

💡UI rendering

UI rendering is the process of generating the graphical interface of an application. The video discusses the differences in how KMP and Flutter handle UI rendering, with KMP potentially allowing for native UI components through its Compose Multiplatform, while Flutter renders UI components on a canvas across all platforms.

💡Native APIs

Native APIs are the application programming interfaces provided by the operating system for developers to interact with system functionalities. The script explains how KMP allows direct interaction with native APIs, while Flutter requires a bridge layer, which can impact performance and ease of use when implementing platform-specific logic.

💡Performance

Performance in the video refers to how well the applications built with cross-platform frameworks run in terms of speed and resource usage. The script suggests that while both KMP and Flutter compile to native code, the lack of a bridge layer in KMP might offer better theoretical performance compared to Flutter.

💡Maturity

Maturity in this context refers to the stability and readiness of a technology for production use. The video notes that while KMP is considered stable and production-ready, Compose Multiplatform is still in beta or alpha for some platforms, suggesting it might not be fully mature for all use cases.

💡Future assumptions

Future assumptions are the speaker's personal predictions or speculations about the direction in which the cross-platform development market might evolve. The script includes the speaker's thoughts on the potential bright future of KMP, supported by Google, and the coexistence of both KMP and Flutter in the market.

💡Recommendation

Recommendation in the video is the speaker's personal advice to the viewers on which cross-platform framework to learn or use. The script concludes with the speaker recommending KMP for native Android developers familiar with Kotlin, based on its current support, stability, and potential future growth.

Highlights

Cross-platform development has been a significant aspect of mobile platforms, with native development being equally prevalent.

Two frameworks stand out for building iOS and Android apps from a single code base: KMP (Kotlin Multiplatform) and Flutter.

The video compares KMP and Flutter across various aspects such as code sharing, programming language, compilation, UI rendering, native API communication, performance, maturity, and future predictions.

Both KMP and Flutter allow for code to be shared across iOS, Android, desktop apps, and web platforms.

Kotlin Multiplatform uses Kotlin, while Flutter uses Dart, which some developers find less enjoyable due to its similarities with Java.

KMP compiles shared code into native binaries for each platform, including JVM bytecode for Android and JavaScript for web applications.

Flutter compiles to native code on each platform, but does not compile to JVM bytecode on Android, instead going directly to machine code.

In KMP, UI components can be made native if desired, utilizing the platform-specific components provided by the native development kits.

Flutter does not offer a straightforward way to write native UI components for each platform individually.

KMP uses the expect-actual mechanism to handle platform-specific logic, allowing direct interaction with native APIs.

Flutter requires a bridge layer, known as platform channels, to interact with native APIs, which can impact performance.

Performance-wise, KMP apps are considered pure native apps without the bridge layer that Flutter has, potentially offering better performance.

Kotlin Multiplatform is stable and production-ready, but Compose Multiplatform is still in beta or alpha for some platforms.

Flutter is stable, maintained by Google, and widely used, giving it an advantage in terms of maturity.

Google's official support for Kotlin Multiplatform indicates a promising future for the technology.

The presenter believes that both KMP and Flutter will coexist and cater to different developer needs and project requirements.

For native Android developers familiar with Kotlin, adopting KMP is recommended due to the learning curve and Google's support.

The future of cross-platform development is expected to include a variety of technologies, with each having its place.

The video concludes with a recommendation for developers to learn KMP, especially if they are already working with Kotlin and Android.

Transcripts

hey guys and welcome back to a new video

crossplatform development has almost

always been a thing on mobile platforms

just like native has always been a thing

but if we take a look at the options we

have to build both IOS and Android apps

with one single code base and then two

Frameworks Stand Out KMP or cotland

multiplatform and flut and if you're

maybe a native Android developer who now

wants to get into crossplatform

development or maybe you're also an iOS

Developer who's watching here I'm a

native Android developer I've been

developing Android apps for 5 six years

but to be honest crossplatform

Frameworks have always been quite

tempting for me as well and in this

video I will compare the two most

popular and in my opinion viable cross

platform Frameworks we have for mobile

apps so KMP and flatter in a lot of

different aspects and categories those

categories are on the one hand code

sharing so how does it really work that

we just put our code at one place and we

get two apps out of that then I will

compare the programming language each

framework uses I will compare how the

compilation works so how the shared code

is actually compiled and what kind of

result we really get out of that

compilation for both KMP and flatter

apps then I will take a look at how UI

rendering works so how do you really

draw UI on the screen I will compare how

it actually works to communicate with a

native apis so how we Implement logic

that is really platform specific like

showing a notification for example I

will also take a look at performance

maturity so which framework is safer to

use at the moment and then I will make

some assumptions about the future so in

which direction I think the

crossplatform market will go to and last

lastly I will just share my own opinion

about those Frameworks and give you a

specific recommendation which framework

you should learn right now so let's talk

about code sharing which platforms can

we actually develop for with KMP and

with flutter and in this regard both

platforms are actually quite similar and

quite comparable since both these

platforms allow us to put our code in

one single place and get executables for

multiple platforms out of that so

specifically those platforms are iOS

apps Android apps their desktop apps and

even web is supported by both k&p and

flutter so in this regard it's a draw

here next up talking about the

programming language well as the name

cotland multiplatform already says it

uses cotland surprise so we just have

our sheared logic written in pure

cocklin Cod which we can then just take

and use for all those different

platforms I just mentioned on the other

hand flusher used the programming

language and while I am of course a

little bit biased here as a native endro

developer who uses cotland all day I can

only say the last time I used Dart which

is quite some time ago to be honest but

it wasn't enjoyable it really reminded

me so much of java and there was not a

lot of syntactical sugar at least not as

we know it from cotlin and that's also

the impression I get when I talk to

flutter devs who have also tried cotlin

coming to the next category and that is

compilation so how does the framework or

the compiler really take the shared code

of the framework and compile it down to

something that runs on all these

different platforms and while these

Frameworks are similar in that regard

there is still some differences so if

you take a look at cotton multiplatform

then it really depends on the target we

want to compile an app for that decides

how the compilation will work so that

means if we have a KMP project that

should run on Android then for Android

the Cartland compiler will compile the

shared Cartland code just to jvm bite

code to to Java virtual machine bite

code that is the primary format Android

apps are just compiled to which Android

understands so that is native for

Android on iOS fiber we don't have a jvm

since that just works with the native

binaries so just a bunch of zeros and

ones that represents some kind of

instructions for the CPU of iOS devices

but here again the coton compiler will

take the shared code and compile it to

the those native binaries that run on

iOS so it's also a native IOS app and

the same also comes for desktop app so

here we have the option to actually

compile it down to jvm bite code since

we have the jvm available on desktop but

it's also reasonable to compile it down

to native code which can also be run on

a desktop environment lastly if we take

a look at web applications then the

cotton multiplatform code will really

just compile down to JavaScript the

programming language that will used

everywhere in web so in regards to coton

multiplatform all those platforms really

get native applications out of our

shared cotton code that's very cool of

course since native usually also means a

better performance than non-native if we

take a look at flutter on the other hand

we also get native apps on all these

different platforms that's something

many people don't know I feel like

because you always hear okay KMP apps

are actually native while flutter apps

are not and I will also share in a

moment why that is actually the case or

why people say this but technically

flutter apps compile to native code on

each platform as well the only

difference for flutter is that it does

not compile to jvm bite code on Android

but rather to machine code directly but

that can also run on Android devices

let's next compare the UI rendering so

how do we achieve that we put our UI at

one central place and it looks the same

on all these different platforms these

points are similar again but there are

still some slight differences so on

carton multiplatform all UI widget so

all composes if you're using compos

multiplatform that is the Assumption I

have to make here because otherwise you

can't share UI code in cartet

multiplatform but if you're using compos

multiplatform then the entire UI so your

entire jetpack compos code in the

multiplat project will be drawn from

scratch so you can think of this as just

having a native canvas component on iOS

side and they compos multiplatform

framework will then figure out okay this

is our compost code and this is how it

needs to translate into canvas

coordinates so we just draw that on the

native canvas and iOS so the UI

components we Implement in composed

multiplatform are not technically native

components but you have the option to

make them native components that is very

unique to carton multiplatform so if we

want to use the platform specific

components that the in this case Apple

developer kit provides here in Swift UI

in that case we can do that in C

multiplatform since it allows us to

write platform specific code natively

for every single platform so if we

really want those native Apple

components then we just need to

implement those in Native Apple code in

Swift therefore with flutter on the

other hand drawing the UI works very

similar than on compos multiplatform

that it will just draw everything uh

that we Define in flutter on a canvas on

all platforms that's fine for sharing

but with flutter we don't have the

option to actually write native UI

components for every single platform

individually at least not in an as

straightforward way as we have with KMP

coming to the next category and that is

how do we communicate with Native apis

so while we can of course share a lot of

code between all platforms with these

two Frameworks there will always be

scenarios where specific platforms need

specific logic so imagine you're

building a mobile and a desktop app on

desktop apps the file system even on

Windows environments works completely

differently on Mac OS environments and

that is completely differently how it

works on Android environments if we now

want to share some logic regarding the

file system then we somehow need to tell

each platform how it works with the file

system specifically from that platform

and in KMP that works with the expect

actual mechanism so in our common code

we can just expect a specific type of

class and then we have actual

implementations of that class for every

single platform individually so we say

okay on desktop interacting with files

works like this this is the file path

for desktop this is the file path for

mobile oh on Android we actually also

need permissions these kinds of things

we can uh Implement very individually

for every single platform on KMP and the

big Advantage here with KMP is that we

can directly interact with the native

apis so the native apis would really be

those apis the platform itself provides

so if we think of showing a notification

for example then there is already a

system API in Android that provides

functionality for us that we can call in

order to see a notification or Android

device showing a notification on iOS

Works differently but there's also a

system API that Apple provides to us and

with KMP that is really unique about it

we can directly talk to these two system

apis without any Bridge layer that does

the translation from or cotlin code to

the native code or to to the to the

native apis on flutter that works

differently because flutter can't

directly call those native apis while

flutter can of course somehow interact

with Native apis otherwise this would be

quite a problem there is still a bridge

layer necessary in flatter Earth so

these are called platform channels

actually how how that works so the dart

code will just use such a platform

channel so just a stream of data that

can be used to exchange bits and btes

and this platform Channel then leads to

the native apis but as you can see there

is a bridge layer so some kind of

channel that needs to interpret the

flatter code and translate that to calls

to the native apis and for the common

functionality you might want to share I

don't know camera access recording video

showing notifications flatter has all

kinds of plugins also from the Community

which you can just use in your shared

code and those plugins were then written

in native code for every single platform

so you can use these out of the box

however with flutter you really don't

get around having this platform channel

so this intermediate step kind of which

is of course just an extra layer data

has to pass Which is less performant

than if we just call the native apis

directly like we can do with KMP next

category is performance which framework

actually builds the better performing

apps and I have to say I will really

focus on the let's call it theoretical

per performance because in order to

truly compare the performance between

KMP and flutter we would need some kind

of real studies that compare the

performance of flutter and KP apps where

the apps exactly the same in different

categories of apps and so on and I did

not find such studies so all I can say

here is that KMP apps as I said are pure

native apps just like flatter apps but

there is not this bridge layer that I

talked about so Cartland multiplatform

apps actually also share the same memory

space and call stack as the platform

that it's running on that is not the on

flutter apps so on the one hand as I

said on flutter apps we have this bridge

layer which does the translation from

the darkart code to the native code or

to the native API calls and flutter apps

are also running in their own kind of

isolated environment on the dart VM Dart

virtual machine so that means they also

don't share the same memory space and

call stack as the platform that's

running on and this does not make

flutter apps true native apps so while

they compile to Native binaries

technically they are still not really

treated as native apps and that's really

what people mean when they say KMP

brings native apps well flatter does not

so let's talk about maturity next

according to Jet brains carton

multiplatform is stable and if something

is stable then it's also considered

production ready that's also my

experience when I've been using that

it's quite stable if we just use Carton

multiplatform and I rarely run into any

weird issues with it however we need to

take a look at compos multiplatform

individually because compos

multiplatform is really just some kind

of add-on to C multiplatform that allows

us to also share UI code between all

those different platforms and composed

multiplatform is not officially St say

that it is for Android since jet compos

is a technology that was primarily made

for Android but for the iOS side for

example it is in beta currently and also

for web platforms it's even an alpha so

compos quity platform still has a path

in front of it and to be honest if I

would have to seriously build a

production ready app with a

crossplatform framework then at this

point I wouldn't feel confident with

using compos multiplatform yet so I

think right now is the perfect time to

try it out to use it in your hobby

projects to experiment with it but I'd

still be careful with production apps

since even if it might look very cool on

the first glance the dangers of such

unstable Technologies are always that

they might lead to issues you don't even

think of at first but at a much later

time so imagine you already built maybe

a 10 15 screen app with composed

multiplatform everything was cool until

then but then you start to experience

weird performance issues or whatever and

at that point it's too late if you then

want to switch the technology you need

to rewrite everything or at least the UI

layer in C multiplatform so that's why

thinking about this from the very

beginning on really matters here so this

is honestly a point that I have to give

to flatter at this point since flatter

has been around for quite some time it

is stable it is maintained by Google and

also broadly used and applied for lots

of different apps but if we really

compare cotland multiplatform so without

compose with flutter here then I think

these are even and getting to the last

category before I want to share my

personal opinion and recommendation for

you let's talk about future

unfortunately I forgot my crystal ball

here so everything I say here are just

my personal assumptions of course but

maybe you noticed that Google actually

announced during Google's yly event

Google IO that cotland multiplatform is

now an officially supported technology

by Google and I think this has been a

marker for a very bright future of

carton multiplatform and you might not

think okay but flutter is actually owned

by Google and KMP is only supported by

Google how does it make that better that

Google supports coton multiplatform than

that it ouns flutter I personally think

the fact that Google actually decides to

officially support a technology don't

own because cin multiplatform is owned

by jet brains but still Google decided

to officially support it even though

they have their own technology that does

exactly the same but that actually

solves the same type of problem at least

the fact that they decided to do so

could show that Google Sees more future

in C multiplatform than in fletter

because why else would they support a

technology they don't even own and this

of course just conspiracy time I could

be very wrong with that assumption but I

still find that very interesting that's

like Samsung buying Apple stocks why

would they do that if they have their

own stocks and one more reason why I

really believe that c multiplatform will

have a very bright future is that the

company behind it jet brains really sees

it as their baby if you follow them on

social media and how they promote it you

really notice that they they do

everything in their power to make coton

multiplatform succeed and a viable

technology however if we take a look at

flatter at the present moment then yes

that is officially maintained by Google

it also belongs to Google it's a Google

product but the past has shown that

Google is actually not very afraid of

suddenly stopping support for products

they are own morning and I'm not saying

that this will happen to flatter soon no

I don't think that but I am saying that

I would trust Google much more to

abandon flutter then I would trust jet

brains to abandon KMP because I don't

see flutter as Google's baby while I see

KMP as jet brain's baby and Indian

Google is just such a giant company that

if flutter would be gun Google would be

at exactly the same position as it is

right now well I think if jet brains

would suddenly lose KMP for whatever

reason that would really hurt their

reputation of course jet Brain still has

some other awesome products like all

those cool idees but I see carton

multiplatform as one of jet print's cool

products so what does now my personal

opinion what do I recommend you to do

right now or if you want to learn

crossplatform which technology should

you really pick and my opinion here is

really clear if you are a native Android

developer and you know cotland then

jumping into KMP is just a no-brainer

from my side because you really already

know most of what you need for KMP

because in the end you know the

programming language you know many

Concepts that are used in Cut

multiplatform project especially with

the just announced Google support which

will add all those jetpack libraries we

already know from Android also for KMP

so all that will not be new to you the

only thing you really need to learn is

how you implement patform specific code

so the learning curve is not steep at

all however that also doesn't mean that

I think flatter will go anywhere anytime

soon I personally think both

technologies will just coexist I

personally am also convinced that there

won't be just that one single way in

future of building mobile apps people

have been saying that for decades that

specific technology will take over all

other jobs will be lost I don't believe

in that I think Native will still exist

there will be native iOS developers

native Android developers there will be

crossplatform developers with flutter

there will be crossplatform developers

with KMP and all those will be viable

technologies that are viable for

specific set of people specific set of

goals and specific set of requirements

and especially if we also take a look at

the iOS side if we take a look at Native

iOS developers I have the feeling that

they often just live completely in their

own world and that Technologies like C

multiplatform completely go past them so

if you want a general recommendation I

would say go KMP if you are already

building flatter apps and you enjoy that

then this is not a reason to switch from

that just because KMP is Now supported

by Google I don't believe that this is

the end of flutter however I still

believe that KMP has a very bright

future and that's also why you will see

much more CET multiplatform and composed

multiplatform tutorials in future on my

channel and if you want to learn how you

can build a full crossplatform app in

Cotton multiplatform with a native UI

check my course down below other than

that thanks for watching this video I

will see you back in the next one have

an amazing rest of your week bye-bye