I'm only dreaming, right? Hello and welcome to this Talk today. My name is Nicola Zaghini. I am a professional mobile engineer with probably 13 years experience. Now I played many roles as you can see on the slide, engineer, architect, engineering manager, tech lead, all these kind of roles. I spent most of my career in native development and was, you can see there I got a couple of emoticons. The first one is over an airplane because I spent most of my career in the airline industry. So if you have flown in Europe, in America, in Asia, and you've checked in with your mobile phone or booked manage your flight, most likely you played with an app that I actually built or I was architect for only recently I moved into cross platforms development and this know four years ago. So it's not so know a bit of experience in there. And this is with the other modicons that I got in there which is a lady taking can aircut because today I work for Forest which is a silent software company for air beauty barber and spa owners which provide tools to manage, market and grow their business. So why I'm here today to tell you about cross platform because as a professional engineer that spent a lot of years into native development, I found after a bit of time I found myself much more productive and effective as an engineer into the cross platform domain. So if this is the reason that brings me here, what I would like to basically achieve with this talk is really to stimulate your curiosity and break a little bit of skepticism on cross platform development. In a way this is the talk that I really wanted to hear four years ago. Okay, how are we going to do this talk? Through a small story which is a real story. The story that how I approach it cross platform. So let's start with it. Let's start with a story. The story is divided in four quick chapters. The first one talks about quality, the second one talks about developer experience, the other one is the CTO pitch. And finally, how to build a team. Why it's a story. So it's a story of a product line that Forest had a b to c. So for customers doomed to be retired. And the reason is with unscalable, completely unscalable because Forest today has more than 8000 customer. Each one of them is eligible for having its own mobile application native. We're talking about white label apps. Clearly otherwise would have been totally impossible, but clearly at that stage four years ago was kind of smaller, the size of a company, but still too many apps into the stores to be able to manage in a decent way. Just think about a single bug fix. How can you fix and deploy thousands of apps in there with the technology that we know the native domain providers, right? So this is where it all started, and with me pitching react native to the CTO of the company in order to save the product line. So you may wonder now why a cross platform technology may save a problem which is of scalability. The reason is that when you go into a technology, then you bring along a lot of tool and instrumentation that you may not expect. So again, probably in here, the real killer feature was not code reuse, which is something that you think about all the time. You think about cross platform, but it was another thing, and I'm going to talk you through that. But before we dive into it, the real important thing that, oops, we all want to talk about when we say cross platform is quality. And I had to convince CTO of the company that with a technology called react native, I could have provided a quality solution to their customers which would have not let them regret the native stuff. So how is that even possible with react native? Your customers touch and feel the native graphic user interface component you're used to. They are used to. Sorry. So the UI scroll view has the same bounciness of the original UI scroll view because it is the original native UI scroll view. The label on the screen is a UI label. The button on the screen is a UI button. So there's no real, let's say nested browser or embedded browser. So your user is actually interacting with the web page. There is no real custom widget rendered in a graphqL, in an OpenGL engine, for example, or openGL canvas. That's the right word. Sorry. That may feel extremely fast, but even too fast for the platforms. I'm not used to it. As a user of an iPhone or an Android application, I really want something that looks like exactly the other app in terms of performance, in terms of responsiveness. Right. We don't want anything more or anything less. So react native can give you that. That's why I think the quality is there. So how is that even possible? You really need to understand a little bit of react native. This is not a course on react native. Let me just give you a little bit of, let's say a hint on how it works. So this picture is of a couple of puppets, right? They're there, and there is a puppeteer somewhere which we don't see, and there are some wires, right? So the puppeteer is moving the puppets. The puppets are our UI kit components. If you like the puppets are the real native graphical user interface component that the user sees and touch the puppeteers you don't see, which is the JavaScript engine in this case, right, JavaScript brain. In react native, it could be native code, or could be not native. Nobody cares, because unless you sit and you don't as a customer, you're not interested. And then you have the wires, which are the conjunction between the two worlds, right? So this is the app that we eventually built. As you can see, it looks like a very normal mobile application, and if we x ray this app for a second, what we're going to see is that exactly what I explained, but probably in a bit more technical terms. So the blue boxes are the native native code base, which has for example the react native SDK into it, and then you have the yellow box, which is the JavaScript engine, which basically makes react native code run, let's say in the middle there is this bridge that connects the two worlds. Let's maybe use a picture, which is even a bit more technical. I've stole this from a paper detecting proximity with Bluetooth low energy beacons for cultural heritage by Paolo Barsoki and Michael Girolami, because I think that gives a very, very good explanation again, of how react native works at a very high level. You don't have to get into the details, but on the left you've got this app which renders the react component tree, because react native uses react. Right, it's all JavaScript. He lives in his own shred. In the middle there is a bridge that bridges the two world exactly as the name implies. And on the right you have the platform OS with everything that you as an experienced native developer, know and love. Okay? So this should give you the idea of why react native can do the things that I've just explained to you, right? So I really know that I've said already Javascript too many times to annoy you because that was something that annoyed me at that time, right? And in fact, I also found this beautiful sort of a joke on the Internet, which it's really spot on, right? So I think I'm the blue guy in this case, and tell hey look, this is my favorite language, JavaScript. It's not true, because I'm going to tell you that is another one, my favorite language in a second. And you are there as can is developer looking behind my shoulder while I sweat? Because Javascript is completely drunk, as you can see over there. So I think this is one of the first thing we have to demystify for sure, but yeah, let's go through the story and we will talk about that as well. It was just very funny and very timely, if you like. So next slide. So again, just two, give you a couple of numbers there to explain that. When I say quality, I'm not talking about proof of concept of these application. We have more than 4000 live in the store at the moment. They all change based on the branding. We have roughly 12,000 daily active user and those app they do process roughly 2000 daily appointment taking money was well and everything. So we're not talking about a proof of concept, we're talking about something which is really serious in a way. Again, quality. This is how they look like when you switch the theme because we have a luxury of having multiple teams. So again, it doesn't really feel like something that is not of high quality, if you like. Just to close the quality chapter, I really want to quote here, probably the person which is most interested on providing quality solutions to their customers, which is Ronan Parcel, the CEO of Forest, which stated, all in all, this is one of the most impressive things the company has ever done, was a testament of the quality that you can produce with cross platform developer experience. This is another chapter that I had to go through because clearly the company already had native code base, native developer a little bit. And anyway, it's truly, truly important even that I communicate to you, my audience, developers, what is the developer experience for cross platform? We need to please our customer, but we also need to please ourselves in a way, because we live with this every day for a lot of hours. Right. So let's jump in there. And the first thing I need to tell you is that we're not going to use javascript, we're going to use typescript, which is a completely different language. Typescript, as the name implies, is very, very much typed. It's a very modern language. You won't regret swift or kotlin, because they are very similar one to each other. It's a very alive language. It's not something that is old or that it's not used. It's really, really a beautiful language to play with. And you can even write javascript within typescript if you really want to. But in general, I think typescript is a very beautiful language. Two, work with the IDE is another very important topic, because personally I was extremely skeptical about the possibility of debugging, for example, the possibility to have autocompletion of the code, the possibility of refactoring. And I can tell you it's just much, much better than I used to play with Xcode. In reality, I used Xcode and upcode in my previous life, let's say, because upcode was a much better refactoring tooling. Now the ide for typescript eventually are extremely powerful. You can go from the free vs code to intellij powered, let's say ids. And the experience over there is just a pair, if not better than definitely better. Actually. Sorry of what it used to be with Xcode, sorry to say. But that's the reality of things, especially on the refractory side of things. Fast refresh. It's another thing that adds dramatically to the developer experience. The possibility, as we have seen, puppeteers and puppets to change the puppeteer at every command save. If you change the puppeteer at every command save, it means that your app behaves instantaneously different. So you don't have to stop, recompile, wait for this. And that you just hit command save and your app changes the behavior right away. It may seem like, or at least to my years at the very beginning was like, oh, it's a nice thing, but I'm used to compiling things. True, it's true. After you live with that for a while, you will get very annoyed about compiling things. React I spent my previous life a lot of time preparing talks and doing talks in relation to architecture for is development what sort of architecture we're going to do, blah blah blah, react. When I've seen react, I realized that it was a beautiful, beautiful, not even a framework because react is a library. It doesn't even have two stand a framework, but a beautiful tool. Or to build mobile application. It's even more so now that react support hooks compared to previous react, which was bit of an adaptation to the events that happen on mobile right now, is such a spot on thing. Declarative, fully declarative in that requires a little bit of mind switch compared to how we used to build mobile application. Because being declarative means you state, sorry, probably I need to choose better words, but you say what is the state of your application and your application behave and change in relation to the state versus checking how is your application and modifying that. So it's declarative, it's much, much more powerful, and the time you start playing with it, you will realize how much better is or much easier is to build a mobile application this way with react community another really important thing when you evaluate developer experience is the community. Because no matter what, you're going to have trouble. Whatever it is, you're going to have trouble. And if you don't have a community, if you don't have people, there's no stack overflow answers, there is no even conferences is very very difficult to handle. Right? So the community you can check for yourself and do a bit of Google is very very big around react native now. And last but not least is this possibility that adds up to the developer experience given as a mobile engineer. Usually we're DevOps, we distribute our own apps, we maintain the relationship with the App Store, app reviews and all these kind of things. It's stuff that we do and we know. So the over the air updates, the possibility to send a bug fix over the air. Two, all the installed application you have, that's a real game change. That's absolutely a game changer. And in reality, if you think about my use case and the story that I started with, with an application which has thousands, thousands of installation that you really need to update all of them if there is a bug fix. This was the killer feature I was looking at. But in order to get there, I really needed to have react native with me and the cross platform power. Right. So this is a quote of myself. I know it probably is not great, but I quoted myself, no money can convince me back to the previous way of working. In fairness, as a developments that's 100% I really hope. I try to give you a bit of a glimpse in here. But absolutely developer experiences is amazing in fairness. Let's go. Oh, sorry, I forgot that I put here those videos. This is what an over the air update looks like. So as you can see the app boots, we've created a panel that explains to our user that there is a better code base that can improve their experience. It's very very quick was you can see the apps reboots quickly and after that the new source code is there. Those are two applications that we have on the store. But I really wanted to show you that because it's something that maybe could be cryptic otherwise. So now the CTO pitch, let's go and have a look at some metrics and numbers that I asked to convince that react native was something good to play with. Okay. I put at the top quality because without quality we don't really go anywhere. Right. We said it already, it's really really important that we have quality there. And then we can talk about the first thing that everybody thinks when you say cross platforms, code reuse. So I can state very safely that if you build an app that there's nothing strange with that you have 90% code reuse. Because it's very, very rare that you have to say if is iOS do this, if is Andre do that, it happens. But 2% of your source code and source codes can become very large, right? So it's not really a big number. But to me, the coder asked was never the killer feature of cross platform. Was never, never hit. Fine, great, amazing. But that's not the killer feature of cross platform, it's what it implies. What does it imply? It implies 50% cost reduction. Why is 50% cost reduction? It's 50% cost reduction because most likely you have an iOS and an Android app and you build a single time. If you build a single time, you have already caught enough your costs because you can have a single engineer. But most likely, let's say I find it difficult to explain this to you because otherwise you're not going to trust me. But the 50% cost reduction could be pushed even more. And the reason is, again, react. I've witnessed that with myself, with the product owner, which I worked with when we started this endeavor into cross platform with the designer, which we were all kind of people coming from the native world, and we were all shocked by the speed we could put together a single app, let's say the is app, without even realizing that by just installing that into the Android phone, we already had that app as well. So 50% cost reduction to me, you can push it much further because react is a very fast library to build application. So yeah, I really wanted to give you that. I don't want to push it more than 50, otherwise you won't believe me. But it's more. What does this imply? It also implies that you have a faster time, two market, at least 50% more, because you must have had one iOS and 100. Those two developers, those two guys are now insisting on the same code base. So unless you plan it very poorly, so they step on each other boxes, if they don't, then you have 50% type to market reduction for sure. Clearly there are other implications. Resource utilization. You will never be into the situation whereby, for example, there's a bug on iOS and a bug on Android, because the bugs are going to be common and every engineer can basically contribute to the same product, to the same app, rather than, oh, I'm an iOS, I'm can Android, that's not my thing, and so on. Plus another very, very important thing, I had a lot of trouble with that in the past, in my previous past, in relation to uniformity and feature parity, because it's very difficult, was you may have witnessed it. If you have a product which is both in both platform, having uniformity and feature parity is very difficult. If there are two different source boxes, even if you sit and I'm under engineer very close to each other, the feature parity is very hard to achieve in here. It's by design clearly because there is a code reuse. Again, as you can see, it's beautiful to have 98% of code reuse, but in reality is everything else which matters for real. 50% code reduction, 50% time to market reduction, full resource utilization and uniformity. Over the air updates are really a key differentiator here. This is a killer feature to me for react native for what it implies. Again, it does imply rocket time, faster lead time, rocket time, faster release frequency. They both add up two software delivery performance, two great software delivery performance. So let me explain a little bit. What is a lead time? A lead time is the time that you measure at the moment that you check in something into your source control to the moment that it's production available for your customer. This is a lead time. It's really, really important to have it as short as possible, especially if you have critical bugs and stuff like that you really want to release, right? Say that for some reason you can't take payment and all your customers stuck with that. You really would want to put that fix out as soon as it hits git and basically your QA says it's fine, right? With native development we know that it's going to take at least a couple of days of review time. There's no chance. We are all used to send email to Apple to ask for expedite review, but it is still a lot of time with the over the year updates. I personally send those kind of critical bug fixes, mission critical bug fixes in a matter of 30 minutes, find a code, write a test, fix the code, send it to QA out. It is the release frequency. It's yet again another extremely important metric because you could technically release five times a day, ten times a day, it doesn't really matter. You can release as fast as you want. This is a luxury that changes quite a lot the game of mobile development. It's all perfectly in terms and condition of both Apple and Google Play Store. The real important bit is that you don't add big features without going through the App Store, but you can add tweaks to the current existing features that are declared into your description and so on. And clearly you can fix bugs which will give your customers a much, much better experience, right? So those two things again are extremely, extremely important. Let's go on and talk about the team. And here is probably the most difficult conversation part. What about the current code base? Right? You have really two options here. You either extend what you have in a sort of a hybrid approach, sometimes called brown bag approach in react Native, which means your apps is alf native and alph react native, it can coexist. I've done this. It's definitely something that I would advise if your app is very big and you can't do a big bang rewrite. But my personal advice is don't plan this to be your future for too long. Plan this as removing chunks of your application, changing them from being native native to react native one at a time. So you are never going dark, let's say, with your app. But at the same time, you don't plan to have a native native code base and a react native code base coexisting together forever. That would be a mistake. The other option is to rewrite why you do this. You do this when your app is probably a bit dated anyway. You want two have a revamping in how it looks like, right feels, maybe features. But always remember you work at twice the normal speed you used to. So maybe you can evaluate that, you can go dark a little bit, rewrite the app, and then have a big bang once it's done. We have witnessed both in forest. You can go and find a lot of examples out there in the wild on Google of companies doing both approaches. I think they're both valid. Just my personal advice is don't try to pretend you want to live with the hybrid approach forever. That's not scalable. Okay, what about your current employees? Okay, one of the most important thing on employee is that you need to buy in from them. You need two buy in. You need to have employee happy for what they do. If they're not, be prepared for leavers, but also be prepared for new lovers. Believe me, that is going to happen. And I also have a story for that because before joining Forrest, I ran an r and D in my previous company to exactly spike react native. Understand if that was something of quality, could deliver quality, blah, blah, blah, all these kind of things. And I brought together with me a few iOS engineers, few Android engineers on iOS. It's my past, so I could move myself very easily on Android. It's not my thing. So basically, probably I got the best engineer in the company that day on that endeavor, let's say. And what happened under Christmas? I got this slack message from the engineer which told me, look, this thing you're asking me to do can be done probably. We were bridging quite a lot at that stage. We're trying to be in the hybrid world. I see how the hybrid works. That's impossible. Can do it. Just blah, blah, blah, blah. And I said, look, you are the most important person for Android in the company. So if you think you're most skilled, if you think that that's not doable, don't stress. I trust your word. I go back to the chief architect that was architect at this stage, and I'm telling them, look, it's not doable that way. That way it's not doable. So once you put someone into this sort of a pattern, mental pattern, the answer was, okay, give me another three days. Give me another three days. But I'm quite sure that's impossible. Blah, blah, blah. Came back after three days. The work was done. I don't remember exactly the specific, but I do remember, yeah, I did it. I did it. It's working perfect. It's also even clean. I'm very, very happy. You know what? He was a lover, but he also was a lever because basically for us was just an R and D. The R and D finished. And this person, this engineer, was so happy for what they'd learned. They figured out what they had that they said that they moved to a company that was doing react native already. It was a bit of a shock for us because we lost a very good engineer, but at the same time was a good witness of what when you break this initial barrier of, I want to work with this, I don't care. But we forced this guy a little bit. And after we forced and put this guy outside of his comfort zone, he didn't want at the beginning, but then it was like, I'm not going back. Not going back. In a way, it's the same feedback that I gave you two slides ago. I'm not going back. Anyway, let me give you the golden rule for building the team, which I already stated, but I'll restate. Oh, no, this is really important. I didn't tell you before. Experienced mobile native developer in the team. Don't pretend that if you do cross platform, you don't need native developers. You really, really need native developers in there. Because react native has that react part and the native part, and you need to tame both of them. So if you have a team, you really have to have at least one. I was Engineer 100, engineer experienced, able two build mobile in the past. So they know what it means to build mobile, then you can build on top of that. But that's really important that you have those figures, otherwise you will find yourself into trouble. There is other tools like Expo, but in general, please have an eye. As an under engineer, they will speed you up dramatically. Engineers that buy in and want to learn. Okay? Because if you can't hire for react native specific person, you will want to try to train them. Or anyway you want people that are very, very interested. And in fact, let's jump into the how to hire again, strong native background experience iOS and Android, you need to know what does it mean to build an app. It's really, really important, even for the old DevOps part. And again, the learning attitude and the willing to get out of their comfort zone. If you're up into like we do, mostly to get people that are pretty much only iOS or Android engineers, but they really want to challenge themselves. If you find this attitude, if they have the experiences, you won't regret to hire them, because basically it's a perfect mixture to make a team able to be successful in reality. So to recap very quickly, we talked about good quality, how react native works more or less probably you get now an idea, the user touches the break thing. Developer experience is just great. I can't state it any differently. The CTO pitch, the metrics, the numbers you've seen over there, a very, very important number. The speed, the cost reduction, time to market, and overall the delivery experience, which changes very, very dramatically. And build a team, what sort of person you should look at or what sort of team you should have in order to be successful. That's everything for today. Thank you very much. If you want talk with me, just get in touch. Here is the Twitter handle and the email. Thanks a lot. Till next time.