Ep 134 Kotlin Multiplatform Mobile with Mohit Sharma

Mohit Sharma: Hello, everyone. Welcome to MongoDB Podcast. I'm Mohit Sharma. Thank you for having me here. Today I'll be sharing my thoughts around mobile development, specifically around Kotlin Multi- platform.

Shane McAllister: This is the MongiDB Podcast. My name is Shane McAllister and welcome to the show. We're grateful to have you join us for another episode. In this episode we turn our attention to mobile development and I talk to Mohit Sharma, a fellow developer advocate here at MongoDB. It's easy to forget, given how prevalent mobile devices are nowadays, that the smartphone and more particularly developing applications for smartphones is a relatively new endeavor and profession. With Apple opening the app store up to public apps in 2008 and the Google Play Store not hitting the scene as a relatively late comer until 2012, we're talking about an industry that just 15 years ago did not exist at all. I chat with Mohit about mobile development, how he got started in mobile development, his current role as a mobile developer advocate at MongoDB, and we focus on KMM. What is KMM? KMM stands for Kotlin Multi- Platform Mobile, and we focus on what that means for mobile and indeed desktop and web development, and the benefits that KMM brings to your development process. Let's get started. Welcome to the MongoDB Podcasts. We're always glad to have you join us back here to listen. I'm Shane McAllister and I'm on the developer advocacy team here at MongoDB. This episode we are interviewing one of our own, not just one of our own in terms of a MongoDB employee, but also another member and a colleague on the developer advocacy team. So I'm delighted to be joined today by Mohit Sharma and Mohit, why don't you introduce yourself and tell us what you do here at MongoDB.

Mohit Sharma: Thank you Shane, for inviting me. I'm really happy to join in your podcast. I'm a regular listener. I really like the way things are presented here. Thank you for keeping this up and once again, I'm happy to be here. A little introduction about myself. I'm Mohit, I've been a developer from past 10 years. I have joined MongoDB recently, two years back. I'm part of dev roll. That's all from my side.

Shane McAllister: Good. Obviously we've worked together for a long time. When you joined, we were working together on a team. It's been superb experience working with you, but let me go back a little bit further. How did you originally get started in your mobile career? Now we're going to spend this episode talking about KMM or Kotlin Mobile, but I want to delve back a little bit into your background because we know that we've got a varied listenership of this podcast and we've got a lot of students. We do a lot in the education space and the university space. So tell us how you got started in your mobile career. Where have you been before? How did you learn how to develop for mobile in the first place?

Mohit Sharma: To be very frank, I don't have much of a interesting story of how I got started with the mobile development. Primarily, because as soon as I got my first job after college, they put me in a random project and it happens to be an Android project. At that point of time, it was year 2010 where in Android was just starting to getting picked up. I started with Android 1.4 or 1. 5. I'm pretty great grateful that I was there at that point of time. Since then I really started enjoying the framework because it was new, things were moving in at a very great pace. So I switched along different companies to learn along the way. But in general, if I have to give a suggestion to any of the newcomers who wanted to do mobile development, my first hit for them is to go try to create a app for yourself. Trying to understand whether do you really love building mobile apps or not? Because while using an app is very different and while building it yourself is very different, so try to figure out by building a very small app by yourself, whether you like it or not. It doesn't matter which technology you use, but try to build something on your own so that you get a feeler, " Okay. Yeah, I like it." Or, " I don't like it."

Shane McAllister: Yeah, I think that's the best way to go. I know you need to experiment. In my world in mobile development, it was mostly around in the iOS space, in the iPhone space because that's where I started. It predated Android by a couple of years. It predated the Google Play store by a couple of years as well too. So originally, obviously in your development for Android, that was not Kotlin, it was pure Java, right?

Mohit Sharma: Yeah, it was Java. I think so we started on the same years, because you were also mentioning me about inaudible the project on which I was put in was in inaudible. I wanted to port it to Blackberry and Android because it was a new upcoming project. Yeah, almost the same timelines. And yes, it was probably Java and we used to use Eclipse at that point of time. It was not even Android Studio. So things were pretty funny and different at that point of time.

Shane McAllister: It's amazing actually to look back and see how far things have come in essentially 15, 16 years of what we now recognize as mobile development. It was incredibly fragmented before that. Some people will still say it's fragmented as well too, and we'll get into that. But the world of mobile prior to essentially it being a two horse race between iOS and Android was incredibly fragmented. When I hear people these days talk about how fragmented the development systems are and platforms are, I go, nothing. It was in incredible and very tough. Right? There was very little standards as well too, and it was a ton of experimentation, at least from my experience. So you got started in your mobile career almost by accident, but it obviously led you to where you are now. You said you came to MongoDB just about two years ago and you joined our developer relations team on the advocacy side. How has that journey been for you, Mohit?

Mohit Sharma: So far to any of the listeners, I would say being in MongoDB is one of the best decisions I've ever taken. I'm not saying just because I'm currently an employee of MongoDB, it's just from my own experience as well. The people here, they are very talented and equally very kind and understanding. Same goes for the leaders as well. It is a very different feeling. Although MongoDB is a big organization from a outer perspective, from the outer world, but within itself, I really feel that I'm still part of in a startup, which is moving very quickly, changing very rapidly and equally giving you time and opportunity to grow along with it. I really love that experience and that feeling because still now I have been always moved along the small organizations or bigger organization, but they were slow. But this one is very unique and I'm really liking my experience here.

Shane McAllister: Great. Obviously, there is a change from being a day- to- day developer to becoming a developer advocate where you're trying to, I suppose the whole role of the job, in my view anyway, is to be the kind of go between. Engineering teams and essentially our users and vice versa. So be that feedback loop. How have you found that change from not developing on a day- to- day basis, but actually thinking more about creating demos, creating content, and getting out there amongst the mobile community?

Mohit Sharma: Actually you have touched one of my pain points to be very frank. I really miss sometimes coding, but I've also realized with this job is that you can still code on a day- to- day basis. Nobody has stopped you because at the end of the day, what I feel as a responsibly being a developer advocate for MongoDB is that you have to be on the edge of your technology stack. Right? Earlier you were building all the time for your organization to come up with the releases. Now here you have to every time code yourself be on the top of the technology just to be aware what changes are happening within the platform, right?

Shane McAllister: Sure.

Mohit Sharma: At the starting when I joined in, I really felt that I have taken a wrong decision, but then as I stepped into the right shoes and with your mentorship and everything, I realized that's not the case. I'm still coding on a day- to- day basis and I really enjoy doing that. Definitely this has changed my perception. And another thing which I would like to add on this is that being a developer advocate gives you an added benefit. Because, you are able to learn all the bleeding edge technologies and you can interact with people trying to understand their problem. Being a developer, if you want to be very well- versed with the technology and you want to feel like you know most of the stuff, then this is the right role for you, because you will get to learn a lot with this profile and this role.

Shane McAllister: Yeah. I mean look, yes, it totally, it's entirely, I think, you're at two sides of a coin really with regard to this. Because you're getting early access to what our engineering teams, our incredible engineering teams are building, and you're putting on your, I suppose, users' hat and saying, " Well, how will I work with this? Does this solve the problems that I want to solve? Does it make my day- to- day job easier as a developer?" I think from an advocacy perspective, that's crucial. As you say Mohit, you still get chance to learn new things and obviously sometimes very early access in new things. It can be frustrating at times when things don't work the way you want it to work, but maybe, and we do a lot of alphas and a lot of betas and we might have six months between both and we get to play with that while we're doing that, I suppose as well too. Correct?

Mohit Sharma: Yeah. But Shane, to be very frank, I don't get frustrated with a lot of alphas and betas because ever since I've been developing mobile apps, I was always on the alphas or betas, whether it's the Android APIs or Android Studio or whatever. Because you want to be on the edge of your technology, so you'll have to adopt early and sacrifice a little bit on your performance. I've been always frustrated with, this is not working on my under studio, but people will say, " That's your problem because you are there on Alpha." But then I have to say, " Okay, yeah, that's my problem, but I know how to work more efficiently for the upcoming releases. So I kind of not agree that I have this thing, but that's how I enjoy it.

Shane McAllister: So you're not frustrated, you're used to trying to be at the bleeding edge of development, really. Not even the cutting edge and just working around that, trying to find the workarounds or the fixes or getting that feedback back to the engineering teams, which is the really nice part about this role. The feedback loop is really short and we get to work closely with the engineering teams and then also conversely with our docs teams as well. Then everything else in between. You speak about working with new technologies, which brings us basically onto the subject of today's chat, what we're trying to talk about here on the podcast, which is Kotlin Multi- platform Mobile. We've both been around long enough to know that essentially, and for those who aren't necessarily mobile developers in the audience, historically building mobile apps falls into two categories. You're building either a cross platform app or you're building a native app. We have had, over the years, I know I've had a lot of experience of them, is solutions in the cross platform world. A solution in the cross platform world is essentially saying you can build once and deploy anywhere, or you can do this with a single team, with a single code base and still deploy out to whatever devices you want. We've seen lots of them Flutter, React Native, Xamarin et cetera over the years. I suppose in my view, and you correct me if I'm wrong, Mohit, but in my view, the cross platform approach is really crucial when potentially time and cost is really important to high priority and maybe less so the user experience. Then when you're building natively, it's flipped.

Mohit Sharma: Yeah.

Shane McAllister: I think that's kind of the right approach. Okay?

Mohit Sharma: You're right on that. I've also experienced a lot of things. And being a native developer, I have always this thing whether I should lean onto the other frameworks of hybrid or not. But I've never been good at the decision whether to go with hybrid or native. Just because I've been a native developer most of my career and my preference has been always towards the native. Few times I have leaned upon the hybrid, as you mentioned, when you have to make choices between money and time. But most of the time I have always leaned upon the native site. That is one of the very prime reasons why I was very much interested with Kotlin Mutli- platform. Because I don't have to take that conscious decision that if I use a hybrid, if I get stuck somewhere within the plugin framework or if there is a performance issue, what will I do? With Kotlin Multi- platform, I still get that privilege. I'm still writing everything natively, right? So I don't have to bother whether, " Okay. My platform API is not supported." Because I know that feature is supported by the platform API. That's why I'm building it up for that.

Shane McAllister: Okay. That is an interesting difference. Definitely. I suppose I'd like to dig into that, the fact that, I suppose KMM is standing, I suppose on the shoulder of... Basically, it's native under the core. Right? Talk a little bit to me about the architecture of that. How does it handle logic? How do... If I'm a developer and I want to go at building the KMM app, we've seen this before where the cross platforms and the hybrid apps over- promise and under- deliver. So, I don't. As you said yourself, you don't want to invest in a platform that you might potentially hit a roadblock in. We know for example, that many of the hybrid approaches would always lag native functionality. We wait obviously for Apple and Google to release new frameworks and new codex and things that we follow. If you're a native developer, you can get instant access to those and use those. But, if you're using a third party cross platform, a hybrid approach, they lag a little bit. Correct?

Mohit Sharma: Yeah. Shane, I would like to correct you a little bit. I wouldn't call KMM as a hybrid. Okay? Because as per my view, it's not hybrid anymore. Because why we used to call hybrid? Because you're writing a code in one technology and then the compilers were building it out, giving up ERR files or IPAs. On the technology, which could be understand by that operating system. But with Kotlin Multi- platform, that has changed a lot. I give you a little brief how that has changed in my opinion.

Shane McAllister: Sure.

Mohit Sharma: What Kotlin Multi- platform says or what notion they're trying to bring in, they have noticed that from ever since the development of the mobile technologies, everyone was trying to reduce the cost and the time. Why? Because they feel that they're repeating themselves a lot on iOS you're writing the same application or an Android you're trying to write the same application.

Shane McAllister: Oh, totally. I mean you have entire... I've seen companies that been in companies, single teams, single code base and the holy grail was right once run anywhere. It depends on their nature and the structure of the company as to whether they were geared up to do that. But I think, yeah, I see where you're coming from, in terms of this is a fundamental change, which is why people are pushing very much towards KMM, to solve a lot of the historical problems that we had with cross- platform or hybrid approaches.

Mohit Sharma: Yeah. There are a lot of sayings, also like single source of truth, don't repeat yourself and all those stuff. Right? That enforces you in the same direction. As I was mentioning you earlier, what happens is with KMM, they think from this perspective that you write all your common code, which could be business logic, getting data from the network or doing some manipulation over the data, cleaning of the data, whatever thing you have to do with after your business logic or with business logic, that should be written in the KMM thing, which is actually written in Kotlin. Okay? So one added advantage for the Kotlin developers, so everything that is written in Kotlin and then that piece of logic or that thing is being exposed to the iOS and the Android developer, which they can move further and try to manipulate data over the top of it. What Kotlin Multi- platform is doing it is basically creating a library or exposing a library for you with all your business logic, written in Kotlin. Over the top of that, you can use that in Android and iOS to just display it on the UI. Still you are writing all your code in Jetpack Compose or SwiftUI or traditionally if you want to do your storyboards with Objective- C or XML and Android, you'll still get, and there'll be no performance hits or anything, right? Because you are still writing the UI that's more fundamental on building on UI, which takes most of the processing time.

Shane McAllister: Sure.

Mohit Sharma: You're still doing it in the native technologies and it's just the logic part that you have exposed to the Kotlin Multi- platform. That's why I was saying earlier, I don't see this as a hybrid approach. I see this more on a native approach. I have been clever enough to understand, " Okay, this is the part which I can expose as a library for both of the platforms." And to mind you, Kotlin Multi- platform for mobile. But it is basically Kotlin Multi- platform, so it allows you to extend your project for MacOS, Windows, desktop, whatever you want. Okay? You can use it anywhere. It's letting you spread your wings to other side of the world as well.

Shane McAllister: Okay. If I'm a company and I'm producing mobile apps, this sounds incredibly exciting. Essentially keeping all the business logic in one single place, which not only reduces development time, but obviously the maintenance and updates of those apps. We're all used to that update cycle. It's keeping all the business logic in one place, it's reducing my costs of development and increasing my flexibility. Do I have to go all in on KMM or can I incrementally start to use this in an existing app, pieces of an existing app to start to replace that business logic for example?

Mohit Sharma: Yes, definitely. You can go incrementally. There is no push that you have to start a very fresh project with that. It's very simple as well. For android developers is just create a KMM library and expose it to your android application. Likewise, with the export as well. Now, very with the recent update, export has also started providing natively support for Kotlin Multi- platform projects as well. So you don't have to bother there as well. Just add the corresponding dependencies and you are good to go.

Shane McAllister: Okay. If I have a mobile app and I want to go the KMM route, I can take an incremental approach to this. So it doesn't matter that I built my app on Compose or I'm using SwiftUI or anything like that. I can slowly start to introduce KMM elements into my development process.

Mohit Sharma: Yes, you can do that. Let's say for example, you decided that I want to add an offline functionality for your app and you happens to use realm for that which is a MongoDB product. You don't have to do anything. You just simply write the KMM layer for the Realm, which supports that thing and then you can just include that error file or lift file in the respective projects and then you are good to go so you don't have to bother how the things are getting saved. It will be saved at one location, exposed to both of the projects.

Shane McAllister: Okay. That was a super nice segue into realm. So obviously Realm is MongoDB product and as you said, we released our Kotlin SDK to general availability back at MongoDB World, which was in New York in June. That's been out for a number of months now. Tell our audience a little bit about that Kotlin SDK and it's a couple of years in the making. What does Realm give a mobile developer? And certainly in the context of KMM as well too.

Mohit Sharma: Realm has been an interesting product, especially around iOS technologies. Because if you ask any iOS developer, " Have you used Realm?" They'll probably say yes. But they might not have the new Realm. Because earlier Realm was primarily used as a local mobile database. But now when it collaborated with MongoDB, it is much more powerful just being a local database now. There are various other functions that allows you to take your data out of the box to the cloud as well. In general, it's a one place solution for adding an offline capability to any of the application, which reduces your overhead of playing around with the data, manipulating it, converting either into tables or JSON just to save it. Because, Realm is an object- oriented database. Basically you can just directly save your object into it. You don't have to bother, how should I convert it into a table or a JSON just to save it internally? Right? You don't have to think about that. It comes out of the box for you. The querying mechanism is really nice with the new SDK, which is built upon Kotlin Multi- platform, you can use all the Kotlin functionalities like co- routines, the programming syntax. So everything is very clean and neat as compared to what you were used to do with Java. Because at that point of time the best way of doing things was reactive way of doing. But still it has a certain level of call back help, but here with co- routines even that has reduced and cleared out the way for most of the developers. Definitely I would recommend you to hit out and try to build a small app wherein you'll see how easy and convenient it is to save your data with a mobile application.

Shane McAllister: Yeah. There's very little mobile apps and we tend, as we said at the beginning on the introductions, the app stores have been around for a number of years now and we're very used to highly performance stable apps, but it wasn't always the case. I certainly remember that back in the day, managing your local database and managing some way to sync that data that you had locally on your device back somewhere to the cloud was always difficult. That's really where Realm stepped in. I know we spoke about offline, but we do like to think of it as not offline anymore, as always online. In other words, you will never notice the fact that you're offline. Because offline still exists. Even though we living in the world of 4G and 5G and ubiquitous data connectivity, it still exists. There's black spots, you go into a subway, et cetera, you don't want to have that experience and we all know how frustrating that spinning wheel is. So we don't want to give that user experience back to any users of our app. Obviously we're all in on Realm here at MongoDB, but do check it out. It's very straightforward. If I was using Realm already and say before the Kotlin SDK came out, and was GA and I was using the Java SDK. Can I move? Can I change my app from using the Java SDK across to the Kotlin SDK? Can I migrate?

Mohit Sharma: Yes, definitely you can migrate that. We have built special provisioning to make the migration very less painful. As I mentioned to you earlier, that with Kotlin Multi- platform, you can go incrementally. Likewise, with Realm migration you can go incrementally as well. We are not forcing you to just stop all your development, migrate to the new SDK, because it's cooler, no. You can take a smaller step, move the applications, move the logic or the data one- by- one. Because at MongoDB we understand it's not easy to migrate data or change your application in a day or so. Right? You have taken a couple of months or years just to build that logic and we are asking you to migrate it overnight, no. We give you the flexibility to migrate it over the period of time so that you can use the both side of the world and once you are fully committed to it, you can slowly start deprecating or changing, getting rid of the older SDK.

Shane McAllister: Okay. Again, it's an incremental process for somebody to move to the newer versions of that SDK. Somebody might be along the lines of thinking of moving to KMM and every few, I don't know what the time period is, but generally, you need to migrate and update apps regularly. There is a natural cadence in the flow in the mobile space because there's new versions of operating systems. Around this time every year, the September October timeframe when developers at least have to dive back in to make sure that their current app is compatible with the new versions of the operating systems. I know from my experience that's when you would take care of a lot of maintenance as well too. The one thing about having Realm in your app and using the Kotlin SDK is it does very easily give you access to Atlas device sync and Atlas app services. It'll allow you very simply to get the data that's on your local device back onto Atlas, which is our hosted platform for database. Once there, you can do a lot more with that data. People sometimes, and I don't know your experience as well too, Mohit, is they think of, " Well I don't need sync and everything's on the device. I've inaudible an API and I've downloaded everything and I've passed it and I'm storing it locally." But many developers need to understand that people migrate between operating systems. I have an app and I've set up some settings and set up some preferences myself and I'm moving from iOS to Android. Well, I don't want to have to change that when I go and download the equivalent Android app on my new device there. So there's lots of different ways that you would need to have sync when it's not instantly apparent that you're collaborating or sharing on anything with a group. But there's lots of other ways to do that. Correct?

Mohit Sharma: Yeah. To be very frank, even let's take the discussion of whether your user is on the two devices or not. Even if you are very much sure that he'll not change his device, he'll be on that exact device every time, you will still have to write the code for downloading the data from the API. Then passing it along the way and then saving it into whether Realm or code data or room, whatever. You'll have to do that manipulation of the object, right? When you're getting all these functionality out of the box, why wouldn't you do that? Right? It's like somebody's telling you, " This is a trick." And you're saying, " No, I don't want to do the trick, I'll reinvent the wheel for myself again."

Shane McAllister: Yeah. I think the analogy of reinventing the wheel is really important. I think once you try to build this for yourself, what you get out of the box with our Realm SDKs, the custom networking, the serialization, conflict resolution, et cetera, these are hard problems. There's hundreds if not thousands of developers trying to solve these problems over the years and I always feel that if you're building an app, your time is much better put towards making that app experience as nice and as enjoyable as possible and not writing boilerplate code. There's some people who take a proprietary approach to things and want to create their own, but I know from prior experience too that time and time again they come back and it's all been too hard and it doesn't work. That's a lot of maintenance of something that essentially your users don't see happening in the background. We take this for granted. So really what you want to invest your time and money in building a mobile app is the user experience and everything that happens on that screen, on that user's device.

Mohit Sharma: Yeah. What I've seen with my working on products, this problem of giving the right experience to user every time, sometimes product owner, straightforward, shy away and they say, " No, we work only on online. We don't care about offline users." Because they know this is a very hard and a big problem to solve. But I think so, they have never experienced a platform like this which gives this functionality out of the box or else they would have simply said it, " Why don't you go and just use Realm?" Because it's coming out of the box, I'm getting additional set of users so why should I not do it? Don't try to think that I'm trying to boast what I'm working upon. It is what I've experienced actually. Definitely I would like to recommend anyone who is in the mobile world, just go and try and check it out, try and see it yourself whether it's actually helping you or not. Sometimes it might not. Then do reach out to us on Twitter or our forums and we'll be happy to help you out in that case. But my experience and my take is that you should definitely explore it.

Shane McAllister: Yeah. Look, I think in the context of KMM, what we're speaking about today, I think Realm serves the same. It reduces complexity, it reduces costs, it increases your flexibility. It falls into the same box as the advantages of KMM as well too. If I'm a developer and I'm around the edges of mobile and I'm trying to increase my knowledge, as you said earlier, your day- to- day job is a lot of new things and a lot of learning. Where do you go to learn Mohit and how do you keep a pace of what's going on in the mobile space?

Mohit Sharma: Basically my take on that is talk to people because no matter how many blogs you'll read, how many websites you serve or how many feeds you have on your mobile, you'll never have the right amount of time to update yourself with that because you have an actual job as well, right? Which you have to fulfill. So if you want to be updated, try to attend kind of meetups that are getting organized, try to listen to podcasts and all those stuff. Try to gain more knowledge passively, right? Rather than just going and reading blog. My take has been always like this, if you want to learn something, talk to people, attend conferences, meetups and everything because, there people will tend to share their experiences, they'll talk about, " Hey there's a new framework coming up. Have you tried that?" That has been always my secret thing of learning things because even in an organization I used to organize these small roll back sessions saying, " Okay, let's talk about it. You don't have anything prepared? It's fine. Have you read any blog? What have you read?" In this way I'll always tend to know 15 20% and I'll also get to know their own take on that. That serves me to purpose. I'm always aware what things are moving around in technology. Plus I also know what are the first challenges which people are facing around it and if that interests me I further go and dig down into it.

Shane McAllister: Okay. No, that's very interesting. I like that idea, that you can learn a lot from the community and participating in activities within the community. Because I think when you are online, you're stack overflow or on YouTube looking for information et cetera as well too. You are really only looking for the answer to a question that you have and once you've got your answer, you're back in your development environment, trying to fix the current error and move on. I think in my experience anyway, the more you interact with the community, be it in person or online, you get to have a shared experience really with them and you learn things that you might necessarily have an immediate need or a requirement for. But, you put them in your own personal backlog and understand that, " I can learn from this and use it forward as well too." Obviously I presume, you know, go to the usual places, you ask questions on Stack Overflow, you jump onto YouTube to watch some tutorials as well too. Is there anywhere else that you would recommend if... Actually, going back to an earlier question, if I was not a mobile developer today and I wanted to get started, going back to our very early start of this podcast, would you say native or would you say Kotlin Multi- platform? And you're going to contradict me now. Because, you're going to say Kotlin Multi- platform is native, right?

Mohit Sharma: Yeah. Kotlin Multi- platform. Because that's the choice. But if you happen to look around around Kotlin Multi- platform, you'll also know that it is currently on the alpha, it's not even beta. That might raise your ears a little bit. But let me tell you, at Realm we have invested in that, seeing the advantages of it. We took the risk as well, but we have seen the advantages and even a lot of companies have taken that risk to go along that lines. Because they understand the value and the benefits that are coming through. With my experiences. We have a couple of repositories on MongoDB developers, that's our GitHub handle wherein you'll find a application like pass keeper or expense manager where we have used Kotlin Multi- platform that can be an headstart for you, if you want a application to understand. With that applications, when I was building through, I realized that the platform, it is very much stable even though it's in the alpha phase. Yes, there are a few hiccups, but if you search for those hiccups on Google, you'll find it very quickly. The platform is very much active. Kotlin itself, has a dedicated channel within their Slack, okay? Which deals only with multi- platform. So you can go and subscribe there if you have a super urgent problem or you want to actually talk to people rather than just putting on Stack Overflow, waiting for a while. You can go there and people are helpful, there. You'll see the kind of responses that are flowing through. Each day you'll understand how active the community is all around Kotlin Multi- Platform.

Shane McAllister: Okay. When I search for Kotlin, I see JetBrains in the results. Tell me about the relationship between Kotlin and JetBrains if somebody doesn't know already.

Mohit Sharma: It is basically coming from the JetBrain. Originally Java used to be coming from some or long back, the same relations goes where Kotlin and JetBrains. They are supporting the language, they are the main developers of the language and building it along the way. That's how the JetBrains came into the picture.

Shane McAllister: I think that going back to what you said about learning and experimenting is key and crucial as well too. If you're a developer the best thing to do is go and read some tutorials or go to some meetups, et cetera. But then to start to play with code, what would be your go- to thing that you would build when you're trying to learn a new language or a new framework? What would you first try to build with something to know that I can take what I know maybe in another language and transpose it across and see is this more performant for me? Is this something that I prefer? Is this something I said? Is it a simple table view app, a list view that you might put together or what would you do?

Mohit Sharma: I'm a developer by heart, so basically I like to learn by writing more code. I'm never a kind of developer that wherein I'll first read the documentation and try to understand, " Okay, what are the benefits?" I'll go and research with few of the blogs and YouTube videos. That's not how I'm programmed myself. Normally my approach would be first go on the official documentation. In this case I go and check the Kotlin website and see okay, " How's Hello World app build along?" I just take that code base, I try to play a few bits and pieces, try and change from Hello World to Hello MongoDB or Hello Realm, whatever. Okay? Then once I'm done with that, then I start building my own small calculator app or an app which simply captures the user information and all those stuff. That's how I always try to learn any new technology or the platform. Definitely it has its own advantages and disadvantages. The biggest disadvantage could be, the no- go, I'll come to know after I've spent a large amount of time understanding that platform. But as a developer that's more convenient to me that I don't have to read and process information in English. I am very happy processing information via code that keeps me more attached to the ground, how to make the right informed decision for myself.

Shane McAllister: Sure. No, that that makes perfect sense. I think also as you said earlier, the advantages of KMM is that you can incrementally adopt it and get it into your app over time as well too and it'll still live alongside your shared technologies that you have elsewhere in your app. So you can put a toe in the water, right? If you have something that you have already, you can change a portion of that to use KMM and see how it works out.

Mohit Sharma: Yeah, definitely. Basically, even if your app is working for inaudible and there are architects and solution managers involved in it, they'll also go with this approach. They will like to just test the waters, how the things are moving ahead for them and then fully dive into it. If KMM and Realm is giving you that opportunity, why shouldn't you go ahead with that? Just try it. Whether it's working out for you or not. If it does then you can move ahead along that lines.

Shane McAllister: Excellent. I mean think certainly I'd be keen to see how it puts forward I suppose those possibilities. If I was building an app at the moment, I would be really considering using KMM, certainly starting from scratch. Because of all of those opportunities of the shared business logic, it's in one place, the right ones run anywhere. As we said and touched on briefly, it's not just mobile, this is web, this is desktop, everything else as well too. Correct?

Mohit Sharma: Yes, definitely. One more other point, you don't have to even think about whether I have to create a hybrid app or a native app. Because that's you're getting out of the box. Because business managers will always think about the costing as well. Right? Even if you're building from very scratch, you'll have to give them also that is in their favor. I'll definitely go into it. But the technology, I'll also say one thing that any technology is not built for all the solutionings Right? It's not like that came and will solve every problem for every developer. It might not solve for you as well. What I'm trying to say, it's not one go solution for all the problems you have in your life. Not in life. Basically, as a developer,

Shane McAllister: If it could fix all of those, we'd be very good.

Mohit Sharma: Yes, definitely. But it might solve most of your problems trying to understand whether I should take a decision of hybrid or native. How many people will I be required to maintain one app and all those stuff. Definitely, you should go and give a try at least try to understand. If you don't like it, you can easily get rid of it as well. You have win-win from both sides

Shane McAllister: Yeah. And there's a low barrier to entry, I suppose. I think I saw a statistic somewhere that I think it's about 70% of the apps in the Google Play Store today are Kotlin- based apps. Pretty much. So there's a huge cohort of people already riding in Kotlin who familiar in riding in Kotlin, who now by adopting KMM can actually deploy to the iOS app store and to web and desktop. I think it's a superb scenario to be in and it's come a long way from where we were at the beginning of mobile development and all of these, as I said, other frameworks and cross- platform hybrid technologies promising the earth, but they all failed to deliver I think. And everybody, I think certainly in the mobile space we do gravitate towards the shiny new thing. As developers we go, " Yeah, let's play with this, but let's play with this platform." Then they have, I don't know what the name of the graph is, but there's this graph of promise and then there's this valley of nothing, where you're not familiar with the platform or you're not familiar with the program and then you're self doubting, " Have I chosen the right technology or framework to do what I want to do?" But I think that probably is very much reduced in this respect because of that huge developer experience building in Kotlin who can now adopt KMM and all of a sudden they've got the rest of the operated systems and platforms open to them. I think yeah, it's superbly promising, right?

Mohit Sharma: Yeah, definitely. But Shane, I think so you are missing out the iOS developers with Swift coming into picture and most of the apps written now in Kotlin, if it compare the syntax of both Swift and Kotlin, it's almost the same.

Shane McAllister: Okay.

Mohit Sharma: Don't neglect the iOS developer or don't think it'll be a barrier for iOS developers as well. It's very convenient for them. Definitely, you are changing one programming language. There will be some pieces here and there. Say for example, co- routines, it's not available in Swift as per my knowledge. There will be few bits and pieces here and there, but they will be very easily able to read code and write code. So it's a low entry barrier for iOS developer as well, which is a very added advantage because you are trying to solve problem for both of the platforms. So now there is one language which both developers understand. Earlier, it was not like that. Java was very different, Objective- C was very different. But with Swift and Kotlin, I think so they have aligned pretty much the same.

Shane McAllister: Perfect. No and I appreciate you bringing me up on that because as you say, the syntax is very similar and I think that's probably the greatest barrier to any developer adopting something new is, " This looks strange to me, this is very different. I don't understand the structure here." We always have these conversations about different style brackets, et cetera.

Mohit Sharma: Yeah.

Shane McAllister: So the fact that the syntax is very similar to an iOS developer I think, that should bring, and I'm right in saying, I mean, these two worlds, you need it as a mobile company perhaps or a company with a mobile app to produce these apps for these two different OSs and per examples, you had maybe different teams doing that. To bring these worlds together and to make it simple is only going to improve the experience of that app as a whole. KMM allows it to still, as you say, it's still going to be native looking, all the UI is going to be native, everything is going to be the same. We've seen some cross platform apps in the past produce a UI that doesn't look neither this nor that it's not native and it's very scary, right? Yes. But, the UI and the UX is going to be fully native for anyone, using KMM.

Mohit Sharma: Yeah, that's one of my punchline in KMM talks. Earlier, with this hybrid platforms designer was also trying to be creative. They'll put a backup button on one of the platforms and they say, " Oh, isn't it eligible? I can do that, right?" But then you'll tell, " No, the user is not used to it, so he doesn't know what to do with that." Or they'll just mess up the back arrow all together. Android, they'll put iOS and iOS, they'll put Android. So now, these all problems are gone. Because it's purely native, and look how performance is getting impacted with the hybrid platform because you're trying to access the underlying platforms. You're trying to build UI in a third language. Now, you don't have to do that, right? It's very simple. Since you touched upon this point, I would like to tell you one more thing. Let's say for example, you want to access user location. Even more simpler, you would just want to get a random string. Okay. Both the technologies have a different way of doing it. Android, it would be from the Java SDK or from the Kotlin SDK and iOS, it would be from the UI kit or from somewhere else. Still you can use the same thing in the shared code base. Still you have certain provisioning that you can use certain underlying platform APIs just to write the business logic. Somebody might misuse it to build a UI there as well, but I think so, they won't do it because they'll understand why they're doing it. So I'll say that still you have the flexibility of writing your shared business logic with the platform APIs as well. Over the top of that, try to build your UI natively, which is very convenient for any mobile developer, I think so.

Shane McAllister: Yeah, no, totally. I mean, I think if we take anything from our conversation today, it's the fact that this seems to... It doesn't have any of the pitfalls that would've been associated with other platforms and hybrid approaches in the past that this is... I find it difficult to see any real downsides to adopting KMM in a potential future development.

Mohit Sharma: Irrespective of the pitfalls, the first thing is how will I go and try it? Right? Here you don't even have to worry. Because it's in the language which you understand. Right? Even if you don't understand all the bits and pieces, it's fine. Just go and try it out. If you don't find it, good, roll back to what you were doing earlier. But with earlier Flutter or React Native, just go and learn new technology first. Try to understand how the data is being passed from one screen to another. Now, you don't have to mess around your head just to get started. It's still the same way, which you used to do earlier, in almost the same language you are doing right now. Considering iOS developer, and you're happy to go ahead with KMM.

Shane McAllister: Excellent. I think that's a very salient place to leave this conversation. Go ahead with KMM. If you take nothing from this podcast, take that. Mohit says, " Go ahead with KMM." And I'm delighted to hear that. It's been superb to have you join me. It's been a pleasure chatting to you and hope to get you back on board the podcast as we maybe try and keep up, I suppose more of a focus for Realm and for our mobile listeners as well, too. So we'll certainly get you back. I know Mohit, you do events as well too and live streams, et cetera. So for the listeners, go to essentially mogodb.com and use the navigation there to jump into our community where you'll see our events and our listings that are there. We also write content on the developer center all the time. You can go and look there at the MongoDB developer center where you can go in and filter by language of choice. Go in and pick Kotlin and you'll see all the Kotlin related articles as well too, some of whom have Mohit's name on it as well. I think keep an eye on Twitter, go to realm. io to see the latest there. You can go into the downloads page and see what we have recorded, regarding all the different SDKs as well too. We continually add new articles there. I know that we have learned how to build an Android app. We have Android database articles as well too. For any of the mobile developers out there, please jump in there. Mohit, it's been a pleasure to have you. Thank you for joining us.

Mohit Sharma: And thank you Shane for inviting me. I really love to have the chat with you again.

Shane McAllister: Excellent. It's been a pleasure. Thank you. Thanks to Mohit for joining me. A really enjoyable chat and lots to unpack there. We certainly could have gone on for lots more discussion. If you do want to learn more, do remember to check out the show notes for links and also go to realm. io to check out our realm Kotlin SDK, which went at GA, general availability back in June of this year at MongoDB World. There you'll find links to our docs and tutorials and everything that you might need to get started building with the Realm Kotlin SDK. Have you heard of MongoDB. localevents? A MongoDB local event is an in- person event and a day filled with educational breakout sessions and announcement packed keynote presentation, customer stories, free one- on- one, ask the expert sessions and lots of networking opportunities and much, much more. In October, November and December, we have. local events in San Francisco, Dallas, London, and Toronto. You can find out more about these at mongadb.com/events. The best part of all, all the MongoDB. local events are free to attend. Thanks for listening and do check out the show notes for any links and references mentioned. Thanks to Mohit for joining me, and thanks to you two the listener for tuning in. As always, if you did enjoy this episode and haven't done so already, please do leave us a rating and a review on Apple Podcasts, Spotify, or wherever you listen to your podcasts. It really does help us a lot and we very much appreciate it. From me, Shane McAllister, until next time, do take care and thanks for listening.