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

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

Channel: Philipp Lackner

Views: 34,636

Keywords:

Id: dzog64ENKG0

Length: 16min 18sec (978 seconds)

Published: Sun Jun 09 2024