10 Questions You Always Wanted to Ask Us About Kotlin Multiplatform Mobile

hey everyone welcome to our kotlin multi-platform mobile webinar it's the first km webinar on our youtube channel so i'm totally excited uh my name is kate and i'm a developer advocate for kotlin multi-platform mobile you can find a couple of my kmm tutorial videos subscribe to our channel so you don't forget to check all the useful kmm and not only content later after our session but today we'll go we'll not go through the steps of creating the next kmm application no today we have another exciting format this webinar is dedicated to the most frequently asked questions about the technology about its usage and of course the i think the best source of knowledge for such questions is someone with lots of hands-on production experience so today i'm going to interview kevin gardigan from touchlab kevin is a partner at touchlab and he has 20 years of professional software development experience and has been working on android since the first public platform release amazing kevin is currently focused on developing and evangelizing cotton multiplatform native tools for the next generation of mobile development well i'm sure you are already know kevin for his great contribution to the community and let's say hi to kevin hi kevin hi how are you doing thanks and you pretty good pretty good okay so today together with kevin we will walk through everything you want to know about kmm um here we have seven questions which are often asked and uh could be considered you know quite complex uh so you won't find like one sentence answer for them in the kmm documentation these questions they imply you know good discussion and that's exactly what we are going to do today and i think the most attentive of you may notice that the three questions are missing we promised you 10 questions in the title of our webinar yeah but but please uh don't worry this is the place for your questions so please don't hesitate and write your questions in the chat in the youtube chat we will choose the best ones and we'll answer them in the end of our session and well i think let's go let's dab diff and let's start from something from some general ones and then go deeper to some specific ones today mostly about ios but well it's quite expectable so ah let's start with quite common so kevin which parts of your project do you prefer to share and why um so i think the important thing to start here is defining you know you right so um me personally you know and when we build small sample apps or if we're doing something brand new um we tend to try to share everything from the ui down so the ui um once your data and your other things get to the ui layer we try to keep the ui layer kind of i won't say as dumb as possible but as uninvolved into logic as we can and you can get a lot of shared code that way uh in larger teams it's kind of a different thing and we spend a fair bit of time working with larger teams so they tend to focus um this is generalizing what they tend to focus more on specific modules that are um perhaps complex perhaps things that people don't necessarily want to do um you know like again we're talking about databases physically stronger analytics things like that um it tends to be more module focused and larger apps with larger teams i don't know if we've ever seen any of these production environments but they might have tens or more of separate modules that are all kind of wired together at the end of the day but they tend not to get as involved in sharing threading and architecture that the more complex they are they tend not to do that as much but some do so it kind of depends um but yeah if i we have a few projects that have been kmm greenfield starting with like a small ish team and we'll work from essentially we have a co-routines enabled layer that exposes flows and suspend functions to android let android manage lifecycle directly because it's um they've obviously been putting a ton of work into that and then we sort of have an ios lifecycle simulation layer and then that exposes methods and callbacks of the ios layer and and essentially the ui is it's just doing the ui logic so that's what we attempt to do but you know there's practical realities that sneak in there too and when you speak larger teams the main the main reason is large code base or a big or a big team or or it's both why it's important for them maybe to not go directly to the whole layers in the kmm um so i would say that um i have a condensed like slide which we probably should have shared with you then you could have shown it's the reasons why kotlin is a great option um versus the other options that are out there and one of them is a low risk incremental introduction possibility so you don't have to do everything at once and you can introduce critical difficult things into a team um you're going to have team members that are skeptical you're also going to have team members that don't want to disrupt their current bills there are nightmares out there when teams started trying to introduce swift into an objective c ecosystem with swift is new and everyone remembers that so uh you kind of have to prove it'll work you have to do it a lower way so it's more of a practical they'll start that way and then um if you have dedicated ios developers and dedicated ios architecture i do think there comes a point with diminishing returns of trying to also do all the multi-threading and the logic and everything all the way up to the top if you have an existing project so that that becomes the debate and that will i think um it'll change over time especially if if you get a team bought into it and as you know we'll probably get into later in this discussion when multi-threading changes libraries mature uh compiler plugins mature ide um integrations are always improving so um it's a process of time of selling a team on it and then um i think the ecosystem matures and you'll see different teams do different things some will never get beyond certain modules some will probably start adding slices of functionality that are like more complete shared kotlin and then um do things differently even in some apps if you have a large enough team like you'll have one app with two teams that that really don't even work together i'm not talking android ios i'm talking like one app where like different ios features are implemented by entirely separate feature teams yes yes exactly right thank you for the proper industry term um yes but exactly that and and you'll have some teams that are uh i can't say which client now but we have one client with um we're starting with multiple teams coming up this coming monday and like they they do things entirely different but it's the same client so uh you'll see and it's it's once the team suits the value and feels comfortable with the build process and the libraries and the ecosystem it becomes more of a thing that you can push for but it has to be a value proposition and it has to not risk the existing situation right right i agree with flexibility like is the main beauty of km and cotton multiplatform stuff for me and uh based on that if let's imagine the case with a large team and the new project maybe let's imagine this uh amazing world where they have yeah then we have time for maybe experiments and they even can risk and uh for for that situation what uh would you recommend what approach maybe maybe or what process um for a brand new app and they're already sold um well you know i i would say one of the things that's difficult um is politically difficult with the team is that you know um as much as we try to dance around the obvious issue the obvious issue is that it's a very android centric approach and only because um kotlin is like the default language in android i would imagine often you know the team that's pushing this is probably more of the jvm side of the world slash android side of the world so there's getting past um i would say occasionally political issues but um this one if you're gonna start a new app from scratch i mean we tend to uh do it this way too you're kind of leading with your android development um you're going to delineate where what's going to be shared and let's you know take a concrete case of what we're working on now you know like we have um essentially view oriented logic transform is the last stage and then uh database access and another thing you know like stuff like layers that are going on there we planned that ahead um let me code with that but essentially you kind of um you have to have people that understand kmm like it's not it's it's it's not realistic to think that even an android developer is just going to say okay i'm going to do shared code now because there's an understanding of just mechanically how ios works and compiles and understanding the memory model so you do have to have a core team that kind of understands um how that's going to work and you start from there implementing features and then doing the ui and android and then as that settles you can you know add those things probably in the following like we tend to try to do like one sprint you're doing the android thing and then the next print here um have a ticket to to implement the ios ui and it's um mostly works sometimes it doesn't go as smooth as you'd like um but especially um you know we we're a special case right like um touch lab because like you know i've talked about the memory model so everyone on their team understands it enough really to like to to like get through their day right if you're starting brand new it is important that you you have some people that are going to have to understand enough about both platforms and the unique features of kmm to to code those things out but generally it is a faster cycle to start to to get through your your architectural modeling with an android top looking at it um and then adding ios on top of it which again we can be politically like feel a little bit like the stepchild platform but it's not you know but i will say it's also difficult to code the kmm part in a vacuum without having a front end pointing at it so you generally end up like coding it with android calling into it and then adding the ios and stuff so i guess but we encourage um especially with teams to not make it feel like you're taking responsibility or uh capability away from the ios developers it's it's important to have them like also be able to contribute foulin and be able to push code the other way right so um if it feels like it's an android first approach it doesn't necessarily um attract the ios side to be excited about it so you have to be careful with that thank you the next question um it's it's quite similar to the first one but it's about numbers so what percent of code should we aim to share i think we could separate this question depending on the case as you mentioned small team or a large organization existing up new application but i don't know can you share some numbers um so but no i don't have numbers uh i'll tell you why uh it's it's uh i feel like it's i understand where the question's coming from but i don't think it's the question to ask so um if you're looking at this purely from trying to have a quantitative like i need to talk to the upper management with something um and some convincing thing to to i understand why that uh stat would be useful and i've seen people argue that like i've been doing shared code quote-unquote i was trying to do something with j2 bjc long before kmm so i've been in this um let's say the the the world of trying to sell people on something for for several years now and i've seen a lot of this where it's like you know here's the x percent of code we've shared here's the extra code that you could possibly share but um i don't know it to me it's it sounds a lot like measuring productivity in lines of code um which is you know known to be not necessarily a good way to measure and especially in this context like if you have a large team and you're sharing certain modules like the question is is immaterial to begin with because you're not trying to maximize um lines of code shared but um especially in like what we're doing if you actually looked at the lines even with the greenfield app we're trying to share as much as possible um the ui has a lot of code i mean there's configuration files there's style files there's uh lines of code that are you know you're setting up your ui and wiring up this boilerplate yeah if we if we count zip files and zip files for development we could be very productive modifying our ui right right um but you know not that ui is less important but if you don't have the right radius on a button that's a different thing that you have an incorrect calculation in your tax calculation module so i look at it like um this core architectural stuff the really hard calculations the things you have to get absolutely correct um you know each line of code it's not even so much that the line of code is worth more it's that an error in that line of code is far more damaging so like um that particular line of code is probably a lot more valuable than the one that sets up the radius of the border of the button because if you get it wrong you know people aren't going to get that upset so that's kind of the way i look at it i try not to maximize it so much as duplicate code especially logic code that that has nothing to do with a particular platform it's just adding more time to code and test and certainly update and and maintain over time and it's just adding more places where you can have bugs because you didn't properly change both sets of code uh in lockstep so uh i don't measure percentage but there you go also if your app is mostly ui how much code are you gonna share you probably shouldn't even try right whereas if your app is doing like really really complicated calculations and the ui is like just a text field and a couple of buttons um you know you're going to share almost all of it but so it all depends on what you're building well maybe we should introduce some uh factors some ratio to our modules like ui is not important and uh networking is more important and then people if you say that ui isn't important that upsets people rightly so it's not that it's not important it's just that if something isn't laid out exactly correct it is not going to cost your business an enormous amount of money it'll just get you know maybe a a four star review instead of a five star you know what i'm saying like soon but u.s is very important uh you mentioned this discussion with management then if not numbers what uh what should we use to to pitch kmm to introduce it uh it wasn't prepared but well it's a discussion i mean not those numbers but i i um i i give a more of a logical argument right like um you know the history of computing is is uh it's a it's a progression of an attempted to reduce redundant work and at the same time we're like re-coding the same exact logic multiple times so if there weren't any build barriers or tooling barriers or political barriers to not recode the same logic um you would be crazy not to do it the reason that we don't do it is because there are a number of imperfect uh compromises that you have to make so um if you were going to use c plus and there's a infamous famous blog post from dropbox if you're in our little shared code world uh that's interesting that says sharing code basically sucks but um it's a really good article about why sharing c plus plus code is not great but it's not like it doesn't really most of the problems are related to that particular ecosystem and then it was interesting i was at a drycon san francisco talk with that author and they talked all these reasons why this wasn't good for them and then at the end he started talking about why they're using rust to share code and i was like dude you're like completely like your your point is completely logically blown like what you're saying with rust is in this case rust is a great ecosystem for this particular problem like okay so that makes sense to me um so people often write it up but like if you didn't have any issues it would be crazy not to try to share code and the reason why we like kotlin as a shared code option is is um the the team has done enormous amounts of work to solve the really hard problem which is getting rid of the compromised barriers the interface the interrupt between um the native code and the shared code is uh it's very good and there's one thing i tell people like it's never going to be perfect kotlin is not swift even if you get swift in a round like it's it's not swift so you have to be prepared for some compromise but the compromise in this situation relative to other situations um is a whole different equation like it's much uh much less compromise and a lot of the big problems are at least reasonably solved if not like removed um and then you have to decide for yourself if it's worth it so anybody logically would say like one set of code is better than two they just don't do one set of code because the barriers to having one set are more trouble than their work and the pitch with kmm is that the barriers aren't more trouble than there were right so yeah i think uh this point about this relative thing is an important one so um let's imagine that we agreed on what which parts we want to share how much do we want to share and you've already talked a lot about who should contribute to to became impart that it's android specific but well iris folks they also should be involved so who should own the kmm common code in your opinion in your experience again this this kind of goes into how big your team how are you structuring your code um you know if it's a single i'm thinking of a couple of examples of apps that we started from scratch um and we essentially just keep everything in a mono repo um and it can barely be called the monorail because when you say monorego they usually mean like a huge code base that's in one repo we're talking about shared module android module ios module and uh specifically in these cases the team is too small for anybody on the team to not understand at least how to like modify goblin code maybe not set up a full architecture but they can go in there and add the field to the database or you know whatever um in that case i wouldn't say that anybody owns it it's more like whoever is most senior does the prs i guess whoever is well not most senior but i'm saying it's like who owns a small repo with the small team it's the person who who does the prs i guess um in a larger ecosystem it tends to be a module or a set of modules around a shared thing then that get published as a library uh in that case you are going to have you know a team that is or it could be an individual but a couple of people um it is going to you know it's more likely going to be coming from the android side that's learned enough about ios to function that was my next question of of whom it it contains yes i think i think people minimize the accumulated knowledge of an ios developer and how to function in an ios build environment because the benefit and the difficulty of kmm is that um once you're past the actual source code you're into llvm you're into linking you're into xcode world and just understanding when something goes wrong how to deal with that i would say the accumulated knowledge of how to deal with that is more than learning how to code palin if you're a swift developer already so we found that ios focus developers i try not to say ios developers ios focus people because developers are i like how it sounds yes um if they're open to new stuff some people are just like i'm swift that's it goodbye but like if they're open to kotlin and trying to do some things it's not necessarily more difficult for an ios focus developer to learn how to code kotlin than it is for an android focus developer to learn how to build and exist in an xcode world you know what i mean well it's not an xcode but like an apple tool chain darwin tool team world right uh most android developers like they'll see ld colon and some a whole bunch of gobbledygook and like i've been looking at that for a few years now i could be like yeah you don't you didn't put a link or flag for sql light that's what's wrong but if you're an android developer you have no idea what's going on there so um generally starts with android focus devs ios focus devs who like new stuff actually can pick it up relatively quickly the concurrency model is difficult for everybody but that's a different discussion we're talking here yes um and well for those ios focus developers who who love new stuff for them what's the best way to develop an expertise in kmm because you know there are several approaches you could start from learning kotlin idiomatic kotlin maybe or deep dive into gradle and spent a few nights watching gradle tutorials no okay nothing wrong with gradle but no i wouldn't start i think you know there's a lot of talk out there about how kotlin is very similar to swift um i've spent time like in the kotlin compiler layer and like dealing with the fact that swift and kotlin actually have a a bunch of different things like and how things are implemented but visually it's true they are similar um but i would say you need to uh it's kind of like how you approach any language i think um unless you just started as a developer um you go through that phase where there's some cool new language that you just want to go learn it so you know in the past i've done like i'll just get a book and like read it casually but you know you don't really learn that way but still um you kind of learn the basics of the language itself i think you have to go do that um good go get the kotlin cones or the the works the work sessions online uh there's a lot of good documentation especially um i mean your team's amazing work over the last few years to make this accessible to anybody as a first language uh although i don't know how that's i don't know anybody that's first in kotlin i would be curious to see how that went um but it certainly couldn't be more confusing than javascript let's put it that way uh as a first language but um yeah i think you go through and learn the basics of the language and then um i like to clone or get a sample that exists and then try to do something interesting with it so um do that first i would say approach gradle config later and i and i say that i just spent the last few days wrestling with carthage i just any foreign config system that you aren't experienced with um especially i don't know not that gradle's more confusing than anything else but gradle especially now that you have kotlin script and groovy and the samples are all over the place it's it can be um it can be a lot and i think it learning the build system of any environment could be kind of a turn off like i'm sure people love carthage right now i absolutely despise carthage you know what i mean like just because i i don't it's like too much so not gradle first gradle when you need to do something different i would say that um but i would take an existing project or something from the ids templates and do something fun and then uh the next layer is like all right pick something you actually need to try to solve like something that's not like because if you go through a tutorial and read and it says okay add this you're just gonna copy paste you're not really learning it's like uh you need to have something where immutability exception or you try to do something that like is going to be a real problem you have to solve it so that's how i do it but or like when we have a new birth to start a team like we try to cram in a few basics and then it's like here's here's a ticket and then we'll screen share and talk you through it like that's kind of how you learn you know samples is most favorite option among kmm developers multi-platform developers to to learn your stuff to play with i agree with you it's cool that you at the same time you can just go through the ripple just with the code and at the same time you can modify it and see see how see how how it affects and about uh you mentioned gradle later when you need something to do with i want to talk a little bit more about it uh what do you think is it possible situation for example when a ios developer who is working on the kmm on the shared module then they know nothing about gradle they can write pure cotton but they know nothing about radial work with it like with a black box and when something is needed today just ask the android focused android focus developers greater focus developers for help what do you think is it a possible situation i would say yeah in most cases that's it's not just possible i mean it's probably what's going to wind up happening so we talked to another org not a client yet but they're all potentially class but um no they're not but we we we do a lot of uh and if anybody's watching an interest like reach out to the team we we do like we'll just talk to you for an hour about what's going on not not in a client relationship we do that a lot um so we talked to one and one of the big issues they had was kind of that like the project that they were playing with was mvp and it got set up by an android developer who's probably used to doing gradle um although they're not used to the kotlin kmm kmp gradle so this is different i mean there's a lot you have to learn but um well not a lot i don't want it to stop but there's a fair bit yet um but then they you know one of the big complaints was that well then the ios dev went in and tried to like change a bunch of stuff and add things and i was like did you spend a lot of time learning gradle and you're like well no i was just trying to hack it yeah i mean that's difficult so um i would say gradle is a big surface area to learn things um so it's not like an android developer will come in and just kind of magically solve everything i mean when i go into gradle i have to hack it too i just happen to know a lot more about how great it works um so i don't know i think it is you're gonna have to it is kind of like anything else like it took me um a fair bit of time to really understand how to configure ios and how to configure you know uh standard ios build and then got forbidden to do things in the command line and ci like it's just a progressive uh introduction of more complexity and i think unfortunately more esoteric information so um my carthage example like if you're going to have one repo per module in an open source situation carthage is very easy if you want to include a kmm binary library inside of a single repo where you also have ui code which is a separate ios framework it is not easy and you'll also uh not surprisingly find basically zero people who have to do that so like um kind of the same situation here like it's much better now but if a couple years ago you had to go look up how to configure a static framework in kotlin using cocoapods like you would find basically zero people without like you have to understand uh not only how to figure out how to do it like you have to understand frameworks to some degree on the ios side like there's a lot you have to learn so it is it's an incremental process of increasing complexity so i don't know but it would be good i guess to learn basics of gradle i guess i've been doing gradle so i don't remember how i learned cradle so bad enough read a doc and then you see some examples and then it doesn't work and then try something doesn't work and then you go to google again and again and again or you go to the slack group and then you ask them anyway okay so somebody just reached out stay step-by-step conversion example for kotlin gradle it was stacey you know anyway um next one again is about ios development but well it's quite expectable because as you mentioned in the beginning kmm is more android centered android specific and well android part is usually pretty straightforward so today the best questions and the most discussable ones are about ios integration so how do i package kotlin ios code how do you share ios frameworks again you've mentioned kind of some approaches but let's let's systemize them all okay carthage throw it right out in the garbage uh no i'm just some sounds sounds like a song yeah we're getting close there um it's so i would say for for um obviously the unit of code that kmm is going to output is an ios framework for an export framework i guess it's probably more formally um even then it's kind of a if you make a dynamic or setting there's a few things to figure out we tend to lean towards static i know even though dynamics sounds like it would be better just by the the terms but um i don't know i actually you could probably explain that better than i could like what is the industry doing uh you know versus static versus dynamic but i feel like it was static and then it went to dynamic for a little while uh and now it's like static but anyway um we for uh the smaller apps the greenfield single team monorepo things we just use it's actually the jump rings cocoapod plug-in the plus side of that is um it's generally easy to configure i we had a fork for a while that allowed us to directly configure the framework um gradle thing so you could like set some fields like there was no easy way to set um a framework to be static like everything was dynamic uh we just wanted static and we also have an issue with debugging which is no longer a problem um we reverted back to the jeff brain's official who's you know maintaining somebody a fork or something is his work and there's no reason to anymore um so we you have to have the jvm installed you have to be able to build locally uh but otherwise it's relatively straightforward and um the round trip of making a change and then hitting you know play and xcode or the kmn plugin if you're using that um is fairly well integrated i mean the build time is longer on the ios although it's improved it's a great time to mention that with the latest version of keyman plugin wizards can create this structure with cocoa pods for you because previously it was only with this regular framework option with a separated gradle task but now you can generate the needed uh gradle build file for cocoapods integration also yeah and we i it's partially because of who we work with often uh we tend to be i don't know if it's a random sample we tend to be working with teams that are more cocoapods focused so i found that to be a reasonably straightforward way to configure projects even though like apple clearly doesn't care about breaking the cocoa that's world when they change execute definitions which is like fine well not they don't care but it's not top of mind so anytime like there is a long-term concern about whether or not cocoapods is maintained right because you know you have to and i would say carthage is running into that now with the adventist package management so um but that's a much longer discussion we do um for local stuff we use the cocoapods plug-in i don't think we do much in the way of just direct uh framework congestion then pack for xcode um then we also with larger teams um more specifically around cocoa pods but also carthage compatible um we have sort of a not yet open sourced thing that will build a framework zip file and you can configure which modules you want and then publish that like a pre-built binary and then you can consume that cocoapod carthage actually works as long as you have one repo for that if you try to have two modules one rebuild something like that that's all um for me because i understand cars interesting but um unexpectedly uh a lot of uh mentions of carthage the last few days was just like this should be easy i'll just bang this out and then three days later i'm like i can't believe how not easy this was but uh anyway no so we're um for our larger team clients we you know we have some we we're working on a thing i don't know if we're gonna open sources or not uh we'll see how how mature it gets but it publishes um zip files and uses cocoapods to do uh pod spec private prospects and then the benefit of that is you know if you um want to add that to your ios build this is just another cocoapods binary that works the downside of that of course is that um if you're consuming packaged sdks you're not really getting into coding kotlin itself uh if you have a bug of some type you can't fix it yourself is much bigger and it's it's not specific to colin like this this is a long term problem and um what you get is always wanting to do it that way because it's easier mechanically but it doesn't foster the idea that you're not an android ios developer you're a mobile developer which we encourage uh strava because it allows um it's just better for development so what we we do is we have a little flag that um it's an environment variable now but if you want to just do local development you can flip that and then make sure you have the right repo and you point out the right way you can quickly go from binary to local uh development i think that that's pretty important otherwise you get this yeah long round trip cycle but you know sometimes uh most large works it's like yeah we get what you want to do and then the perfect world we do it that way but you know you have an internal sdk publishing team and that internal sdk consumers so um that's how we do we haven't done anything with package manager yet uh i forget the name but there is a gradle plug-in that exists for kotlin to do that i was experimenting with last night because you could also get xc frameworks which some documentation in the people in space sample uh you you can find an example of this plugin john o'reilly as usual hi thanks for watching thanks for all the samples now he's he's great uh we we 2019 joycon we i unofficially made it to the kmp summit and uh we had all the all the people you'd wreck john came out for that uh it was interesting but anyway so yes you can use uh package manager we i was experimenting with xc framework last night because carthage doesn't like that frameworks or whatever uh didn't work out though carthage still could be trouble but um yeah that's how we would practice stuff but like any i would say as you get into larger teams and orgs like any any internal build system tends to get more and more customized so it's kind of hard to generalize after a certain point thanks uh again it's a good uh time for mention for some release notes because we are talking about km and ios integration with the latest kotlin release various kotlin multiplatform gradle plugin now provides not for pack for xcode task it's the new task but it serves the same proposal to uh to allow you to integrate xcode and your shared part and you can do it now you can now remove this pack for rexcode tasks and make your your build greater files and add some magic finally finally we get away from the copy paste method of software yes yes finally no judgments it was great okay um okay so next one again they dedicated to ios development but we we talked we talked a lot about it today but well it's really the hardest questions so how does kmm impact binary size that is a great question and we get that oh yeah um a lot i had planned on finishing a blog post before this event i did not i've been threatening this blog post for at least a year and uh and every time someone asks this question in the kotlin slack i write roughly half the blog post uh explaining this but i will say the following um well now with the public it's a public promise so i know you'd be surprised how much i like ignore public promises like that but uh only the ones that matter blog post is okay um so uh the first thing i think that comes to mind you know um you get to set the stage and a lot of times it is again an android developer that is pitching kmm and they'll get this question and you know usually the freak out moment is i ran this i looked at it and it's 30 megs and the first thing you have to say is like that's not how you measure on ios so like on android if you look at you know the the actual uh apk um that's what it's going to be when you download it on your phone it's a little different now like they do shave some things out of there but uh ios world is very different like once you upload a binary um you know there's apple servers somewhere that are magically chopping all the stuff you don't need and making specific binary packages for specific devices because not every device needs all the resources not every device needs all of the architecture um and i you know it's a good practice anyway and google's been doing more of that but it's been more necessary in ios because the reality is like binary sizes in ios are crazy like at least relative to android it's already judgmental about the ios world but um like look at uber on iphone versus android it's it's crazy and like um i'm sure there were points where uber like you needed to get on wi-fi to download it and usually you need uber when you're standing on a corner somewhere and you need a car so where's the wi-fi i don't know um so you have to measure it properly we used to upload the binary and sample project to app store connect there's ways you can do it locally too but it's it's it's significantly more involved than just looking at the figure out disk so step one is measuring a problem um what we did then was we created a sample project that was just swift with no logic in it and then measured that against adding a really basic kotlin module piece of function right we just added a function no libraries no nothing and you kind of pay an overhead of runtime and just whatever so that works out to about 500k on disk 150k over the wire which is the compressed size um and then it's sort of like the the tax you have to pay uh the next question is great like how about the growth in binary sizes you're adding logic so we did a test where we generated very simple not production equivalent classes but we just generated a whole bunch of classes we measured at 50 classes like 100 200 500. what happens to your binary size over time and we did that logically equivalent swift and kotlin classes just to get a sense i will say in general the binary size growth is equivalent and linear at least in that arbitrary test so after like 500 classes that added something like two meg to both right so that makes kotlin look very good as far as like something you can integrate the negative part when we got a bunch of freak outs from people not a bunch but a few reached out they're like hey i added a bunch of sql delight you know added 100 tables and all of a sudden you know it adds tenants yes well it's not it's not that so this is a secret thing that we kind of figured out it's not really secret but it is if you have a lot of small classes especially if they're public that generates an objective-c adapter or interface interface is kind of a loaded board so we'll say adapter right and objective c is a dynamic language in the same way that like java is a dynamic language swift is not very static compile as is kotlin name so um in order to interact with objective-c you need this adapter and i should i'll share the charts in the thing but like if all of those 500 classes are public it's way more than two minutes something like it's like five or seven or something like that and if you make all those classes uh internal it goes back to just being equivalent so um there are actual best practices which are try to make everything you can internal and then there's some things we've experimented with like it's useful not only for binary size let's be honest well i know i know just a good practice but there's a lot of moving parts there you know we're experimenting stuff um but you can make it equivalent issue you have to be aware of these things but what i generally tell people is they're usually adding a module or a couple modules and they're going to have the usual suspects for dependencies like sql delight ktor uh serialization and i'm like yadda yadda it's like one to two megs that's like the answer for everybody unless you're doing something significant so it's gonna be a couple of eggs and in the ios world it's i haven't talked to a lot of people once they understood that especially that public visibility problem um there aren't many teams that have that i've heard of that have not implemented it because of the size yeah i i had with such experience so first thanks for numbers second we are waiting for the blog post post and uh i totally i totally agree i was gonna say if if you were bored now wait for the blog post you're gonna be i totally agree about this point uh was first with zero point about uh uh measure properly because i've also got a couple of questions about oh my gosh the binary is big but it turned out that they're measuring fat binary that was built in the development mode and all the stuff about you mentioned about how bitcoin is working for reducing binary size for uh final applications so yes this is really important and that's why again we need your blog post i will send it later for when i receive all these questions so i would say the best the best way to get the blog post is public shame so just uh keep people tweeting at me for that blog post okay so the last one from the prepared list and then we will go to the community questions and we already have some really interesting ones so if swin if swift interrupt is introduced what does it fix do we need it at all or we can just work with maybe objective c interrupt and well everything is working what's your opinion here it's an interesting question um so immediately talking about binary size i suspect if you don't need that objective-c adapter that directs with interop would get rid of the public um interface problem to some degree so the binary size would probably be less dependent on that however i i feel like um this goes back to another blog post eventually that i made right that is called like it's never going to be perfect and um there's a lot of pushback on the fact that it's objective-c interface from let's say the ios focus developer ecosystem but um the reasons why people like swift are not it's not just a prettier language like there are structures in there um like structs there's genomes associated values those things are not going to exist even if you have direct swift interactive columns because they don't yet exist in kotlin there are equivalents right like data classes feel like structs right um what sealed classes oh man i was about to fail my kotlin test seal classes feel like you have associated values at least logically but you're not going to have those things right um i would say you know one of the things i did now going back a couple of years was i added objective-c generics to the output of the kotlin compiler right like that was my major contribution to the kotlin uh proper thing and um you know kotlin c and swift are different languages so um we were able to add at least some usable generics to the objective c and they're usable in swift but like objective c has some sense of variance kotlin has a more sophisticated sense of variance swift does not so you're able to cast around those problems if it's coming from objective c but direct swift you would not be able to so you'd probably lose a lot of generics or at least be weird rules so um i don't know it might improve performance some i suspect it probably would uh but but like not at the degree that you would ever notice unless you were measuring really really crazy if you are crazy on measuring you may notice you might um so i would say um anybody that is like waiting for swift interrupt before they use kmm uh i think not to judge but it's like you're not going to get the things in the language that makes swift swift right kotlin is different so it's never going to be perfect not that objective cd's interface is perfect either but um i wouldn't wait for sure like uh so i'm like it's to me it's not other than it's like a check box item and people are like is there swift in a route but i could say yes great but it doesn't change our day-to-day coding at all i think this is a great time to refer our audience to visit our roadmap page and yes you will find the ticket the task where you track ticket with direct swift interrupt there but you will also notice that it's on pause now because currently the uh the whole focus of the cotton native team is on the new memory memory management approach and maybe we'll have time to discuss this question also today but maybe not we'll see uh it's a question we we could uh arrange a dedicated webinar for that uh but let's decide later i'm sure that that will be one of my conference talks uh sometime later or next year uh only after a blog post please agreed on of course so um as as i as i said let's move to the community questions and let's pause a little bit our ios discussion uh and uh there is a good one um what is the best way to build internal libraries that can be reused for multiple projects uh it's a relevant question for big teams and big organization like sdks how to modularize properly is is local marvin enough or not uh that's there's a lot in that question and i'm not sure i understand all of it um to go from the you know uh lifo direction here um local maven just published a maven local i guess um i don't know that it's enough i mean i don't know how you would share it with anybody we do a lot of that when you're developing locally but then when it's time to like share the thing so you need to publish somewhere um you know oh my world is kind of split between open source and not open source so open source we're doing just maven central now that pinterest going away or whatever uh i would say no local maven is not enough when you need to publish because obviously you have to share with people we are doing a private thing now with an internal sdk team that is publishing to i think github packages um so we'll see how that works out we're not publishing calebs we're publishing uh i guess terminal things so esco framework or aars so i don't know if that would actually work so i can't answer that question unfortunately but um how do you marginalize popular i i that's a hard question too like uh i think that's just software development skills like i don't have anything specific to kmm that would be um a different answer than how would you modularize in in an absence of sharing code do you know what i mean once you've selected things that are going to work for kmm i think that it is like a normal modularization thing now uh and specifically km and ios you know if these modules need to be able to talk to each other in any way you're going to have to package it with a single framework and that gets much deeper in the rabbit hole of kmm world um so yeah i don't really have a specific answer that's more than like what you would do uh normally i'm sure that when this call is over i'll think of about a hundred things because we're doing this we're actually doing this with multiple teams this is turning out um i guess this this is news for everyone it jump right into it seems to be um more than i would have guessed not that i wouldn't get slow but a lot of teams are starting to publish at least trials of internal sdks that are okay from kmm uh like we got one surprise this past week because it was like they filed a bug and i'm like where is this code and they're like oh here's our you know sdk publisher oh it's amazing um i have no idea what your bug is but like it's amazing that you're publishing your library that way so anyway sorry i don't have a better answer for that no problem um another another one and i'm sure here is a good space for discussion what do you think about combining modern android and ios sdk tools with kmm um ios sdk tools i don't understand the question i initially thought that uh it's about uh ui tools your declarations maybe maybe let's pretend uh this is that better option but if not please the offer of the question specify what tools you're thinking about so i mean um yeah brady from our team hey brady's this week wearing it working on uh camp kit composed as a public example and then if we get to it we're going to do the joycon app composed uh and the android world you know compose is stable sometime in the coming month according to uh google's projection so i think um not incorporating compose at least in at least understanding how that would work it's not like everybody's moving to compose overnight uh but you're going to need to be able to interrupt the question is does that change your architectural organization that's actually kind of what we're focused on now but again going back to john o'reilly is arcadie's doing a lot of stuff to decompose there's a lot of things going on in the ecosystem around how to attach compose to kotlin and knm specifically where that it to me it's more of an architectural question than is the technical question because technically they go together fine swook you as a different question and i uh we tend to focus our attention on the kotlin side of the world um so and and i also try to keep a pulse on the community the ios community like how much are you using swift ui and the rollout hasn't been let's say entirely smooth so we've been less aggressive at um our team jumping into that research um where i'm not going to say why but we've been experimenting with actually driving ui kit layouts with compose on ios but uh don't get too excited i don't know that that's gonna really work we can't get too excited when we hear a compose and iris in one sentence i know but it's time to be not excited it's not composed it's not composed ui it's not like a custom ui this is purely doing layout uh but it's because the japanese team the web team is doing like this they were doing like this common widgets thing with compose so i was trying to adapt that to ios as well but it's uh mixed results we'll see how that goes okay and uh well the last question kevin sorry but i just can't let you go without that kind of discussion so i think we are ready for it yeah what's up with mass trading yes are their best practices especially taking into account that we all know that we are working on the new memory management approach i think so this is the bigger question it's it's bigger than just practices how to write code and there to write code um so what's up with multi-threading i think is um let's try to condense that as much as we possibly can uh at runtime your date is mutable it has to be in a single thread or it's frozen immutable and it can be shared across threads that is the most condensed way i can explain what's up with multi-frame um and what you just mentioned like the team is working on uh changing that model so that it is and it's it wants to be clear it's only a native that does that so it's confusing for people that are coming from the android world they can do whatever they want and now they can't um so that memory model will change i don't know that we know exactly like is it going to be exactly like the jvm where you can do what you want or they're going to be more rules i don't know if that's been entirely resolved yet um but i would say i've been talking about this for last few years and i conceptually think it's not a bad thing because it forces you to think about the places where you could be doing something that is problematic but in that weight against people having to learn it and running into problems and like once you get a really complicated object graph you can freeze things unintentionally it's so it's not necessarily good but what's going on is we tend to focus more on i'm explaining to people general patterns of usage now than just trying to explain everything that you're writing about well especially because it is going to change at some point and it's whatever so i would say best practice is um you should be intentional and aware of what parts of your architecture are going to remain mutable and which ones aren't um and i think that's good uh recommendation in any context so you should be aware of what parts of your code might be going into a different thread so you're not touching parts that aren't in that thread and doing weird things um i think the native model forces you to do that even more so um we tend to do view model layer stuff don't have to get deep in the weeds of mobile the view model layer stuff tends to be not frozen intentionally mutable and then everything else assume it's frozen and it's coming from the data and you shouldn't you know you should be transforming data not modifying it anyway so stuff coming from your database should be you know uh immutable data classes things like that um i would say best practices we use the multi-threaded co-routines branch most of the time if you don't if you're just using that to go across threads you don't have to worry about freezing anyway because your data will get frozen where it needs to be so it's not a lot to worry about and if you're not coding like libraries specifically around concurrency um there's really nothing that's going to change in your code when the new model arrives so it's not something to really worry about should you still go read some blog posts perhaps by someone on this call about how to do this stuff like sure because you're going to need on you're going to need to understand it but uh i wouldn't say you need to do a deep dive like perhaps not watch the talk at kotlin comp that i gave but the feedback was like uh there's too much in there i'm like okay that's fair but um go to the hands-on tutorials on the the km site um that's certainly enough to get you started and you don't need to worry about it too much um but yeah like i worked with the coin team on their native implementation um that's gonna have to change because it intentionally directly deals with concurrency in the management uh we have a library called stately i don't know what the purpose of stately is once we don't have the same restrictions because it's entirely around concurrency so if you're not working on that kind of stuff it's not a big deal agree it's a great time again to now mention our kmm documentation portal and kevin wrote a couple of articles about multitrading and i think uh their level is quite quite good to you not to get i would say tired for it but to to get where the needed understanding just to just to be confident that you but well you understand what's going on so please visit km documentation portal and also there you will find a lot of articles and we also have an article with a set of frequently asked questions um they are much simpler than those we discussed today and for for that for the discussion kevin thanks a lot thanks a lot it was great thanks for having me um a lot of great advices and numerous mentions of carthage unexpectedly i i i'm not sure i can't but i'll try to and uh public promise uh great great discussion and uh again great answer so thank you and uh that was 10 questions you always wanted to ask about cotton multiplatform mobile i'll i feel that it was the first but definitely not the last km webinar so again don't forget to subscribe to our channel not to miss the new content and see you later bye bye you

Channel: Kotlin by JetBrains

Views: 3,490

Keywords: Kotlin Multiplatform, KMM, Kotlin Multiplatform Mobile, Kevin Galligan, Kotlin cross-platform, kotlin cross platform, kotlin ios, kmm Kotlin, kotlin for ios, kotlin mobile multiplatform, kotlin, webinar

Id: P8DvF4-9Uq4

Length: 67min 58sec (4078 seconds)

Published: Tue Jun 29 2021

Reddit Comments

[u/dekonta]

What does kmm stand for in particular?

[u/rypher]

I'm very excited for every new stepped in kmm. I've been using it for personal things on the side and each of these releases changes the argument at work more and more in favor. I love it.