Brand New Kotlin Multiplatform Podcast: ATOM
welcome to a touch of multi-platform a new podcast from JetBrains and Touchlab about the multi-platform technology evolution and its grow and the community that's growing so my name is Kate i'm product marketing manager for Kotlin and my name is Justin i'm the director of project strategy at Touchlab in atom a touch of multi-platform we invite multi-platform experts to discuss where all aspects of Kotlin multiplatform technology from its evolution and how it affects developers to a variety of use cases with available insights about how to maximize the benefits of using Kotlin multiplatform in your project we've got a great episode for you today we've got Dimitri savinoff the Kotlin multi-platform lead at JetBrains and Kevin galligan the technology partner at touch lab to talk about kala multiplatform mobile and the road to beta and how it's come so far since january 2020. great i'm excited but uh before inviting our guests Justin uh i i think we need a short warm-up you know to to have a good dynamic during our interview but please let's not discuss the weather it's quite cold and depressive here oh it's bad over here in connecticut too although i like the snow i don't like the code the cold um but every morning um besides bringing my son to school i look through some news about calling multiplatform um not just about Kotlin multiplatform because i care about everything that's happening in the multi-platform world and recently i saw um a blog post about a a team that was moving from react native to flutter and react native and flutter are both great technologies but on ios the support is not so good they keep running into animation jank issues which has been a problem for quite a long time the nice thing about multi-platform of course it leaves the ui choice up to the developers you can start with native ui and i think we're going to talk a little bit about multi-platform compose later which might change things but the nice thing is it's still going to be optional you're going to be able to use the best choice of technology for your use case great i always when i when i need to use just one more to discuss all the benefits of Kotlin multiplatform it's flexibility for me i think it describes in general that you're able to use the technology the amount code of your want to share uh depends on your own and on the requirements of your project you know my favorite kind of articles is articles about how a specific team is using code and multi-platform for their needs and the one i i read last week and i enjoy it a lot uh is about uh the story of super awesome which is a part of epic games right now and uh i want to read the quote uh from this article and it's a reason uh why why i enjoyed this article so much so um i began as android engineer and now i'm an ios engineer too when i joined super awesome i had limited ios experience i started out working on the kmm and android modules given i was effectively beating building uh the majority of a feature across both platforms i quickly it quickly made sense to develop my ios programming so i could build the complete feature for both the fact that 45 of our code is shared afforded me the time to do this so i like with hidden feature of uh of Kotlin multi platform that uh like it pushes you to become you know the full stack mobile engineer and i believe uh this role uh will be more and more important uh in the future that's a great story do you have a case study for super awesome on the jet brains website not yet but it's in our backlog okay so you've already reached out it's gonna happen that's great to hear um right today we have um our guests let's start talking to them now um hi Dima hi Kevin hey hi there's no doubt it was quite an intense two years for Kotlin multi-platform let's start with the most noticeable event for mobile developers the Kotlin team focused on mobile code sharing and announced that Kotlin multi-platform mobile went alpha could you tell us please the reason for such a decision and what changes did it bring yeah that is actually a quite an interesting story in my opinion so uh usually in jailbrainz in general in Kotlin team specifically all things were built uh basically with you know with a lot of passion with a lot of inspiration and this surprise for multi-platform as well so that was kind of a cool technology we can build as a team we saw that yeah well that would be awesome if people could share the code and choose what they share what they don't want to share and that would help people out there so that is what we usually strive for but that was not planned for anything so we were just building the compiler which can compile code into you know multiple targets in javascript and native and at the at that moment when the multi-platform just started we were not thinking about the use cases or the product we were just building the good technology and then eventually we started to notice that uh this technology finds it users and fi and some people are excited about what mobile code sharing people excited about other cases as well like for example the web use case but for mobile it was the most you know uh outstanding case out there like people were really excited they were asking us when it will be done like what we are doing for that case and at that point we have realized that we should kind of reposition our mindset about this and start thinking about just technology because just compiled doesn't solve the problem for you you need that to change you need the id you need the dependencies and that's how the Kotlin mobile multi-platform has been born as a product and that signifies the pretty big change in the mindset how we treat the multiplatform here because now we care about the full product they use the experience from the beginning to the end so and yeah exactly that here was really a big year it might not seem from the you know perspective of that not that big from the perspective of features or something but still it was a big change an attitude Kevin how did you feel about seeing that in the in the in the store that first app um well it's it's interesting we'll go too long on it but uh i got pretty excited when i finally saw an ios sample in the Kotlin native repo we were keeping an eye on it but um you know at the time i wasn't sure really if it was ever going to it sounds crazy now but at the time i wasn't sure that there was going to be an ios implementation of Kotlin native all the samples were like linux or desktop so and even if it did the first one still we had to keep in mind was wasn't like if i recall correctly it wasn't like shared code it was like you're going to write your whole thing in ios and get one executable out but it was like two weeks after Kotlin comp we were at joycon san francisco and i was determined to get our app using Kotlin native and uh it was once the JetBrains app came out it was like well you're not first you're last so we didn't do that but it was uh it was pretty neat it was it was pretty interesting to look at to think how far it's come in that span of time if you because i remember looking at the source code for that app and it was like this is interesting it's going to have to approve but it was amazing it was amazing to see it work speaking about this focusing on Kotlin multiplatform mobile i saw some confusion in the community uh when we just gave this announcement of Kotlin multi-platform mobile went alpha and questions were like uh what's the differences between Kotlin multi-platform mobile and Kotlin monte platform do i need to migrate my projects so let's maybe give a short explanation of these differences or there are no differences at all so what is it called and multiple from mobile uh yeah so i hope i gave some context on to clarify this kind of a confusion so the Kotlin as i have said before the Kotlin mouse platform is a technology so on its own it's it can be used to solve your problems but it's not exactly the solution for your problems and it can have a lot of applications so we can actually see that multi-platform as a technology can be helpful not only for mobile code sharing but for other cases like for as i mentioned the web development uh back-end plus front-end uh you you call it but the the code bio mobile monitor platform is exactly the case we are focused the most currently which doesn't mean that other cases do not exist we actually try our best to not block other cases and weigh down the good foundation in the team so whenever we try to design a new feature it usually code by Kotlin mobile case because that's where most of our users are currently but we always try to think quick would this feature be useful for other cases maybe i can generalize this construction in a blue script and make it helpful not only for i don't know ios artifacts but but also for js bundles or like back-end charts or something like that so we always try to think about this because yeah while this case is important for us the multiplayer from the whole technology is also what we care a lot about so it's interesting i kind of want to address a couple things and it's the the Kotlin multi-platform mobile um focus the uh the technology started as as interesting tech and then and then became it became the focus on mobile seeing the community response we kind of came from the other side completely so a couple years before um Kotlin multi-platform we were focused on this thing called j2 objc which you know uh it's an interesting piece of tech that technically works i like the water use interesting piece of tech i mean very worse but uh you know we spent a lot of time because i personally and and to to some degree the org because when i get obsessed with something the org to some degree gets obsessed with it uh we you know android and ios under the hood are if you took off the change the names of the sdk calls and stuff like they're almost entirely the same they both have threading and sql light and they both do network calls and they both have local files that you can name go down the list they're they're essentially the same thing um and the reason that you don't really share code is i would argue purely because of the the the impediments to doing so like the technologies around it uh tend not to be the focus of the you know google is not really focused on that per se certainly apple is not helping you trying to get your android code to work very much let's say but uh it just made sense if you could solve the the resistance between doing it the tooling and all that kind of stuff eventually it's just it totally makes sense to do it and we over time found the things that were wrong about the approach we were taking j2 objc just happened to all of those major problems around long list but when Kotlin multi-platform came out to me it was like okay here we go this is another approach that hopefully this time like this big company will figure out these these resistance issues and and we kind of went all in and to me Kotlin multi-platform mobile as a focus sends a message that you understand that that's like the killer app quote unquote like that's where you're really going to find a lot of traction and to the community and myself there's that hanging question of like are they going to continue doing it or are they going to continue supporting this are they really going to do it and like seeing it go through these progressive stages of um stability and formality and that jet brains is definitely like all in they're going to make this work um it certainly took us to like okay we forgot like maybe the tooling isn't there now certainly in 2018 it wasn't but it's going to be like they're going to figure it out so it's been interesting to watch from that but yeah we were early on crossing our fingers like please you know please please make sure you take it seriously because like somebody has to solve this problem you can totally do it i checked that the first commit to camp kit i think one of the most popular projects aimed to help developers to get started with Kotlin multi-platform mobile so the first commit was made in december 2019. tell us a little bit more about its creation and how has it changed during this period including the changes uh uh related to focusing on mobile uh multiplatform mobile okay so around that time um back when people used to do in-person events which hopefully happens against them we i mean we in new york we run the big android meetup we you know we ran android conferences like we were super involved in the community and i started spending a fair bit of time going out and talking about the technology and trying to get people interested in trying it out and whatever and the common thing i would get one person specifically uh said you know we had a hack week and i tried to add some code to our production ios app and it took like it just took a long time to get started and i asked well what happened like well i found there's if you go on the website it talks about gradle and then i googled the blog post and i tried doing that but then i saw the blog post that he googled it was like hopelessly out of date and not going to work so it was really hard to get started if you just wanted to see something work so we were like all right camp kit is going to be you clone this you open it up in this tool you can run it and then you can progressively get the information about how to do things so we try to remain relatively unopinionated around architecture um a lot of the time it was trying to explain the concurrency model which we could talk more or less about later and um it was basically just you could you'd have five or ten minutes to get from i saw this repo to i have something running and that was really the goal and then from there you could you could expand out and implement something in your code like at the time kmm or or Kotlin multi-platform mobile um wasn't like the public specialty and so camp kit was trying to make that um that something that was easy to do and we put a surprising amount of effort into making a very very lean sample app i never would have guessed how much that would take because if we were taking feedback we had we were actually removing stuff removing stuff we're moving so um we had that launch and it was very popular and then after that um the k the mobile the multi-platform mobile specific website and documentation and the focus from JetBrains uh came about and then i would also argue there's several other uh really interesting sample apps out in the community so um i would say our a lot of camp kit is like a little time capsule stuck in early 2020 and it hasn't changed a lot so we're in the process of switching camp kit from this is how you get started to we're going to get opinionated and change it into well this is how we build stuff or how we architect things at Touchlab to be sort of the i won't say bleeding edge of a multi-platform mobile but certainly i would say uh solves a lot of the issues that people run into in the first go-around like you know going from shared code to android is relatively straightforward it's all Kotlin going from share code to ios has a whole bunch of discussions and decisions you have to make and so that's what we're doing we're in the process of doing that now so if you were just starting to develop chem kits right now uh it would it would look like more the set of of golden rules of how to architect your app yes well yeah i mean so this this is uh dovetailing nicely with internal efforts and some of our services side which you know i won't get turn this into a commercial but um sorry but yeah we are focusing on um doing a better job of documenting and publishing our best practices as a team also our team's been growing significantly so we're trying to keep everyone on the same page and um because it's relatively new tech we found a lot of people in the community are like well what how do you do this and so it's it's okay to get opinionated to tell them how we've decided to do this because we've been doing it for a few years so it is pretty much that it is the public expression of how we've the internal decisions we've made around architecture um it makes it somewhat tricky because not we open source a lot of stuff but not everything is open sourced and it's not necessarily because we charge for it it's because we don't want to support it yet um it's one of those things that the open source people don't tell you is that it costs just as much to support it too so you got to be careful um and there's we're in the phase now of a of new technology tends to have a handful of people doing a lot of things okay and it's turning into a larger group of people doing one particular thing really well so there's consolidation around libraries and stuff and we're trying to we're sort of navigating that and making library choices all as the technology is improving it can't get just like that the most public expression of where we're at internally and hopefully we maintain but we will maintain that over time it won't be another two years from now time capsule looking back but that's what we're doing great uh it was a super useful project before we we got all this documentation and other samples and tooling uh now simplifies our job and i believe with all these changes you describe it will be again super useful project so just thanks again from the team and from the community for it yeah that's a pretty cool story i can share like one interesting point if we have time for that if that is okay because it really resonated with my previous point about like the change of mindset regarding like moving from technology to a product so you know again a bit of a context of how the Kotlin team functions or used to function at the very least so uh the dog footing was always the extremely big factor for us in building the uh language and the tooling we're building that tools which we all use so we try to make them enjoyable for ourselves the same with when which the same with scotland started as the language for jet brains to write their products and yeah it turned out to be pretty successful so far and yeah so with the multi platform we actually encountered a new problem that we are not the mobile developers so we certainly can get some kind of expertise maybe we can hire someone with their mobile expertise but in the end we are not people who using this on a daily basis to write our own applications this was a very interesting new you know experience for the Kotlin team and we are incredibly grateful for the community who really helps us to get things right because previously we could hope that we can try to find good solutions for problems but now when it comes to mobile where we are not the experts well we just cannot even hope for that so thanks a lot to like that to touch up to everyone who contributes to this because to everyone who for example answers our surveys about multi-platform ecosystem because it really helps us a lot we would not be able to do this without you thank you yeah technology is fun um when you start thinking about it as a product it starts to become more effort and just like with open source like it's fun to do um it's nice to get your stuff out there as Kevin says it costs money to actually maintain it and do a good job with it um another thing but the benefit is you do get that feedback you get to see how people are using it um one of the downsides um is that people see all your stuff out in the open but that's good for the for the for the developers who are watching what's going on they might see some surprises um Kotlin is open source jetpack compose is also open source and a while back um some people noticed commits for composed desktop and they were like what's going on over there um and then lo and behold we got desktop we got compose on the web compose is now a multi-platform um technology uh Kevin and Dima what are your thoughts on multi-platform compose so it is an interesting thing like i i'm pretty careful to to say uh in my talks that uh it you know shared code or shared logic you know using Kotlin multi-platform we're generally not focused on ui but i don't mean that to say that you should that that's never going to be a thing or something we'll never do um it's just that uh it's not like a lot of the other tools to simplify the job of making this cross-platform thing i would argue tend to only operate in their own universe so it is significantly more difficult to include some react native inside of a native native app and it's difficult to include flutter inside of an otherwise native app i mean i'm sure flutter fans might just disagree with that but um it's true right relatively so Kotlin's designed uh a lot of time i would argue a lot of the the difficulty and the time take to to implement it is dealing with the fact that it interrupts well with the existing platform and that's a much harder problem to solve so i obviously am not privy to any secret information but i do expect that you know doing some screens and compose and ios will eventually be an option and at that point you know i had this discussion over the weekend on twitter actually it was um i people were like wary of it they're hesitant you know and i'm like yeah you but you're thinking about like okay now you're gonna do all of your screens and compose and i wouldn't think about it that way i would say you can start with maybe all of the setting screens that everybody touches once or never you could do them and compose and then but you can also do your your main screens in in fully native and you don't have to make a big decision and that's always been the benefit of Kotlin and would continue to be if composed for ios perhaps ever it appears right um we can go on a big long discussion about this compose ui and compose runtime and there's definitely people running compose runtime on ios today it's just the ui is a much bigger thing to implement so yeah so i agree and that's a critical point about the philosophy of Kotlin in my opinion like the good interoperability and flexibility as katja said in the beginning like you you choose what you want to share and definitely in that regard we would be very happy to see a rise to of you know good ui framework multi-platform framework why compose currently moves in that direction with the support of desktop and web targets and definitely like this question appears so what like are we going to do uh i in Kotlin in jet brains are we going to do the ios compose so i cannot say that but i do want to update the status a little bit here because last time we answered that question it really looked like a very very far away effort from last week we knew that we have to do a ton of work to make that happen like on the all levels of ecosystem and our two chain in libraries and how they are published and how they are compiled so we are just yeah we would love to but we cannot do that like we have better stuff to do unfortunately and now like two years uh two years passed and now we are much closer to the technical possibility of such big and cool frameworks like a multi-platform compose and like well multiply from compose already multiplatform for the desktop and web so it proves that such libraries are possible and yeah that that is just pretty cool that the technology moves there and it unlocks a possibility to avoid such libraries really hope that we will see something cool let's hope and smile um the next topic i want to suggest is well guess what uh we are discussing the biggest changes in Kotlin multiplatform ecosystem during this two years we have Kevin here and well i definitely want to nominate memory manager memory manager because uh when we speak about uh about the obstacles the developer face during their way of integrating kmm of course it's the i think it's the first thing which come uh come on mind and uh thanks god uh it's now not relevant because the experimental version of the new memory management is already available uh it lifts the existing restrictions on object sharing between threads and don't require any special management or annotation from the developers so yeah the this this is the big change definitely and uh i think i have questions for both of you let's start with Dima i don't know can you describe how i think it's as it's a huge change i assume it uh it took a lot of effort from a team and can you elaborate a little bit more and maybe share some details on uh how how difficult it was to to have such such a big decision to start implementing the new memory manager well yeah so i'm not directly in charge of the Kotlin native campfire and there's a separate team for that and even i know that that was an incredibly difficult decision for us so yeah like that's like it's fantastically difficult but it it it's really cool that uh we got so much feedback about the memory model about the you know the freezer freezing memory model because it really showed how you can came up with really cool ideas and and yet just adjust and like uh reiterate on them looking at the feedback you provide and the community provides and what i can say for sure that it would have been impossible to like even think of a decision of scraping away the old memory model and going with the new one without the feedback and without the surveys without interviews our team was doing with the community so yeah that is pretty cool because the change is incredibly big and difficult it basically requires to rewrite the full uh garbage collector and garbage collector is like i don't know what like 90 percent of her hand time 99 percent of her time like a lot of fun time so yeah that is again i think this is a kind of a you know common uh common achievement of that siemens community that we together manage to pull this out and move into direction which is hopefully better and Kevin i think if we google uh some tutorials on the previous on the current uh management memory manager and how to deal with it i think your name uh will be the most popular one and as a person who spent let's say a lot of time to to create all this content uh how do you feel about this change so it's definitely an interesting question i i got started using Kotlin native uh early i think as we just touched on um probably i guess 2017 it was the first attempt to use it so um it was hard to learn i went through i tell people there's stages of grief that you go through when you have the new memory the old memory model the strict memory model and you try to get around it and you try to fight it and then you start to learn it and then i got to to the very late stages of it actually affected how i architect things i think for the better and i um my goal was really to if there was ever going to be adoption of the technology people needed to understand the memory model and that's really why i got um went deep on trying to explain it and i honestly think if you if you go through the content and you spend a few years wrestling with it like you know you really won't mind it at all but we don't have yours right so like um i feel like it's the right move for sure to change the memory model um i remember at Kotlin comp 2019 where there were a lot of discussions with various team members and it seemed obvious that that decision was likely going to be made and my big concern really was just it's going to take a lot of time to re-implement it and it's going to take a lot of time to get it right and um you know it was always around concern of of the you know people getting adoption gaining adoption and things working out so i was worried about that but it was the right decision and and now it is all about um for me working with various people in the library community to make sure that things are ready um we're you know with our clients we're essentially you know using a new memory model and this is a really really good reason for them not to uh mostly because if you're working on something now it's not going to be released for a few months anyway so um yeah i think i think it's good i i i think people i want some people especially the community thought that i was uh loved the memory model and that's why i talked about it so much and i wouldn't say i loved it or hated it but it was definitely just if adoption is going to happen people need to understand it and now they don't so let's all pretend like it didn't happen and and then we'll move on what will be the next Kevin's topic now now you don't have this memory model uh i don't know that i mean there is a bit of like i'm not gonna lie there's part of my identity that was attached to explaining the memory model yeah that's why i'm asking i'm watching i don't know i'm like trying to figure that out i i have found over time though that um in tech you often will go down a path that ultimately does not work out and if you're doing weird or new stuff and uh you just have to learn to say all right i've made a decision that this is over and that's it i can just move on once you made the decision it's not so bad so i think now it is definitely um it's really more around architectural uh pattern decisions as we get into declarative view view things especially because the whole android community is talking about compose and how you architect things just for android well how does it translate when you're gonna do probably swift ui on the ios maybe maybe not how do you get co-routines up into the ios layer things like that but yeah we'll see the memory model was something that i could kind of own now i can't own any particular thing so i have to move on but i will i think biggest changes they always imply biggest challenges and we've already started to discuss it with a memory manager story but also speaking about challenges i want to mention and discuss one interesting feature hierarchical project structure i find it interesting because uh from the point of view of a regular mobile developer its value well it's it's pretty basic you can just use this magic ios shortcut in your build gradle file and now ide can help you to use platform apis ios apis for example foundation library and it will highlight your code to help with after completion and all the regular stuff we usually expect from the ide but as a part of the team i know this is just of the tip of an iceberg so Dima i think you have a lot to say on this topic oh yeah sure but i i will try to keep it short because we don't have three hours right so uh but yeah so that that is really an interesting case of a feature which as you mentioned doesn't look like a you know big change but it's interesting how it stems from the philosophical design choices we've made in the Kotlin mountain platform and like one of those design choices is that your code supposed to be analyzed once uh on the platform you're currently on and you're supposed to see like most of perfectly all errors and warnings you would get if you run or compile this code on other hosts so know this stuff like you have written your code against posix and it works perfectly fine on your linux machine but then you move your code to windows and everything fails because the posix is different on windows we really want you to get away from that and well it took much more because it costed much more than what we would have anticipated so basically in the process of supporting this feature we had to write a pretty unique piece of software which is able to look at the native libraries for each host like for example in the example i used before on posix for windows and posix for linux and find the api which is present on both platforms like which is safe to use in your shared code so this is pretty cool because then we can say that yeah like be careful this file don't use this function in your shared code because it will be absent on another host you compiled to but yeah it was not easy and this is really interesting because like it it shows that the it's also like the uh it answers that kind of the question you asked before like what is the difference between multi-platform and the mobile multi platform because this feature is mostly not requested by the mobile users because for them the ios libraries there they have very similar api and if something isn't present on i don't know simulator for example well you just know that you know you know that you are not supposed to use this or you get a crash when you run your application but when you get into different cases like with the desktop platforms oh yeah and posix then you need this stuff and yeah so that that is the difference and that is some feature which mostly boils down to multi-platform not exactly mobile albeit mobile users probably will be happy as well we don't need all these hacks anymore in this gradle file sorry sorry this is my my pain in retrospect do you think it would have been easier just to rewrite postx i i don't know but i this you you know there's the degree of despair we went because this is a actual question for us like in retrospective i'm not sure what would have been easier but at least like we are prepared for everything now like it's not just one posix we have to rewrite and then it comes with another library and another library and another and we have rewrite them over and over now we have a technology which does it for us automatically so yeah column multiplatform is a super ambitious project and that's even putting it lightly i think in demon you've you've been challenged a lot to make sure that these things are working on different platforms and listening to the audience and understanding like where do they need you to be doing that work to make life better for them um we uh at Touchlab and like Kevin said this is not a uh an advertisement we're not gonna put a book up here by the the the touch lab way of calling multi-platform um but we do talk to a lot of clients and they're putting it into production um and they have their own things to deal with while putting it into production um so Kevin what are some interesting cases and what are we what's occupying your mind lately um to to make sure that this is this technology is adoptable at scale so you know we spend i would say the bulk of our time now uh some of it's on greenfield apps for smaller teams and that's interesting i actually expected a little less of that than we're seeing but it's good um but i would say the bulk of our time is we're working with teams that are essentially either trying to figure out how to scale their mobile development with the shared code modules or which ultimately results in kind of having an sdk team but it's less official or to the extreme we have clients that are quite literally saying that we have this internal sdk team that publishes sdks to other parts of our org privately you know how do we how do we deal with that and and for us um a lot of this comes down to a few a few smaller situations essentially uh teams at that scale they have ios engineers who don't necessarily want to even know that they're talking to Kotlin or dealing with any of that stuff and it's figuring out how to get those automated framework construction builds the umbrella frameworks you know built and published into some form of internal repo that they can just download and we're um going through that expanding on that and trying to find the best patterns for those kind of situations and taking them further so you know okay you didn't compile this in your local machine or the libraries that are that it's talking to but you can you know debug them if you need to and then if you want to actually edit the code it's it's you don't have to do anything crazy you can just flip the switch and essentially point at a local build and do stuff like that so it's figuring out those problems uh for teams at scale and we're getting a little in the weeds on sort of relatively complex ci configurations so so you know you never have this moment where your your fresh clone is broken that kind of stuff but that's that's a much deeper topic but yeah that's what my whole day is kind of that and it gets subtle but there's there's sdk design issues like you you really want to let your android side have full access to the co-routine's endpoints and you want to let android manage the lifecycle of code routines but on ios you can't and and the other thing we're doing a lot more than i expected is actually Kotlin js multiple clients out of nowhere wanted to also publish a js version their sdk so how you design your modules and how you design the public api surface it gets an interesting specialty you spent a lot of time thinking about it and you could do interesting stuff but it's it's not always obvious the issues you're going to run into and that's kind of what we're figuring out so summary we're doing a lot of sdk work that's it well thanks edema and thanks Kevin for being here for the audience i'm sure you've already liked and subscribed as soon as you saw who our guests were um but we do need your feedback um discussions on what topics you'd like to hear uh who else we should invite please leave comments um so we can make the best show that we can for you uh cats i think you have one last thing to to do with us yeah yeah sure um i think before we go we need to have some fun and i believe that it would be great to finish each of our episodes with you know with an advice from our guests because we have this ability we invited an expert so advices are great everyone loves advices but i promised it would be fun so Kevin Dima i have one pretty basic and simple question for you if i if i start developing mobile application in 2022 how should i decide which technologies to use and why i say fun because i need wrong answers only i i definitely think i've been seeing people talking about using Kotlin for shared code and then putting flutter on top of that as your ui and i think that that's you should only do that and don't learn anything else and don't read any of the of the documentation while you do it that's definitely how you should get started and what would that be named uh that would be called clutter there is a library called clutter but i did say that three years ago and when i say i i mean i took someone else's name and said it but i gave them credit anyway yeah yeah and yeah my answer would be ask credit that's a much better answer but anyway sorry flutter people i think i actually said flutter flans earlier let me think back on it uh flutter's great you should all definitely check out flutter yeah so yeah like if we apologize for jokes like so here i just myself honestly that was amazing the best part of the interview sorry folks and see you in the next episode
2022-02-14 03:10
