Kotlin Multiplatform at Stable and Beyond

good to go okay I'm I'm told we are good to go and people are still filtering and that's all right let's uh get started uh hi everyone it's great to be back here uh thanks to the organizers for having me thanks for you for coming to this talk my name is Martin Brown I'm a developer Advocate at jetbrains working on pretty much all the topics uh that we're going to cover today uh in this talk we'll have a bit of a recap of what cotle multiplatform is how it works then we'll take a look at the stable announcement that we had last year and as well as all of the developments that are going on since then and that are coming soon I do have a bunch of slides but I also have a bunch of live demos prepared here um to the side uh so we have that to look forward to uh as we go along and just like have you know fingers crossed for me uh during all that so cotl multiplatform is a technology that allows you to write cotlin code once and then compile it to multiple platforms you can run it on the server side you can run it on iOS Android desktop or web and if you're doing this on the client side you can also optionally do UI sharing across the various platforms for the sake of our examples here uh let's imagine that we want to create a client application which will run on desktop Android and iOS Platforms in this scenario we would have four different Source sets when we're working with a cly multiplatform module we would have our common sources which can be compiled to all of our uh projects platforms and then we can have optionally project spec uh sorry platform specific uh Source sets uh where we can call the various platform apis but generally of course our goal here would be to write as much code as we can in common code so that we don't have to write it two or three different times in common code you can do anything that doesn't depend on specific apis of a platform so you can use basic language features you can create classes functions and all that you can also use things like Collections and a bunch of things from the standard Library uh because these also generally do not depend on the specific platform that you're executing your code on but what happens when you do need some platform specific apis this is where the expect actual mechanism comes into play you can create a declaration in common code of what you expect to exist and then you can provide various actual implementations for each platform let's take a look at a quick example of this as well uh for example you can have in your common code a g platform function declared but not implemented uh because this is declared in common you can use it anywhere in that shared code and then you can provide platform specific implementations so for example on the desktop Target we could uh use the uh system properties to grab the jvm version on Android we could use the build class to extract things like the Android version that we're running on and we can actually do the same thing on iOS we can use um iOS apis uh to grab the iOS version there and this last one should be the surprising part uh this is all thanks to cotlin Native automatically mapping these apis into cotlin whereas originally uh these are meant to be accessed from Objective C or Swift of course you don't want to do this every time you need to access uh something that requires platform apis so uh luckily we have a great ecosystem of and a growing number of multiplatform libraries that you can use and um if you uh are ever looking for a specific uh multiplatform Library the KMP awesome repository maintained by one of our colleagues is a great way to start uh as you can see there are a lot of different categories of libraries you'll find here uh whether it's for logging for dependency injection for testing or just about anything else for just one example of using a multiplatform library I'll show you a quick snippet here from Kor which is um um multiplatform networking Library by jetbrains built for cotlin and uh here you can see that I've imported Kor as a dependency and because it's a multiplatform library I can use it in common code I can instantiate a client and I can make an HTTP call without having to worry about how that will actually uh be implemented on each of the platforms that we're using so once we've constructed this multiplatform module uh we would then build our various applications on top of it so uh as we uh previously planned we can have a desktop an Android and an iOS application built on top and each of these can contain their own logic as well as their own UI implementations written with the native language on each platform and with the native toolkits and libraries of each platform and one of the great things about cly multiplatform is that you get to choose what you want to share if you want you can get started very with a very small portion of shared code uh you can share a single function just one calculation one algorithm uh something like that to get started this is also great if you're integrating this into an existing application that you already have and of course you can go the other way as well you can try to uh move every uh that's um business logic into this uh shared costly multiplatform module so that you have just minimal applic s built on top of your shared code okay uh this talks title was about uh cly multiplatform becoming stable so uh let's take a look at uh the evolution of cotle multiplatform over time uh real quick the first step on the stabilization Journey uh was the alpha in 2020 uh at this point uh we were focused on C multiplatform mobile so the uh code sharing use case between Android and iOS applications and around the these times um we had technical advancements like being able to catch exceptions thrown from Objective C on the cotlin side or the uh binary format of cin native stabilizing so that you have backwards compatibility as you're upgrading your versions then uh beta was a big milestone in 2022 uh here the headlining feature was the new memory model Landing uh previously when you had concurrent access to objects you would have to use special apis to freeze those objects and things like that uh which made it um a bit difficult to write uh shared code that will be compiled to Native because native worked differently but with the new memory model uh we've done away with that and uh you can just write your code the same way as you would for uh any other compilation Target uh also around this time uh we had tooling uh advancements for example K doctor which lets you check your environment setup quickly and uh Google has also started introducing their first experimental uh multiplatform libraries Within jebac and that's how we got to the stable release around the end of last year uh which we'll take a look at in a bit of detail in the upcoming slides but this is the general production ready and um and um stable release of cly multiplatform we'll take a look at that in detail in a bit and of course you'll notice that some time has passed since last November uh so we'll also take a look at some advancements that have happened since then so uh what does the ility mean uh most of all and first of all it means compatibility guarantees cly multiplatform is a complex technology it consists of many parts across the language the compiler uh various pieces of the tooling and cly multiplatform being stable means that you don't have to worry about your projects breaking as your upgrading versions uh and you can uh safely use it in production you can learn a lot more about the details of stability of the various components uh by going to the link on the slide there something we've also improved significantly around the stable release in 1920 was the configuration of your multiplatform projects if you are targeting um uh platforms such as iOS where you have multiple different architectures that you're compiling to then you would usually want to have a shared Source Set uh just for uh iOS architectures uh so that you can write iOS specific code once and then it will compile to each of those uh specific targets for this you would have to manually create sour sets as you can see on the slide here you would have to set up dependencies between them and so on the good news is that by 1920 we have done away with this you no longer have to do that work manually you can simply list your Targets in the configuration of the cotlin plugin and we will create all those Source sets and dependencies for you the way that this works is by using uh something called the default hierarchy template uh this is just a portion of it but the full template lists all of the available targets of cly multiplatform and what the plugin does is as you add your uh platforms that you want to Target it will find them within this hierarchy and it will create all of the default intermediate Source sets as well as all of the dependencies between them so you don't need to uh do that configuration yourself once you do have Source sets uh you will still want to access them to add things like dependencies for example and we have also made that easier uh by adding typed completion as you're looking for a dependency for example if you're looking for common main you can start typing that in uh your configuration file and you'll get autoc completion and easily be able to select it and the same goes for all of the other um targets and sour sets of the hierarchy so Android main iOS Main and so on we've also made a lot of improvements around the stable release on the build and the runtime performance side uh both of which of course are uh important priorities especially with cin native we have added full support for configuration caching in gradal uh not just in the cotl multiplatform uh gradal plug-in but also in all of the xcode related build tasks which uh didn't have this previously as well as in the Coco pods Gradle plugin then uh we now have an experimental uh incremental compilation for calib artifacts which are native cotlin libraries previously there were build steps in the tool chain here where where we needed to fully recompile all of your sources and now we can do that more intelligently we've also moved the uh memory management of the cotlin Native compiler into the compiler instead of having it implemented as part of the gradal plugin uh which gives us uh great opportunities to optimize things right within the compiler and finally to talk about runtime performance as well we have a new custom memory allocator for cotlin Native which can more efficiently uh manage memory for native targets by having different pages for different sizes of allocations as well as different uh management um strategies for these different page sizes we also shipped new documentation um so that it's easy to get started uh with cly multiplatform uh the new development portal uh contains uh all of your entry points into learning about cly multiplatform including sharing UI with it and all of the tooling uh around it as well something quite important uh with the uh mobile sharing use case is being able to call cotl code from Swift as you're integrating shared cotlin code into an iOS application and uh this is something uh where you have to be aware of how your cotlin defined apis will look like from the Swift side and how the iOS application can consume them uh to make this easier uh we have uh created this uh cotland Swift infopedia which contains examples of many many many language features uh written in cotlin and how they map into Swift uh also this is based on a community project um so um shout out to the original project here as well now uh within this topic uh the reason why some of the interrup between Swift and cotlin is difficult is because cotlin for cotlin Native consumption is exported as Objective C headers and so whenever you're calling from Swift into cotland you are going through this objective SE Bridge that exists in between uh and there are some Advanced language features generics and uh things like that which are really difficult to um do through this Objective C bridge and we are working on eliminating that um so uh exporting cotlin directly to Swift but I don't have any announcements on that today uh but uh please stay tuned all right uh with that we're going to head to uh some of our demos here uh and the first thing I wanted to show you is km. Jet brains.com which is the new entry point to create new projects with cotlin multiplatform uh as you can see this wizard allows you to set up basic things like project name and ID and then you can select the platforms that you want to Target with your application so uh Android and iOS are selected by default and you can also add desktop web and server side and on the iOS part uh you can choose whether or not you want to share UI using cotlin as well and then you can just download the zip file from here and you have a project to work with uh not only do we have this project generator here though but we also have a template Gallery uh where you have uh somewhat more meaningful starter applications that you can take a look at and um build your own applications from there uh as you can see we have an app configured here with shared logic and shared UI we have an app that has native UI on each platform and we also have a library template if you're looking to get started with a multiplatform library next I have to talk a bit about tooling uh all of the demos I'm showing you today uh will be in jet brain Fleet which is one of our latest products uh this is an ID that's currently in public preview and it's uh where we are putting our efforts for Tooling in multiplatform uh let me tell you a few things about Fleet um so that uh you have some context for why we're doing that um so when you first open fleet it opens as a lightweight simple editor you can browse your files you can edit your source code but um it is just an editor at this point and uh you have to turn on something called smart mode to take full advantage of its capabilities when you do this Fleet will take a look at your project the languages you use and lo load the appropriate language servers and code engines as a backend of sorts uh to provide code analysis refactoring uh run configurations and more in the case of cotlin for example Fleet can load intelligent as a backend and provide all of the assistant and smarts uh from there uh then um because of this in part uh because of this uh capability of loading language support dynamically uh Fleet also supports a lot of different languages this is a sample of the languages it supports and of course the most interesting ones for us with cly multiplatform are going to be cotlin and Swift uh and uh not only uh does please support these languages but it can also understand the connections between code in cotland and Swift so let's take a look at that uh and from here uh we're going to start hopping through demos and this is our first one so here's a project opening Fleet uh we have a shared module uh which is written uh with cotl multiplatform and then we have an iOS and an Android application uh built on top of it with Native UI for each platform uh here's here I left this panel open which which shows up when you open a multiplatform project in Fleet uh as you can see uh this is essentially K doctor integrated uh into Fleet to make sure that uh your environment is set up correctly you have things like uh the Android s dkx code and so on uh correctly configured uh let's quickly run this app and see it on both uh Android and iOS here we have Android and we should have IOS in a moment uh this is a very uh simple sample app uh we can essentially enter a circle's radius and it will calculate the area for us um we should have IOS launching here let's try this again there we go um so obviously the same thing on iOS we can type in the radius it gives us the area uh but of course the interesting part here is the multiplatform part uh if we take a look at the um iOS code here which is implemented in swiftui we can see that whenever button is clicked uh it instantiates a calculator object it calls a function on there and passes in uh the radius and gets back the area from there and uh if I uh navigate into any of these declarations we'll end up in the shared cotl code that it's using under the hood so uh we can of course navigate from Swift to cotlin we can also do things like rename a declaration let's call this um I don't know just circle area for example and uh if we now take a look at the usages we can see that the naming happened across both languages both in cotlin and uh Swift references and uh we can also do debugging uh across languages if I just rerun this on iOS uh with a debugger which will take just a moment to instantiate and of course I've also uh changed the name of a method here just going to wait a moment here for the debugger to attach there we go uh we have the the debugger so now if I click in here enter a number and hit calculate you'll see that we stop on a breakpoint uh we are here in our iOS code uh we can of course inspect variables on the Swift side we have the calculator instance which is uh shared code from cotland uh we can uh step through the code we can see the radius being parsed and we can step into the circle area function which means that we'll end up in cotlin code and here again we can step through each of these lines uh and uh run this line by line um I'm going to skip this Su off and we're just going to skip down to the bottom of the function here uh we see that uh we can see all of the cotlin variables in the debugger uh we can see uh you know properties of the objects that we created for example this intr range uh that's up here and if we scroll down if we scroll down to the bottom of the locks here we can of course also see the standard output um from cotlin and the iOS um logs there so we also have debugging like this and if I keep stepping we'll return from the function end up back in Swift code again and if I let go of the breakpoint here um then we get back to our application which has displayed the value that we calculated from cotlin which I think is pretty cool okay let's keep going so so far this is the client application uh that we were looking at we had three different applications implemented on top of our shared code with their own UI implementations but of course we can also to do something about that with cly multiplatform and uh here is where compos multiplatform comes into play which is a UI framework built by jetbrains for multiple platforms built on top of Google's jetpack compos framework for Android uh currently uh we support uh the following uh targets we have iOS Android desktop and web uh on iOS uh compos multiplatform is currently in Alpha uh it has been announced uh at last year's uh com on Android running compos multiplatform is really just running jetpack compos so that's of course stable compos multiplatform is also stable on desktop and it's currently experimental on web and naturally we are moving towards stabilizing these um two platforms when you use compose multiplatform the experience is very very very similar to using jetpack compose you are using the same apis the same foundational Concepts the only real difference is that that code now can live in your common main folder and you can compile it and run it on multiple platforms and not just on Android so that means that uh you can that we can update our uh chart here and instead of having platform specific UI implementations we can have shared UI written just once using compos multiplatform but just like with costly multiplatform this isn't an All or Nothing decision of whether you want to share UI or not you get to choose which parts of your UI you want to share and which parts you do not um so uh you can still interoperate with the native UI toolkits of each platforms and if you want you can have a single screen of your application that's written in compos multiplatform and if you want you can have it uh full UI shared uh using compose and anything in between uh at this point I want to show you some of the latest developments we've had in uh jetpack compose including releases from last week and yesterday um so uh these should make for uh some nice demos uh quick up here uh these are generally still experimental um but we really do encourage you to try them out and give us your feedback so that we can stabilize them so uh in compos 1.6 switch shipped uh a bit earlier this year we have added support for using compos multiplatform resources and we are continuing to make updates to that uh then I will want I will talk about some Android X jetpack libraries that have been ported to uh multiplatform which is joint collaboration between uh Google and Jet brains to make this possible uh so we're going to take a look at the life cycle The View model and the navigation libraries let's start with resources so uh compose resource handling for multiplatform looks very similar to Android resources uh this time you'll place your resources mostly in the common main source set under the composed resources folder uh then you can uh show share things like drawables files fonts and values using this resource system at the moment and uh you can also use uh set of qualifiers so that you can have different resources per uh language region screen density and light and dark mode and of course the best way to look at this is also a demo so we'll hop over to this resources demo and I'll launch it on iOS and on Android uh and in the meantime we can take a look at the code here so uh of course okay uh so uh in this sample project uh we'll do a bit of font loading uh we'll load the J brains mono font as an example uh that's what we're going to use for the title of our application which uh will also come from uh string resource uh we'll have a greeting on the screen and then finally a logo displayed which is a drawable Resource as you can see uh the accessors for these resources is again very similar than on uh as it is on Android so we have this res class uh that we generate uh based on the contents of the composed Resources directory and uh in there you can uh have typed access to things like uh strings fonts and so on um and we can also see the structure here um in the project view on the left hand side um so we have some drawables here as well as a bunch of different string xmls let's take a look at the application done um so as you can see uh we have the greeting we have the font loaded and we have this destroyable that's uh coming from um resources as well and if we start changing settings here uh we'll see that the resources update dynamically for example if I go to dark mode uh with the Android application we now have good evening uh instead of the previous string resource and if we switch languages which is so easy to do on each of these emulators so let's do that on the iPhone side and let's see if it's easier on Android yes Android has maintained my setting stack very good um so we can switch both of these to French and in this case uh we have alternative resources and alternative drawables uh that we can load um so very similar Behavior as on Android and um you can use all of these kinds of resources all right uh I want to highlight some uh things that are coming in newer versions of resources as I mentioned we already shipped this in 1.6 but we are adding improvements uh constantly and in 1.6.1 uh we will have support for using these in multimodule projects as well as shipping libraries that use resources which was uh one of the important missing parts uh before then we have added some configuration options for the generated accessors so you can control the package visibility and other options around it we got a Community contribution uh to compos resources which added support for plural strings again very similarly to uh Android and uh we can also now have resource directories in multiple sour sets so not just under common main but under a more specific Source sets of your project as well all right uh let's keep moving and look at life cycle next so the life cycle library is again a port of the Android life cycle library but to multiplatform so it will include life cycle States like created started and resumed transitions like on start on resume on pause that you already know except we will now have mappings of these life cycles for uh the um multiple different platforms that compose has uh for example on desktop uh whenever your window loses and gains Focus those would trigger on pause and on resume events or when it gets minimized or opened back up that would trigger on stop and onart events and of course we have a demo to look at here as well uh as soon as we can find it uh we're looking for a life cycle demo okay uh I'm going to run this on desktop uh we're going to run it in browser using wesm uh so on web assembly and we'll run it on iOS of course we also have it for Android but it would be really really boring to look at the Android life cycle as a demo at this point um so let's just check out all the others so uh here we have the desktop app and the uh web app side by side um I can hop between these of course whichever one I have focused uh will have a resume State and um if we take a look at uh the locks here uh for example side by side with the desktop app uh we can also see the state changes that it's going through and you know I can also minimize this it will go to created State I can open it back up it comes back to resumed and so on and if we take a look at the code that's powering it uh we'll see that uh it's again the same uh life cycle apis as on Android uh so we can grab a life cycle from our local life cycle owner uh with a composition local uh in compose we are collecting the life cycle state of that and that's what we're putting up on the screen and I also have just a default life cycle Observer implemented here which was printing all of the uh transitions into the logs for us uh we haven't looked at iOS yet uh but we'll see very similar things uh of course I've increased the font size here five minutes before the talk uh so now that's a bit too large for iOS but we'll uh go with it So currently it's resumed and then I have a button here which navigates away from our compos content on the Swift UI level uh and as that happens we can see that we have gone into a created State and if I go back of course um that previous screen gets resumed again and I think we can shut down all of those at this point all right so that's life cycles next up it's view model this is not going to be surprising it's the same view model you already know it's in the end Android X package it's an abstract class it has a method uh uncleared which will get called whenever the view model is being disposed so you can uh shut down your uh various operations and it has a view model scope extension so you can easily create new Co routines uh from your view model the interesting question with view models when it comes to multiplatform is who will own these view models uh what's going to be the scope in which they exist and when are they going to get cleared um so essentially uh what will implement the view model store owner interface which provides the scope for all of our view models well uh on Android if you're writing a single activity application all in compose uh this would generally be the component activity which is essentially a global owner for all view models uh within the application and whenever your compost code requests a view model that would be stored uh in the view model store that's inside your component activity now on other platforms we can't quite do the same thing because the external components that host our compos content uh do not have um view model store uh implementation uh they don't have a notion of managing view models um so in Swift UI for example uh we don't have a global store like this um but for uh whatever hosts the composed content within each application so on the iOS site that would be the compos UI view controller on the um desktop side that would be a compost window and so on so those components that host your uh compost content within the application those do have an implementation of view model store owner so whenever your compos code requests a view model that would be stored globally within that compos frame of your application and of course you can also have more granular storage we'll look at the navigation library in just a moment uh but the navigation Library just like an Android each of the navigation backstack entries it has can also um store view models themselves so if you're within a destination in a navigation graph you can request a view model and that will be scoped to the um navigation backstack entry and whenever you navigate away and it gets cleared from the stack that's when it would dispose of all of its view models as well and of course uh as we've seen um we haven't quite seen this part but we've seen that the life cycles are accessible through composition locals in compos the same thing happens to look up uh the V model stores so you can just provide your own view model store implementation uh create a composition local uh provider for that and uh control the life cycle of your view models completely manually if you wish and very similarly authors of navigation libraries may choose to use these same types the Android X model type and so on and provide their own scoping here so uh navigation I feel like a broken record here uh but it's the same thing as uh with Android and Jetpack compose but you can now compile it for multiple platforms uh again you have a NE host you have various composable destinations and you can navigate between them uh let's take a look at this code uh in the ID and um actually see it in action so we're going to go to um this project here uh which is actually one of our template projects from The Wizard that I've shown you earlier and if we run this again we can do Android and we can do iOS here um if we run this um we'll see uh that we have we do have a Wi-Fi connection that's very good um so as you can see this is a browser uh for various images in a gallery and I was a bit too I was a bit too happy about the Wi-Fi there um so uh if we navigate to uh any of these uh specific um pieces of art we'll get to a Details page and we can navigate back it's it's a basic sample for navigation um and here's the code again we've seen this on the slide but we can uh actually hop into these uh various destinations here so for example our list screen is a composable uh it's fetching The View model again using the same apis if we scroll up here uh we can check the Imports it's again just the same view model function um we're providing a factory for how to instantiate our view model uh and then we're uh collecting some state from it and whenever uh clicks happen on the grid of images we're using the nav controller that we passed in and navigating to the uh detail page uh just like that uh so that's uh navigation and view model okay uh then brings me to the last topic I want to talk about today uh which is going to be emper emper is a new experimental uh build system uh that we're working on at uh J brains uh with the aim of simplifying build configuration and making it accessible to developers of all backgrounds uh we are of course building emper with cly multiplatform in mind uh from the beginning and uh we really want to create build system here which is toolable uh which will be largely thanks to its declarative nature and again there's no better way of talking about this than just showing you some examples of how it works so uh let's do that uh we'll start here with a Hello World project for the jvm uh written in Emperor so uh we have a source folder here which contains uh main. KT I already have that open up here um so um you know that's just a hello world function and our configuration uh lives in this module manifest file with emper where we are declaring this this is a jvm application so essentially a command line jvm app and if we quickly uh compile and run that uh that of course uh prints hello emper in this case now you may also see here that we have a bunch of Gradle related files and the reason for that is that we have initially implemented emper as a Gradle plug-in uh which allowed us to really uh quickly uh start iterating and verifying the ideas uh with this product um so uh we are running on top of Gradle here um as a Gradle plugin which means we have the Gradle repper and all of those things uh included in our project and that also comes with a couple benefits because that means that you can introduce emper into an existing gradal based project easily and if there's anything that you cannot configure with emper at the moment you can always just create a build gradal kts file next to the emper module manifest and uh use Gradle interop uh to configure uh more advanced things so uh this project is uh really just a single module jvm application I said so we just have uh one module file here and uh because we are using a declarative format here uh we can actually see that if I just trigger completion uh we get suggestions of all the different things that we could configure uh using emper uh for example uh we can go ahead and uh start adding some dependencies uh let's say that I'm looking for coroutine score if the Wi-Fi is with me we'll get a complete comption for that maybe we're not going to get a completion for that do I have history for it yes I do there we go uh so what we would have seen here uh if WiFi didn't give up on me uh would have been that we get completion for uh artifacts from Maven as well as their different versions ah there it is okay um so uh you can easily just start typing the name name of a dependency in a configuration file and then um add it without having to go to readms and uh so on and then once we import that uh we can of course uh use that as well so I'll just um modify my main file here a bit uh to use some code that actually has cortines in it um it's the classic coroutine demo of launching 100,000 of them and eventually printing a bunch of dots with it um and of course uh because we have imported cortines then uh that works now as well but let's take a look at a more advanced project um which is configured with emper and this again is going to be the same uh template project from The Wizard that we've seen earlier uh where we have a shared module that contains um basically all of the shared UI with compos and so on and then we have uh multiple applications the Android and iOS app built on top of it uh as you can see here uh now our product type is uh going to be a library and we can list the various platforms that we want to support with this Library uh again we have a schema here so if I wanted to add a new platform um I have a built-in completion for that uh then we have this settings block which is generally where tool chain configuration goes with emper um here you can um play with things uh like compose and cotlin settings uh if you wanted to uh set up something like an SDK version um for Android you can also do that and something really nice we have here for in tooling is that you don't have to go block by block uh within this nested configuration ation but we also have nested completion so if you just start typing something like SDK you'll immediately get results like Android Min SDK and you can uh easily uh start completing for that uh then we have uh couple examples of pulling in dependencies from various sources here uh as you can see we can use the uh compose uh version catalog uh to easily pull in multiplatform dependencies uh for compose we also have the Project's own version catalog uh which is again a Gradle version catalog um that we can access uh so we have this Libs accessor uh to pull dependencies from there and we also have a bunch of different uh inspections and uh intention actions which can detect if you are using hardcoded dependencies offer to replace them with catalog versions and we even catch things like using a dependency with a different version uh than uh what's in the catalog and in that case you get multiple different um intentions that you can use and as you can see a fleet gives you a really nice preview of how exactly uh triggering that in intention action would modify your various files in your project and uh here um we we'll just look at uh one more thing uh which is that uh we have these qualifiers uh for dependencies so uh this dependencies block is for common dependencies between all of your platforms whereas these ones are where the uh platform specific dependencies like uh multiple Kor engines would go and the same thing is true uh for the source layout here um so as you can see we have the U regular SRC folder where most of our source files are and then we can have um platform specific Source sets for things like actual implementations um and all of this is a very flat module structure in general uh let's look at just one more thing here uh let's take a look at what the iOS application uh looks like uh in this case so uh again it's an application product so it's an IOS app it depends on the shared module to grab all of that code and it has compost support enabled so that's a feline build file for the iOS application and uh we actually have just four source files here uh which essentially set up our iOS application um set up our Di and then uh the frame that the compos view is hosted in and as you can see we have um you know essentially five files for the entire iOS project here and we can also have Swift and cotlin files um side by side uh in the sources and of course uh we could compile this as well but we would see the exact same thing as before uh let's do that quickly uh for Android but it's just going to be the same Museum app and I think I haven't thrown that in a while if the emulator is with us okay my emulator is not not happy I I cannot deploy to it all right well it would have been the same Museum app okay that's the Wonder of demos all right uh so if you want to learn more about emper uh the best place to go is its GitHub page where you can find uh detail documentation sample projects and uh all kinds of resources to get started uh we have an emper channel on the cotlin L slack uh where we very much welcome your feedback and thoughts about it whether you like it whether you don't like it uh the reason why we made EMP Republic at this point is so that uh we can get your feedback and your use cases that you want to see supported uh and if you have specific issues to report you can also uh always do that on utra okay uh if you have any questions about cotl multiplatform um about any jet brains products in general really uh you can of course find me around the conference we'll also have the KMP office hours tomorrow with not just me but a bunch of really knowledgeable people around uh cly multiplatform and if you want to stay tuned uh to cotlin news a great way uh to do that is by attending cotlin comp uh which I won't try to sell you on at this point uh because we have uh luckily sold out a while ago but what I want to highlight is that you can follow uh the entire conference all of its tracks on the cotlin YouTube channel and there are also cotlin com Global events uh which you can go to and I think there should be one uh even here locally with that uh here are some resources uh that you you can find you can follow me and find me uh on social media you can find the slides and all of the links related to them on my website and again uh thank you very much for uh coming to this talk and yeah see you around the conference thank you I think we have a few minutes for questions [Music] I [Music] [Applause]

Channel: Android Makers

Views: 1,773

Keywords: English, Intermediate, Kotlin, Kotlin Multiplatform, Session

Id: il32V2MNdPc

Length: 42min 37sec (2557 seconds)

Published: Fri May 03 2024