 yep everyone again thank you for coming don't forget to yeah help your chair when you leave the room it's really noisy don't pass in front of the camera over there and we still have Japanese licenses so open for requests then I'm happy to introduce Nishon he's going to talk about Kotlin MPE into the multiverse so okay hello everyone you can all hear me right at the back also I hope okay great thank you all for coming to this talk so the idea about this talk basically came through because I was trying to like find out ways of working with Kotlin multi-platform it's like people have been talking about it and a lot of things are going around this so I eventually started like trying out how I can get this to work turns out it's not as easy as we think it is so that's how this talk came to be so what I'm going to be doing here is I'm going to try to at least convince you all to understand how Kotlin multi-platform in general is working and what's doing and then I'm also going to show you how you can actually get a working application for Android and iOS because it's not as simple as you think like you just fire up an ID and it works no it's not that that's what I will show you so let's start with that so I said Kotlin MPE what does that actually mean as you would have guessed it's basically Kotlin multi-platform there's no formal definition for this like what exactly it is so I came up with my own from what I understood basically we are utilizing Kotlin language to build for these multiple target platforms I'll get to what target platforms are in a few minutes which enables code sharing while being as flexible as you can be right so I'm going to break this down because like a full statement okay there's a lot of things being said here in general Kotlin multi-platform is like an open source tool or I should say plug-in that's available it uses Kotlin as your common code here also is targeting multiple platforms the code sharing is specifically happening for data domain and presentation layer the the the different thing about it is that it integrates with the existing native platforms so it leverages the native capabilities of the platform when it is required it's not that you are you are specifically forced to use them it's more a choice on you when you need to use them you will go ahead and use them it's optional as it's not opinionated ties into the same point as as above it will not ask you to specifically use a certain pattern it will not ask you to do some sort of like trickery or like use a different language to work with so it's basically trying to help you as much as it can while giving you all the choices but the question here is why why are we even trying to do this so from what I understand is that up till now they are being like all these different possibilities that we could use Kotlin for you could use Kotlin for generating JavaScript code and then you could use Kotlin for generating the JVM base code the byte code right and then Kotlin native came into place and that allowed people or at least the Kotlin toolchain to generate more target platform specific code so you can think of something that's more near to the machine level code here and the second point that's very important that existing solutions are very opinionated I'm looking at a flutter react native and then you also have Xamarin obviously people have tried CC plus plus in the past two all of these are very opinionated in the sense that they force you to use a certain pattern flutter would basically ask you to use first of all a different language so you start from a different stack and a different language at the same time it tells you that you cannot use the platform widgets because it is going to be drawing all the widgets for you on the screen right so those kind of like opinionated versions exist and that's why Kotlin native is or Kotlin multi-platform now is something that's more considered it's something like this like we have a situation where it's a dilemma of the mobile app development right now where if you want to develop a native app for each device and maintain several projects this is what it looks like on the on the right and then you use a unique framework like say phone gap and then app accelerator like in the past or you could use flutter or even react native you end up building something that is limited in functionality why am I saying that because there have been companies who have tried this in the production like for example you know Airbnb tried react native and then they pushed back to going to native again Dropbox tried CC plus us for their cross-platform capabilities in the application but they also went back to native because there's certain things that you cannot do when you're trying to share most of the code across platforms so let's dive into the multi-verse of platforms here or target platforms that's the technical word for it the way I understand target platform I think this was explained in the last talk a little bit but the point here is that I understand it as compiled artifacts to be consumed by specific platform so say for example when we are considering Kotlin JVM the artifact that will be consumed by the platform would be jar and AR files right this can be consumed by Java by Android by Spring Boot if you have Kotlin JS is going to be generating JavaScript code which you can bundle it up and push it with say JavaScript react a node and then they come to Kotlin native part which enable more possibilities where you have ability to generate code that is native to the ARM platform or CPU in general that you can push it with the Android and DK you have iOS version the iOS X 64 by the way is the emulator similar you have for TV OS X 64 is again emulator version watch OS X 86 is again for emulator and the other versions are when you want to run them on the device and then you have more where you have the Linux ARM version the MIPS version for the same Mac OS X 64 main W which is basically for Windows and then the WSM 32 which is for WebAssembly that's what Kotlin native is allowing you to target now because it's generating artifacts that can be consumed by code that's running on this platform so this brings me to the next part here because it's not just the target platform it's also about code sharing so when we say code sharing we are actually talking about more related to the data layer in general right where you can put your networking code that can be shared across multiple platforms you can put caching you can put repositories you can even put like something like a presentation layer which is common on Android side you have view models and presenters controllers and then there's the domain layer where you can put use cases entities and the interactors what is also important here is that we are not talking about the UI at all now why we are not talking about the UI because Kotlin native in general doesn't even care about UI each of these platforms that exist have their own way of representing UI IOS has its own version Android has its own version say example Linux has its own version and they all do their job pretty well so what called the native is basically saying is that we're going to build an artifact for you you plug that into your application build the UI on your own and then use this whole code right so this is the artifact that is being generated on all of these different platforms is what is shared but the UI is still native this is more or less on the side of just making sure that the UI gets updated pretty frequently right but your business logic anyway stays the same so you want to share your business logic mostly and not the UI UI can change whenever you want based on whatever technology you use even say for example on IOS we were developing a lot of like UI with save you controllers and other stuff now you're using the sift UI same on Android you could basically be using XML layouts now but now you have compost that's coming in now these technologies would change all the time but the score idea of multi-platform here is that the business logic is getting shared across mind that I'm not saying this is cross-platform comes back to the same thing when we say cross-platform solutions we have basically solutions that are we they're asking you to write code in an opinionated manner right also they are doing some sort of like bridging to make things work for you magically right when you say it's a Xamarin app I write code in C sharp and I write something up and say for example like an application in that and then I deploy it to say Android IOS and save some other platform maybe desktop in this case what they are doing is they are going to compile your code put it behind a bridging layer and then talk to the native site so there's still some sort of a dependency in between if this dependency is not updated you're already behind so what's the secret source here so from my understanding and this is what I am gonna maybe represent it and maybe you can think through with me as I explain this is that there's a concept called expect an actual concept what I like to call as interfaces with superpowers and more and I'm gonna explain what that that turns out to be so this is a standard interface in Kotlin right you have an interface that a function called platform name then I'm using Android code right now you have a main activity where I'm kind of I'm not extending the activity here for some reason but I should have anyways consider it's a standard class that is implementing the interface and it overwrites the the function here platform name because I'm using the interface and then later on I use it inside the function called create application screen message I'm calling it hello from dollar and then the passing the function in there now notice here's something the first section where the interface is declared or I should say define actually or declared yeah that is the point where we are expecting this to be implemented this is how we read it right and then eventually when we override it is the actual implementation that's how interfaces work now I'm gonna map this back to how Kotlin multi-platform is going to be using this kind of a functionality so what you have is that on your say you have multiple modules right now in a Kotlin platform project the common module here would basically say expect that's the keyword to use and then it will put it something similar to like how you use code routines you put suspend and then the function name right you're gonna say expect the function name and then that's it then maybe you can use the same function call in the common code for create application screen message and then eventually in the platform specific code version you will go and say the actual implementation for this by using the keyword actual is this function and what what is the implementation you want to find so in this case we are defining the string as android for android platform module and is for is module but this not it and I said and more with the superpower version is because it's not just limited to how it will work with functions you can use the same kind of a process when you're doing it with the class right so for example you have a class here greeting where you say I'm gonna expect this class to have a function called greet in it now the platform implementation for this will map into saying actual the class greeting and then notice I say actual constructor val name string why am I saying actual again because on the platform side this could have been say swift and it would have said let name string so this is also changing for me so that's why I have to say the actual implementation for the constructor is gonna be something that's very specific to android in in this case using cotton so val name string and then eventually I provide the actual implementation of the function here called greet where I say print and hello name and then you can obviously use it based on which platform you're using in this case we are considering and right so we'll create the class we'll call the function on it which will print hello foster so that said let's jump into trying to or or I'm gonna I'm gonna go through the steps that you require to start building Kotlin multi-platform code now that we know the idea of expect an actual but before we do that I want to mention something about sharing is caring so if you go on the internet right now and you try out like Google searching this how do you get Kotlin multi-platform project to work you'll find many ways one of the ways of doing this this code sharing is that you put all your code in just one repository right and then everyone just tries to work with that in that same repository that's okay to work with but if you have many teams working across different time zones people are going to be committing code it's gonna conflict and cause a lot of problems so that's not a good one the second one is that you put everything in its own repository in its own project while the shared code that is gonna be shared across multiple projects is gonna live its own project it's a bit hard to maintain because you have to keep in sync with the shared code and the other platforms that you are sharing this against so you have to keep them in sync this is what it kind of looks like so imagine this being a project in Intel J where I am basically creating a sample app called KMP here it has app as the module that is the Android app it has native slash Kotlin iOS slash Kotlin iOS as the iOS app module here and then you have a shared code as a full folder here inside which lives something called Android main which is your Kotlin JVM code something that lives as common which is your shared code and then you have your iOS main which is your Kotlin native iOS shared code here this is basically living outside in a shared code folder so this is something that you would do but it's really hard to maintain it at the same time because yes people would be doing a lot of things at the same time the third version of doing this is that you have one platform in sync with the common code while the other one lives on the other side right so it's better it's easier to test with it is better to change things and this is what it looks like you have something like this you have Android app and the Kotlin JVM version living side by side and then you have your shared code the Kotlin native iOS code and the iOS app as a different module right the shared code and Kotlin native iOS code actually lives inside the app module as you can see it's called common main and iOS main this is just living inside the app module itself so we're going to actually start doing this like from scratch like how you would do this you would think that it's very easy to work with but sadly there's no specific ID like Android Studio but you we use kind of like all three IDs here we'll use Intel J idea we'll use Android Studio and we'll use Xcode all three of them together to get to get this project working and functional so you start with Intel J idea this is the latest one I took the screenshot last night you create a new project you say I'm gonna put a mobile multi-platform project with Android and iOS code in it using Gradle build tool define it a name give it something and then say finish at this point when you've hit finish your project would sing and you would ideally assume that it is functional turns out it's not because by default Intel J idea does not put the SDK path for your Android in the local dot properties file so that is a bit weird because they do that for Android Studio or maybe Android Studio team does that specifically I'm not quite sure but in that sense you will have to actually provide the path here so I changed this path to something called users slash username and then I provide the Android SDK path here when you do this your project is fully functional at this point what you do is that you need to also go into your project structure and set the default like the SDK for all the modules this is also something that I don't know why it doesn't work but ideally this should be supported from the idea itself they know there's other SDK but they don't choose the default one is 1.8 Java version so I want to also highlight here when you do this the bizarre version you actually see something like a common code the Kotlin native is code the Android and the Kotlin JVM code and then there's a is specific code which is all split into different modules right now the function calls as you will define you will mention them as expect in the common code only in the Kotlin native is code you will provide the actual implementation in the Android and Kotlin JVM code you'll provide the actual implementation the magic behind how all of this is tying together is is actually using this this plug-in that you have you just need to it is defining your apps build or gradify once you define it you all have functionalities open like these you can define the platforms you can target to under the section Kotlin you can say is x64 which right now is targeting the is emulator I could just go ahead and do TV OS x64 and that would do the same thing but for the TV OS operating system for the emulator version and then you define the source that basically defining your dependencies which you can totally do as you would do in a standard got graded project then because you now want to run your application you set up the project now you need to open up Android Studio and select the app module the one that has your common code to you will select that run this through your as you can see there are different modules it's recognizing and then it will be able to execute the application surprisingly that's nice because now we are going to try doing the same with iOS so if I was again you go and then you select the folder that is called iOS app this is outside your app module in your route project and this is the one you need to select when you do that you would assume everything would work but it does not again turns out that's because they they use a relative path to reference something that doesn't exist which is also weird they should not do this it should come part of the wizard but it's not so you have this error this error literally says that you have something that's missing and that's a graded new file right that's not there so I need to put a graded wrapper in the route project and I'm going to do that by calling graded wrapper and it will create that for me that basically allows me to go back into Xcode hit run and be able to run the app at the same time so now you have an app running on Android and iOS both basically the whole project is functional you can go ahead and write code using Android Studio if you want or Intel J idea you can just open up the Kotlin file provide the actual implementation or the more expected functions you would want so examples in the wild I want to show this because there's a lot of questions going on do people use a production or not like is this something that that we should not be tinkering with turns out a lot of companies are doing that you can see a list of them all working with the links these all links to their blog post actually when you download these slides you can use them and read what they have been working on JetBrainz has recently released spaces their whole the system here which allows to communicate with multiple teams so that is also working Kotlin native Kotlin multi-platform and obviously touchlab is doing a lot of things in this area so you should totally follow them they are Kotlin multi-platform libraries by the way you can get a list of these but here's the caveat here is that the ecosystem is still evolving the bigger problem is that not many libraries are available at your disposal and a lot of people those who are jumping into building these libraries are actually not targeting all the platforms for example you wanted to use a multi-platform library right now that targets say are kind of like does database saving and retrieval of data right but it does not target TV OS but you wanted that functionality and be targeted to TV OS well if the library doesn't support it is useless for you right you can target for platforms but not TV OS in general so that's why not all libraries are actually targeting all the platform so that's a bit of a problem that's most of the stuff there is a resource here this is like a like a I would say a tutorial the first thing is more of tutorial on the official Kotlin line site the second one is the example that I showed you what I do want to also show you is the thing that I was talking about this is how all the files look like and the implementation this is the same project as I was talking about there is a section where I actually call this function create application screen message which was running there and I provide the actual functionality here but some people might even say like what if I wanted to use Swift UI that is also possible provided use it in a different way in this case you will see I'm including the shared code functionality the one that I was explaining way earlier than this and then I go ahead and I actually call the function here with the common KT file so you can also use with Swift UI if you want if you have compose you can also use this word it should function without any problems I will put more examples in this repository so you can also obviously follow this along and that's it I guess thank you