 Hello, hi. Welcome to JetBrains, developer advocate on Kotlin multi-platform and mobile. This is not my full story. I'll say more when I get there, but this is many things in a short time, I guess. First of all, let's have a little disclaimer. This is not, first of all, A, getting started or, you know, examples of multi-platform technologies. And it is not me trying to sell you anything. So just a little background. I have been thinking about multi-platform and chasing it, advocating for it for many years now. And Kotlin fit into this puzzle, which is why last year I actually joined JetBrains, not the other way around. So I'm here not as a representative, but as a, you know, believer, let's say, multi-platform. So let's start from the basics. All software runs on a platform. It's obvious, but then what is a platform? The way I see it, it's mostly split into some essential components. It has a language and it has APIs or a framework. Let's take the best example, like the lowest, let's say. The machine where your code runs has a language, which is a language of the CPU, right? The CPU instructions are the language. And the framework, I guess, in this case, would be whatever you read in the instruction manual for the CPU, how to, you know, shift all the registers and stuff like that. But on top of this, you start building and you build and build and build and there's platforms inside platforms inside platforms. For example, the JVM is its own platform, right? The language is bytecode and the framework in that case would be the JDK. A browser is a platform. Like there's many kinds. And in particular, I like to differentiate between soft and hard platforms. In the sense that, like, a soft platform is something that either gets inlined and, like, flattened to a single platform when it runs. For example, C++, right? They get compiled directly to CPU instructions and it's as if they disappeared. There are other platforms like the JVM, which are definitely heavier than that. And you can even think about what is the cost of bridging between the inside and the outside of the platform. Yes, it is true that technically all the code in the end runs on the CPU, sure. But there's different levels of easiness from going in and out. And this is the trick. There's a third component, which is conventions. Whenever you have something complex, like user interfaces, it's almost as if you had like a separate meta platform on top of everything else. If you take, for example, mobile Android and iOS, if you compare them, it doesn't even matter how they are technically implemented, right? The only thing that matters is what does the user expect? What is the behavior that one wants to encode, etc.? Like, for all its work, there could be simulations running on the same hardware. Doesn't matter. And this is the trick. Conventions is one of the reasons why we have not been very effective in doing multiplatform. Another thing that I wanted to clear up, let's say, is the definition of native. Because we often hear about, oh, native development, but what is native? Because there's generally two kinds of native associated with this. One kind is the machine native, like code running, very low level, C-ish. The other native is native for the platform. So in the case of the JVM, for example, it would be like native means something that runs on the JDK, right? And so, like, it's often very important to distinguish between these two, because it's easy to, you know, start running in one direction or the other, and then... But then why? Why should we do multiplatform? Because, like, we have not really been doing it so far than what is the big deal. So, first of all, is there any water here anywhere? Or... Yes, thanks. Let's put it this way. Unless, you know, specific cases, etc., today, all products, services, apps, they don't run on one platform. They are an ecosystem, and they run on multiple platforms. So this is the reality today, and it's not slowing down. It's only going faster, right? Some platforms look very similar, mobile. Some platforms look kind of similar, like mobile versus desktop. Some platforms don't look at all, like server, for example. But despite all of this, it's still your thing, your product running in all of this, somehow. And many of the rules, the makeup of your product are going to be duplicated, right? And the point is, you're not duplicating, like... It's not the act of writing code that's a problem. And it's not even creating something the first time. The problem is other people, in general, in the sense that the moment where you join a team, you can't scale if you don't have a way to enforce these rules to stay together. Otherwise, they will just, you know, diverge, and they do all the time. So you are duplicating specifications, because those happen very often during implementation. You're duplicating architecture, naming conventions, solving problems, bugs, assets, UI, and all sorts of things. And while doing so, you are creating silos. You're making it so that you become sort of an enemy with the other team instead of working together. And then why aren't we doing this? What's the big deal? So it's complicated, as usual. So even when the platforms are very similar, like mobile... Oh, thank you very much. Sorry. Even when the platforms are very similar, they're still very different. In the sense that the conventions are so different that it's not just about running the same code. You really have to think about the big picture. You have to think about how architecturally, structurally, how your app behaves and what is expected of it in all the different platforms. Also, technically, we are doing it, like if you look at CC++, those are technically cross-platform, in the sense that they run on different CPUs, etc. The difference is the conventions they target are all very, very similar, like file systems or, you know, I.O. in general. That's more or less standardized. So it's a lot simpler to do that effectively cross-platform. But when you start talking about UI, you start talking about sensors, user behavior and other things, then it's a whole different mess. And again, CC++ helps with, like, soft platforms in the sense that it's easy to port that over. Otherwise, other attempts of doing something more haven't really been spectacular. So if you recall, well, Java, first of all, it works. You can create cross-platform UIs, etc., but it doesn't feel native. It's heavy. It won't even get me started on all the JavaScript-based attempts, which I won't even talk about. So we all know and multi-platform got this bad fame of just being bad, not working, not native in that sense, because it's trying to hide the conventions. In fact, if you recall, write once, run everywhere, Java's motto, I think this is the flaw, because you're not trying to write something once and then just forget about it. You're not trying to make all the platforms one thing and then, you know, just not have to think about stuff. To me, it's the other way around. You need to engineer once, and by engineer I mean design, understand, think, plan, solve problems, write interfaces and common code once, and then you don't just run it everywhere, you specialize it everywhere. This is how it should be. This is the key to doing multi-platform the right way, the way that works. And essentially, this is the whole... Okay, we have five minutes. Perfect. Okay, so because this is the core of it. Multi-platform, first of all, what you need to understand is that you already do a multi-platform because you are shipping on different platforms. You're just doing it wrong because you're not sharing anything, right? All, you know, edge cases or it's not my problem because it's on the other platform, et cetera, those don't help. We really need to come together to make this work, because in the end, again, it's not just creating something the first time. That something is going to change. Requirements are going to swift, you know, under your feet very, very fast and when you don't have time to handle them. And so you don't want to be spending time solving problems twice. You don't want to be spending time fixing bugs that should have not even existed. Plus, in my experience, the specifications, the real specifications of a real product, they come 80% of them while you're actually making a product. And so, if you make it as two separate entities, you're going to have two separate sets of specifications with all sorts of bugs related to they should be the same, et cetera, blah, blah, blah, blah. Plus, we have this tendency of glorifying shipping fast versus shipping value fast, which doesn't mean just put something out. It means, sure, we don't want to, you know, take forever, but let's think about the long term. Let's think about how can we get value to users in the fastest cycle, which is not just getting something to them, because, you know, something buggy that doesn't work is not value, in my opinion. And also, I think the biggest fallacy of all of this is that people believe that multi-platform, whenever it comes up, it should be a silver bullet. It should fix all problems, make everything easier, faster, et cetera. That's never going to be the case, because you're not going to be faster in the short term. You might be same speed, maybe even slower, but then the return of investment is going to be huge. It's not going to be easier. You still need to know all the platforms. Not you, you, but your team needs to design and think comprehensively, right? And so that's what needs to happen. And we need to stop thinking about UI first, as we often do as mobile developers, because UI is just one side of all of this. Just much more than that. It's actually, most of it is not UI. Imagine if tomorrow they came to you with an SDK, an Oracle that just tells you exactly what you need to display. You don't need to care about state management at all. You don't need to care about what happens now, edge cases. You just draw to the screen. That would make development for mobile so much easier. It's crazy. And this is how you can do that today. Kotlin is a great example of this. And here we cycle back, because I don't want to say for the first time, but the first time in a way that's easy, tooling-friendly, and other things, you have the opportunity to create specialized code that doesn't run on a hard platform, like embedded in some scripting runtime or something. It gets flattened down to whatever is native for each platform, which to me is the key to doing this. There is still a big issue with UI, which is a completely different topic altogether. But again, you don't need UI to the multiplatform. You can still share 80% or more of your actual use cases and code without even touching UI. And even in the UI, you can still get really close in the presentation logic sharing that, et cetera. Otherwise, on some platforms like Android, you might never have the control you need. To have true parity, depending on your use cases, et cetera. And in that case, the only solution is to go one level deeper, but then when you do that, it means you also need to recreate all the infrastructure that that level gives you, which is something Flutter does, for example, but it's one case. And it won't work for everyone, and it really depends on your use case. But the point is, it's complicated. And you need to think about it, because right now you often believe you're doing less work, and perhaps that's true in the very short term, but it's not true at all in the long term. And things are not slowing down, so they're going to come for you. And time is up. So if you have any questions, I'll be glad to answer offline. And you can find the slides in five minutes at this address. Yeah, follow me on Twitter, and thank you.