Kotlin Multiplatform Mobile: Where to Start?

like Eric said I'm planning to run through some of the things that we a touch lab look at when we're trying to help a client decide where to start evaluating can be or co-chairing in general you know that's one of the things we do when we come in and and it's one of our part of one of our services of their factory is finding areas of the code that will deliver a high value to our clients to bring in as the first thing that they share code on if you remember from Justin's talk yesterday he told us about how console multi-platform doesn't require big decisions and so that's why we've decided you know as touch time to to go that route and also in this talk when I'm framing you know how you want to start evaluating co-chairing we're doing it with that framing with that point of view that you're using something like on the multi platform where you can start small you can have a very clean interrupt story that lets you really you know pick and choose where the most valuable place for you to start sharing is so going forward we can kind of assume I'm talking about sharing with common multi platform and but you know we can also apply these things to other code sharing ideas I know that looking at the registrations a lot of people are in the early evaluation phase either haven't started sharing or are looking for a small way to prove out that co-chairing can be beneficial so this talk should help illuminate some of the key areas where you can evaluate your code for value for ease of sharing and for impact and so essentially I'm going to lay out a few few variables namely the amount of business logic in a part of your codebase that might be shared how important it is to require alignment how active development in that area the code is how it's currently architectured and most importantly what your current team structure and dynamic is so starting there really right off the bat it's important to get or to enlist some advocates from your iOS team as well as your Android team to make sure that you can get a full understanding of what is important so it looks like your highness Oliver's what our pain points what's important how is the code structured on the iOS side and help you identify where iOS developers will see the most benefit and getting buy-in from obviously with something like how multi-platform getting buy-in from your iOS developers right off the bat is important and having an advocate as part of the initiative that can tell you hey this this part of the code is super important to develop Rea we should probably not touch that for now but everybody hates this core data module let's let's start working here having that kind of input rather than it being some sort of top-down or outside force acting on the iOS team will be really valuable in finding the best place to start but moving from there you know after you've got an input from everybody who who you can really looking for areas of the code that have a significant amount of business logic it is it's very possible to share a feature that is nothing but a network response getting piped into the the UI you know we we've done that but it's not where the most value is there is a cost associated with setting up co-chairing with setting up kind of multi-platform and to really see the value from it you do want something that has some sort of significant processing some sort of significant business logic so these might be things like some processing of user input before it gets sent out some server it might be managing critical state through an onboarding out-of-the-box experience it might be managing data flow of those Network responses through your through some further persistence into some sort of offline mode handling caching that kind of thing can take what otherwise might be you know a really thin a really small shared layer and expanded into something that's that's meaningful so certainly look for something that has a bit of that local processing a bit of that business logic important areas that might that might include or areas that work like strictly require alignment between the two platforms there are some things that if it's not perfectly aligned between the platforms it's just not going to function so these are normally some sort of communication object so it could be a network response it could be a analytics event some others see your lights type that needs to go over the wire these are things that if it's not aligned between the platforms something's going to break and a lot of times we look at these and they seem overly simple as things to share it that's seen you know wrapping analytics events or names or you know it seems literally a little over simple but having an area with that delivers that much value and is simple to build out a proof of concept on I think seems like a no-brainer a lot of the time other things like you know if you've knocked out the those high value areas or you don't want to start there is to look at the parts of your code that are going to have active development how active development is in a particular part of your code and the reason I call this out is if there's a piece of code that no one's ever going to touch again you know developer B wrote that processor five years ago and it's well tested and well understood and nobody who you know wants to touch it and it's not causing any problems it might not make sense to rock the boat for that particular piece because having it written once if no one's ever going to go work on it again doesn't deliver a whole lot of value that said there is something to be said for testing this out in a well tested well understood part of the code and isolated part of the code so it's a little bit of you you have to evaluate this to yourself but making sure that you keep it in mind sort of a related note on that is thinking about what people are going to be developing next what people are going to be working on next so if we know that a particular module is is in the works is coming soon that can sometimes be a good opportunity to say this is where we'll start writing things once instead of twice so thing about what parts of the code are active in the parts of the code are going to be active can really help you find value in co-chairing and the last thing I wanted to hit on is the existing architecture of your app so as you're looking to do co-chairing you're inherently going to have to be pulling concerns out away from your app a lot of you are probably already modernizing and separating concerns and building out a clean architecture and finding those areas that are separated can can make for some easy wins when talking about starting co-chairing so if you have a feature that is already fully pulled out that can be a good option there is the train of thought of let's pick the part of the code that's as messy as possible and take this as opportunity to make it better but we've found that at least starting out you don't want to necessarily make your life allow order so looking for looking for or building out those parts of the code that are well modularized and in good separation of concerns can make your life a lot easier for and share code and we've talked about this concept that at least what kind of multi platform well architected code is already shareable you know most of the work of separating things out of isolating your business logic it's stuff that we've already wanted to do for good testable code anyway and so continuing down that train of thought when you're looking at where is the best place to start can't be good so those were sort of the bullet points the the talking points that I wanted to introduce to start the conversation none of those variables are silver bullets or black and you know things that are going to point you directly to the right piece of code but they're all variables that it makes sense to look at when you're trying to make this this decision so hopefully that's helpful to everybody and at this point I think we'll we'll bring Russell who's our CT mobile developer and and Kevin is our founder / KMP guru / speaker and and we'll field some of your questions let me pull up no so um sorry I was myself um the first question that we have and I think Emma's gonna go ahead and take on take it on is um the question is from dory and he asks what is the bugging and cross-platform codling codebase look like compared to Collin running in a managed environment ie Android runtime and then he provides some further clarification how much harder is it to map back native stack traces to the cotton SRC I guess this is more of a Collin native question as opposed to a multi platform question I'm sister Kevin you want to share your thoughts on that let me make sure thanks I was back chillin at slack feverishly like I can't unmute myself hi everybody alright so so the question is debug and stack traces and all that kind of stuff so there's kind of a couple questions here there's this quite literally debugging and we made an Xcode plugin for Kotlin that you can use to directly debug code in Xcode and partially you know we're expecting there's going to be at some point they're not too distant future Jeff rains is releasing that Studio plugin that will let you run iOS apps from android studio and debug your patent code directly in there but a lot of our work is about how to not completely alienate the iOS team right so telling people to install entirely different tools that they're not used to things like that is that mislaid great for that so we didn't launch the Xcode plugin for Colin and you can add your Kotlin code that's from shared and you can debug with some caveats one executed Apple doesn't exactly make this a pleasant process so installing it is some command line stuff - you have to we're currently fighting through some technical issues where if you use the cocoa pods plugin that comes from Kotlin directly it makes a static we're trying to figure out how you can get decent back in there we also fork the cocoa pods plugin and you can use a dynamic library that's primarily why we forked and then debug yada yada yada but that totally works and you should be able to debug dynamically in Xcode getting stack traces back symbolic ation back we also put out something to piggyback on the work that the native team did to expose essentially symbolic ation and and stack traces so it's called crash tiles because we didn't come up with a weird branding name it just was quite literally crash for now in iOS and you can have these go to either crashlytics or bug snag and they should give you some bala cated crash reports if you set it up such that the d sims make their way to the server and i think you kind of have to disable some of the optimizations in the compiler which we're also doing more testing on that because if you do compiling with optimizations it'll in my a lot of stuff that might that might know something stack traces i but that does work it's an ongoing place of research though in our our well if that answers great thanks another question that we have is anything boss is going to take this where we're talking about Android and iOS what about web apps yeah it looks like there was another question that just came in around web stuff as well um so like um web the web is a common platform target you you can target JavaScript and build your browser UI from that and share stuff here so that way as well um we a touch Club are primarily focused on mobile so like that's what you'll find in things like our I can't get a template but yeah web web is there it address it in it um I tend to think that um mobile Gizzi um is a better place to leverage some of the coach bearing like your um your architecture between Android and iOS is typically going to be more similar than your a picture between Android and browser so you'll like starting starting with mobile clients you'll be able to probably leverage um leverage the ability to share code a little better um but Avera trading in doing it with with well as well I'm you certainly can i I mean we touch lab to give historical context I mean we've been a native mobile shop and frankly we're the only shop going back for years right so like clearly our focus is heavily towards native oh right that said you know assuming we have growth in this business like the web decided this is very much it's very good pool we want to do in the future but I also your Russell like it's kind of like you imagine a diagram where you have like more pure logic especially if it's complicated pure logic like if you're doing tax calculations or some crazy stuff that you want to have across all of your things you want to do it locally that totally makes sense technically you can do sequels away in Jay s in memory compilation of sequel light that runs a jl i get you know the i don't know how many people are actually doing that I find it academically interesting but it may not be you know there are like less obvious places where you can share laughing so touch lab admin when we gonna do the next question there yes I think this is actually a great question to kind of end on I mean it's from Samuel so something for asking it he asked wanted to set up a proof of concept of shared ios/android for my team I'd work any tips for setting up so we're actually gonna cover proof of concepts tomorrow but but Kevin jumpin little something yeah so camp kid exists we talked to a number of people who essentially your organization will usually say hey if you want to take a look at that there's a bit of time to go make that happen and often that turns into a half week right and the horror stories we heard were like Android developers getting a hack week and they tried to integrate shared code into their production iOS apps to prove that it works right so don't read the can't get stuff that is a risky especially if you don't recruit somebody from the Iowa side because integrating anything into any production build system is a very difficult process and if you don't have a lot of experience with the build system on the iOS side you just you're gonna you're not gonna have that working for probably a couple of days now what's the experience we had so it turns into something that doesn't turn to a big success so camp can exists to try to get as many of those risks out of the way as possible and please go into the Colin slack and ask for help if you get stuck and definitely this is we're recruiting someone in the iOS side is at least curious about this concept to help that integration if you're gonna try to integrate into your production that that's my big caveat like understand that imagine someone from the iOS team deciding they're gonna come in and change your Gradle scripts in your production app it's gonna take more than a week to figure out how to do that so that is the risk but I guess we'll talk more about that yeah and and thank you to someone actually shared the link to camp kit so if you want to take a look at your chat you can actually see a repo on github for cam kit and that exactly provides all the resources that Kevin just just walked through all right we're gonna go a little bit over we have one final question from Curt Sam you want to give your thoughts on it sure so Kurt asked about managing changes that that span both platforms and not breaking iOS when you make a change only the KNP side we've certainly run into this this complication and figuring out how to manage it has really primarily come down more to managing the project and and the developers and getting people on board with being multi-platform developers and essentially saying that any story is going to be handled on both sides of the of the platform of the share code and that that you know a developer should be comfortable working both sides of that and getting help as needed on whichever platform they're they're less comfortable with that said we've also experimented with the idea of a stable quota you know Co a stable version of library that iOS Delawares can develop against so that as you add things to the KNP a shared part the iowa's developers aren't using that out of the bat or out of the gate there's a lot of pros and cons to that it it makes it more difficult for the iOS developer to make changes to debug to get things sorted out as they're working on their tasks but it does provide some buffer in there if you can't group the story into one full multi platform task what one other like small note I might add on that is um maybe amount amount of helpful if you are in that kind of motivated team kind of setup is to like think about you're on shared code the same way you might think about your API like your remote API like it's always possible if kind of building your website at the same time as your mobile side that you might have breaking changes and in some sense keeping things in sync is similar I would I would throw in like I I try to have a keeper for like and we'll say I'm saying is more thinking of nothing like mobile developers as opposed to Android or iOS developers because the same mental exercises like what would you do if you had a whole bunch of modules and people were consuming Swift modules but couldn't edit them the if you structured your your team that way in your modules that way then that becomes a bottleneck and I think people would say oh well this the iOS developers can edit all this well could they also edit the shared column to write like that's you know what I mean like if you're gonna treat the SD a module as something that's consumed by another team they can't change it there are structural things you have to deal with and accept and whether that's Palin or whether that's just one team that does Swift can't edit an upstream Swift module it's like the same logical problem and there are physical differences of course but how would you solve that in that case again or they can remote server based thing like it is there are they're not unsolvable problems but there are similar problems you run into as a team gets larger in any context

Channel: Touchlab

Views: 301

Rating: 5 out of 5

Keywords: android, development, design, mobile, web, kotlin, ios, mobile development, mobile engineering, software engineering

Id: yAVSM72klx0

Length: 22min 56sec (1376 seconds)

Published: Mon Apr 13 2020