 So, am I audible? Yeah. What about now? Is it better? Yeah. So, am I audible now? Loud. How about now? Yeah. Yeah. So, one second. This isn't working. Right. So, I will start my introduction. My name is Anshul. I work at a company called InShorts. So, InShorts is basically a news app that gives you news summaries in 60 words. I was the co-founder of a company called Beta Glide. We were into app analytics, particularly uninstalled analytics. Our company was acquired by InShorts about two months back. I was also one of the because at DroidCon 13, my talk was about reverse engineering Android apps. And yeah, I graduated from IIT Kharagpur in computer science. So, I will start with a bit of background about our app, the place where I am working right now. So, InShorts is basically a news app that gives you all the latest news in 60 words. So, what we saw was that content, news consumption was really broken and it was over complicated. People generally want to see only one piece of content at a time. They want relevant content and they want a little bit of context with the news. But most of the time, they don't want to go into a whole lot of detail about the article. So, actually reading articles waste a lot of time for people. And our app is a way that you can stay updated in a fast manner. So, we are currently India's highest rated news app. Our rating on Play Store is 0.5. We have about 90,000 reviews. On iOS as well, we have pretty good ratings. So, we have actually, so this is a very interesting data point. So, since we have launched, all our users combined have spent more than 1500 years worth of time on our app. So, that is something that we are really proud of. We have actually served more than 5 billion card views. So, like you saw earlier, we actually give a single news article in one card. So, if you combine all the card views, there have been more than a million of them so far. And we have more than 3 million installs if you combine both Android and iOS. The Android number is more like 2.9 million. So, stay informed, that is a myth. So, basically, our app strives to keep you informed in a fast, simple and precise manner. So, now I will come to the subject of my talk. So, this talk is basically about React Native. So, for those of you who are not aware, React Native is a framework that was recently launched on Facebook for developing native apps using JavaScript. And in this talk, we will be mainly focusing on what impact this technology will have on the app ecosystem and why it is cool. So, actually, this has caused a lot of hype around the world. So, we will be digging a bit into the hype and seeing if that hype is justified and what are the good things about this tech and where is it currently lacking. So, let us start with a very simple thing like what is React Native. So, I just copied this from the native page. It is a framework for building native apps using React.js. So, what is React.js? So, React.js is a library for building user interfaces and it is built for reactive applications. So, reactive means that the app changes fast based on user input. So, if you are changing any data inside the app, it actually updates faster than what you would expect in a normal JavaScript application. So, we will go into a lot of detail about how this works and why this is different from all the other JavaScript user interfaces. So, what reactive basically means is that what you can do is that you can say that at one particular moment of time, this is how my app should look like. So, you can say that, okay. So, let us take the example of InShorts. So, InShorts has an image, a title and a summary and there is a link at the bottom. So, I can just say, okay. At an instant, I will have this image, I will have some text, I will have some summary and I will have a link. And now, the cool part is that if you change, so all these four things are variables. And the cool thing about React is that the moment you change any of these variables, the view will refresh instantly. Now, as Android developers, you will be probably saying, like, I mean, this is something that is so obvious in Android. But it's actually very difficult to do performantly on JavaScript because what you have to do is you have to re-render the DOM every time you make a change. And the problem is that DOM wasn't built for applications. DOM, like the name suggests, is document object model. So, it was built for documents and documents don't change with user input. Right? So, that's one of the fundamental things that is broken in the web right now. Many people are banging their head trying to fix it. And this is actually React.js is one of the ways one of the frameworks actually been able to impact this problem, right? Without, you know, imposing a whole standard. So, within the existing web ecosystem, you can use React.js to do performance updates on your JavaScript or your web views very fast. And we're going to what is so special about React that allows it to do this. So, yeah, this is one of the main points, right? It's created and maintained by Facebook. And there's a fun fact here that the Sagram app is actually built on React Native. I'm not sure about the Android app, but at least the iOS app is built on React Native. It is actually a single page application running inside a single activity with all the view logic written entirely in React Native. But we're talking about React.js for now. So, just to make things clear. Yeah. And of course, it's 100% open source. So, that's one of the good selling points of this technology. Yeah. So, I'm not sure how relevant this is for you guys sitting here, but for anyone who's ever worked on a single page web application, they'll probably be thinking that how is this possible? I mean, how can you re-render everything on every state change? Like, there are four variables. Any one of these four variable changes, and I'm changing my view. How is this possible inside a document object model? So, the answer is that React.js has a concept of something known as a virtual DOM. And as we'll see later, this concept is actually very powerful and very generalizable, which allows it to be applied to more than just, you know, web applications. You can actually use it for React Native for Android and for iOS, the same concept. So, the basic concept, you know, like I said earlier, now, doing updates on the DOM is expensive. Every time you change a particular part of the document object model, everything that is a child of that particular object has to be changed. So, a document object model is like a tree. And every time you change any node of the tree, the entire subtree has to be re-rendered. And browsers are not good at doing all this, right? So, and DOM itself is extremely heavy. So, what these guys noticed was that instead of updating the DOM, you can actually update JavaScript projects, right? So, what they did was they made a representation of the DOM inside JavaScript. So, that is called a virtual DOM. So, it's basically a tree that represents the DOM, right? Now, every time your app does an update, instead of doing that update on the DOM, it does that update on the JavaScript representation, which is called the virtual DOM. And then what it does is, it uses clever hackery to sort of calculate what changes are needed in the DOM. So, every time you do an update, the virtual DOM is updated. And then there's a mechanism inside React.js that decides when it needs to update the real DOM, right? So, if you look at this problem from a very abstract way, right? Basically, what you have to do is like, initially, you had a tree, which is a bit of a screw up, we'll call the virtual. Now, you need some updates. So, you got another tree, right? Now, what you need to find is, what is the minimum set of operations that I need to transform this tree, this initially to this final tree, right? If you can calculate that minimum set of updates, then you only need to do that minimum set of updates on the DOM itself. I don't have to actually go about doing the whole subtree, right? So, that is actually the whole insight behind React native, that instead of having this thing where anytime something instead make whatever changes you want in the virtual DOM, you use some clever algorithm to figure out what minimum set of updates that is needed to go from the initial state to the final state. And then you just push minimum set of updates to the DOM. This is actually minimizing the DOM updates in a very clever way. And that is actually the secret behind its performance. So, there's another callback over here. There's a callback shoot component update, which is triggered before re-rendering. So, now, what you can do is like, what normally people do is that they just ignore this, React handle all the DOM updates. But in case you need to handle this yourself, you can use this callback. So, an example of this would be like, if there are like, you have a chat application, right? Which are multiple threads of conversations, right? And only one thread has changed. So, you can just specify that I need to change only this particular thread of conversation. And I can just ignore the dates on the rest of the threads. So, this sort of application specific which gives even more performance. So, yeah. So, enough about JavaScript. This is after all an Android conversation. And we'll come to how this is element in Android very soon. So, you guys must be thinking that, you know, okay, you've gone about something in JavaScript and that's making great apps. And this is a new, I mean, they've been like so many of these, you know, hybrid apps. And I mean, some of you must already have experienced these frameworks. And the main problem that you face is that they aren't performant. Like, you can always make a native app that performs better, right? Always may and the difference is visible to the end user. So, as an Android developer, it doesn't make sense for you to make a hybrid app, right? Because unless it's a really, really light kind of app, any sort of complex calculation and you just forget about it. So, and what do you care about this? I mean, like this is JavaScript framework for building apps. So what? I mean, so I'll talk about why you care, right? So, usual stuff that you can afford multiple platforms. The layouting engine is slightly better. It's more flexible. It's easier to work with. This is a CSS Flexbox layout. So, this is something that is specific to the web. But based on my experience, I find that it's usually better native Android rendering the Android layout system. Yeah. Oh, yeah. And of course, you can use, so there's a lot of JavaScript libraries out there that give you a lot of, you know, out of the box UI functionality. And you can just directly use that instead of having to. So, for example, if you wanted, like, arts, so charts on Android, they're like one or two libraries. I mean, it'll difficult to pull off. When JavaScript, you have like T three, you have so many charting libraries, each with their own way of doing things and very, very flexible. So you get that whole ecosystem. So this is the usual stuff. I mean, this is not something that is special in react native. You can do the same thing in Cordova or phone gap or whatever. You can have a shared code base across multiple platforms, right? This is usual. There's some not so usual stuff. So all these, you know, hybrid app frameworks generally sell you this that right once use everywhere. That means that you have a single code base that is running on Android on iOS on the web. But the problem with this is that the users of each platform, right, they have different expectations. So as an Android user, you will want something that is more Android, as a iOS user, you'll want something that is more, you know, native in iOS. So this is actually not a good philosophy from the end user point of view. A better philosophy would learn once right anywhere. Why do we want to have a common framework for building apps across platforms? That is because if I want to support three platforms, I'll have to hire one Android developer, one iOS developer, one web developer, then I have to make sure that all my feature sets are in sync, right? And I want people who are expert in that particular field, right? Whereas many, many developers out there are comfortable with JavaScript much more than they are with Android or with iOS. So these guys just have to learn this framework once and then they can develop apps for whatever platform they want. So it doesn't the, so you just need to learn it once, the way of the method that you use for building apps doesn't change based on the platform. So that is one of the philosophical differences. So the key difference is that using React Native, you will still write Android specific code, you'll still write iOS specific code, you'll still write code that runs only on the web, but that code will all be using a common framework. So that's why you don't have to keep three developer teams. You can have one developer team, all of them JavaScript developers. It has very easy interfacing with native modules, which is something that is lacking in certain hybrid app frameworks. And one of the good things is that it's very easy to drop into a existing project. So another problem that you generally face with hybrid app frameworks is that if you're building an app from scratch totally in the hybrid app framework, then they're good. But if you have like, you know, six screens already built inside your Android application, and you just want to add one screen with a hybrid kind of layout, that's difficult to do. So React Native actually makes this very, very, very easy. Yeah, so now we come to the real reason for this talk, what is the big difference, right? So React Native actually renders native views. So this is actually a big difference, like your hybrid app frameworks are usually running inside of a web view or something like that, right? But React Native is actually transforming whatever code you're writing into native modules, right? So now I come back to why I made that whole hoopla about the DOM tree and the tree updates, because, okay, so yeah, this means that because it's native, you have a consistent look and feel, and you have a consistent user experience, because if you add a tab bar, for example, it'll look like the native tab bar, you don't have to write a whole lot of CSS to make it look like a native tab bar, it'll behave like a native tab bar, because it is actually a native tab bar. If you actually go inside and inspect the code, it's actually a native tab bar. There's no like JavaScript or HTML there. And of course, it means much, much better performance. So one of the things I wanted to add here is that so coming back to my old analogy about the DOM tree, right? So if you think about it, the Android view layout hierarchy is also tree, right? So the same concept that you applied on the DOM can be applied on the Android layout view hierarchy. It's as simple as that, right? But so it makes a virtual DOM, which is a JavaScript object, it calculates updates on that. Now, instead of updating the DOM, it updates the Android view hierarchy. That's it. It's the same everything and they've just added another sort of boilerplate code to make it interface with Android. And the code technology is exactly the same. And because it is only updating the view hierarchy, like it is updating the view hierarchy in a very, very optimized manner because it is calculating actually the minimum set of updates needed on the view hierarchy. And that is the reason for why it is different from all the hybrid app frameworks and why it has much, much better performance. So again, why do Android devs care about this? Like, okay, so some of us are developing on various platforms, but most of us are core Android developers, right? So you must be thinking as a core Android developer, why would I ever stop using my native app and go to something like react.js? So even if it has equivalent performance to a native app, why would I even do that? Why would I learn JavaScript? Why would I code JavaScript? Like the shitty language? So why would I do that? So one of the benefits is that without any overhead in performance without any loss in performance, you get the benefits of the whole JS ecosystem. So for example, if I was today building a app which was heavy on charting, I would prefer using the JS charting libraries and they interface very well with react. And then ultimately, everything is rendered natively. So I'm not getting any performance overhead. So that is one of the, you know, draws for me. And the other big thing is that you can actually do over the air updates. So over the air updates is something that is very difficult to do in your usual Android, right? Because it requires like code injection and stuff and you have like Android putting limits on that. Of course, any OS will put those kinds of limits. But because this is JavaScript, you can just, you know, change the JavaScript code and now you have a new app. So that's actually one of the most powerful things about this technology. And that is why probably even native Android developers would consider using it because this feature you can't get on a native Android app. So let's talk about performance. Yeah, so this comes down to my earlier point. So instead of DOM, you have the view hierarchy, you have native components that gives you very good performance. And you also have asynchronous execution. So your UI thread is running, but all this DOM updating virtual DOM and calculating the updates and everything is happening on an asynchronous thread. And the moment it calculates a minimum set of updates, it just pushes that to the main thread. So it because it is happening in an asynchronous manner, it becomes even more performant. And the final reason is that they're using a really good JavaScript engine, JavaScript code, which was by Apple. So on iOS, Android or web, in all the three platforms, they're actually using the same JavaScript environment, which is JavaScript code. And that is a very good decision on the react teams part, because one of the big problems with JavaScript is that changing the environment, certainly your quotes are speaking because this environment doesn't support this directive or whatever. So I actually had a demo to prove to you that it react native is as performant as it claims to be. So I can't actually show this right now because technical issues. But I can share the link with you guys offline and or you guys can meet me outside and I can show you on my phone. So it's an open GL app running on react native. And it has pretty good performance. You'll be blown away basically. So one of the takeaways from so I explode this for the last two or three weeks, I looked at a couple of apps. I looked at a couple of demos. So the takeaways, the key takeaways are that it's better than most hybrid frameworks. But give it some time to become production ready react native for Android was launched in September. It's not production ready yet. There are lots of features missing. So it will still take a couple of months or more for it to be used in the real world. It's a good choice if you want quick prototypes. And you want to do cross platform development, but it is really, really promising. Because it gives you native performance. So everything is native, but it gives you some additional features which you can't get on any native app. So let's talk a bit about the over the air updates thing. So this is a little technical. So basically, this is how you actually define an activity using react.js. So you just have to do this kind of initialize this react root view object and give it a path to a bundle. So bundle is basically a set of JavaScript CSS images, everything, which is written in react.js. And if you make an activity and you do this kind of thing and you give it a path to some bundle, certainly you have an activity which is loading all its views from JavaScript from that JavaScript bundle. Another cool part about the JavaScript bundle is because it's a JavaScript bundle, you can just change it whenever you want. There's no problem. So there's actually a project by Microsoft called code push. So the only thing it actually does is it gives you sort of method. So in the previous code, instead of doing that adding hard coding the path, you just add this. And now suddenly you have over the air updates. So just change it on your server. It automatically handles versioning and everything for you. It allows you to configure when you want to check for an update. Updates are downloaded silently. It also allows you to configure how to present the update to the user. So if you want that, so if you're doing an update on Android natively, you have no choice but to accept, make the user click on OK before updating. But with this, you can do silent updates without the explicit consent of the user. So there are some gotchas, of course. There will be some conflicts between if you do an abstract kind of an update and you do an update using this mechanism, you need to figure out a mechanism for handling both these cases. There will be some versioning issues, like what if a user misses a version and there are all kinds of issues that might be caused due to that. So you need to think about how you'll handle that. You need to manage. So if you're updating React Native from 0.8 to 0.9, you can't do that over the air. You need to actually send it through the app store process. And the biggest gotcha is actually that these bundles are large. They're pretty large. So downloading a bundle every time is kind of bad. If there was a diff mechanism, it would have been a little more possible. But then you have this whole problem of how do you manage this between arbitrary versions? So if you're only giving the diff every time and the user skips one update, that user can never do an over the update. So you need to figure out some way to manage that as well. So it's not like that easy, like the way I showed it earlier. There are some problems, but it's still promising. So yeah, here's the best case scenario. You can update your app whenever you feel like it. Of course, since your entire view logic is sitting on a server somewhere, and you can just download it, you can be test very easily. So instead of loading the same asset every time, you just give a URL parameter and based on that load a different bundle for different sort of users, you can launch on other platforms in days because you can reuse most of the code. You just have to write some of the platform specific views. You can maintain a uniform code base. That means your entire code base is in one language. If you're supporting multiple platforms, the performance is, like I said, pretty good. And biggest part is that you get the native look and feel, which is very difficult to do in any sort of hybrid app development framework. You can't get that native feel. So and of course, there's this point about easy interfacing. So it's very easy to load a native module and reuse it and pass all kinds of data between the native module and the react view. That is very, very easy. So like I showed you, you can just drop it into activity and you can have like six activities that are your normal app and one activity that is just using react native. So this is a good way to experiment as well that you can just and you can also if you combine it with over there updates, so you can have actually one activity which you can change whenever you feel like you can also a be tested. Right. So this way you can very easily deploy new features and test them out. And if they work, put them in the main app. Don't have to go through the whole update cycle and all this kind of issues. Right. So I think that's all from my side. If there are any questions, I would love to answer them. Yeah. Thanks for the really helpful. I just wanted to know about the permissions issue. If we do over the air updates, what happens to the permissions? So permissions are not affected. Like you can't change the permissions for that. You will have to do an update through the Yeah. Thanks. So the awesome part was that it has a very good performance. But can you share us with the stats of UI load time as it has a boilerplate code that converts JavaScript into native that so can can we have a stats of UI load time for react native and native app? I can't share the stats because like I didn't find any I was actually looking for the same thing when I was evaluating this. So there are no publicly available benchmarks but but can can can't we have our own statistics for this thing? So I don't have those but I'll be happy to share an example with you. I have some phone so you can just, you know, sort of look at it yourself. But but we can't compare it with a native thing. Right. For that you'll have to actually implement the same thing in native and that so I didn't go into the effort of doing that. Sorry about that. So so when in short says planning to move your mobility stats to react native. So we haven't taken that decision yet. So like I said, one of the things that is attracting us a lot about this is actually the AB testing and experimentation part. So since we have a card based format, one of the ways we could do it is like just slip in a card which is a react native card, which has a different kind of a look and you can experiment that look with different users. And then you can use that to get quick feedback about what is working in the real world and whatever work then you can deploy it on your main app. Because right now there's no mechanism to test a UI change, AB test a UI change on a large audience. You'll actually have to use this kind of AB testing frameworks, which do dynamic injection and they have some performance overhead. So that is a little difficult. This is a easy way to do it. They also have their own limitations. So this way you can just completely change the entire behavior of the card. You can do whatever you like. So that is one of the things that is interesting. But we have only been exploring this, like I have been exploring this in in shorts for like a couple of weeks or so now. So we still have to take the decision on that. Like I'm not sure about your question. So are you what handshake are you talking about? Right. Yeah, so you can actually use any native module, like you can even write your own native module in Java and use it. So for example, if you wanted to, you know, write your entire web interfacing logic like multi threaded HTTP calls in Java and just sort of pass the data to react. You can even do it on that level. Right. So you can easily use any of the existing location APIs or any existing modules, but you can also write your, you can also do a sort of thing where the really, really performance dependent parts in the really, really the parts that are really, really dependent on your particular platform like Android in this case, you can put them in Java, you can put them in native and you can just have the UI in react native. No, no. So what you can do is that you can just have the UI logic in react and that is getting updated and you can manage the wallet in Java like you do normally. I'm sorry, not really because one code is actually handling the view logic and one code is actually handling the transaction behavior. So yeah, so actually you'll write the same code in Java if you write a whole native app instead of one part in Java, you can just change that to react. It's working. So that's totally up to you. You can use the JavaScript maps if you like. I'm not sure about the same activity part. What I am pretty confident about is that you can make different activities. Definitely. As far as I'm aware, you can actually just have a view that is a react view and you can just put it in a view hierarchy somewhere if you like, right? Though I don't have code examples and I haven't gone into too much detail, but from what I recall, very vaguely, you can do this. So like you have your view hierarchy, one node in that is your maps and the other node is a react, right? And you can just put them wherever you like. So we can have a react based UI and a native based UI on the same activity. Right. So I'm not 100% sure about this. I'll have to check this, but yeah. Hey, hi. This is here, here in the balcony. What about hardware support? Means how camera, Bluetooth, what it supports? So you can use the existing Java libraries for hardware interfacing. Okay. And even offline connectivity, right? I'm sorry. Offline caching and all these things will be taken care by native only, right? Okay. Is your application built on this framework? No. So our application is purely native. We are just exploring this for, like I said, for experimenting with some UI changes. So we haven't used this anywhere in production yet. And in my personal opinion, it's probably not ready for production use as of now. It's a promising technology. You need to wait a couple of months. It's launched in September. Give it at least three, four months. And then you should use it. Okay. And what about office caching? Like native part will be taken care by native. But what about the JS part? I'm sorry. I didn't get your question. I'm sorry. Office caching. Yeah. Code of office caching. Yeah. So I'm sorry. I don't know a lot about that. Maybe you can use the existing JavaScript minification tools to do some sort of code obfuscation obfuscation in JavaScript. I'm not sure how well that works. So yeah. Thanks. Can you be loud? Architecture. So there's all your business logic. Is it in your views now? What happens to layers and the native way of decoupling layers? What about that? So like I said, that is a choice that you can make. You can keep only the view logic in JavaScript before like, or like Instagram date, you can actually put the entire app like all the business logic in JavaScript. But that way you'll have to architect it the react way or the JavaScript way. But if you're more into architecting it like an Android developer, then you can just keep the view logic in JavaScript and react. And any of the business logic you can keep in Java and you can interface between them. Thank you. And how do we see our UI components in different platforms like iOS or Android? If I want to view my screen, which I'm reading on, I want to see how it looks in different screens in iOS or Android. Is there a kind of visualizer that you're having? So you can just use, so the way it actually works is that you need to set up a developer dev server on your machine. And then you can just connect any device on Wi-Fi. And then if you install, so if it's an iOS, so the react code actually lives inside of an app. So if it's an iOS app and you have react code inside it, so there are ways that you can connect it to your server and then you can change your code on the machine and it is live. So it actually even does like live reloading. So once you set everything up, just change your code and save it and the view gets refreshed automatically. How much of an access do we have to the code that is generated by react? Like tomorrow if I see that I have a performance problem and I'm not able to figure out from this existing react code where this is happening and I want to look at the code that is generated. Can that be tweaked and that be reflected in the end app or do I have no control over it at all? So you have control but not in the Android way in the sense that you can use Chrome debugger to actually see what is happening and you'll have to debug it in a sort of JavaScript kind of a way. Whatever JavaScript code you have. How much of community support is there for react for Android because online I couldn't find much resources for Android alone. Like iOS there were plenty of resources. Yeah so iOS was launched actually at the beginning of this year and Android was launched just in September, mid-September. So yeah so it'll take some time like I said that's why that was actually one of the reasons that I was saying it's not really production ready yet because many of the many code features are missing and there's not much documentation. Like even for all the information that I had to make for this slide I had to do quite a bit of research like I had to go and look at videos of you know people and stuff like that. So there wasn't a single resource where I could just see everything. So that problem is there I would agree on that point. Yeah as you said a number of hybrid platforms are available. Frameworks are available to develop hybrid apps. So still the Android developers are moving towards native development. So for some period of time they are liking the hybrid platform framework and then they're avoiding using it and they're moving to native development. So as being you yourself as Android developer what do you think for React.js framework? So what I think is that the big difference between React and all the other hybrid app frameworks is that React is actually rendering views natively. So that means that you get that native experience like there's no change like you won't be able to tell a React app from a native it's not possible. You won't be able to tell because the performance there's no performance lag and it's been like two months since it's launched and this is the scene right now. So three or four months down the line it'll probably be at a very good level that way. So that's so I think that is a very big difference. So the major reason why people are abandoning hybrid app frameworks according to me is that first is performance and the second is a lack of the native experience like that's very difficult to create the same kind of buttons the same kind of material design kind of use very difficult to create in CSS and JavaScript. Right now React.js also do not have that much of handling of complex level of designing or you know designing a complex applications. Still we are waiting for documentation and upgraded framework. So does this framework has a future for Android developers in the next few years or something? Yeah because Facebook is maintaining it and if you go down to the repository of React native you'll see there's quite a lot of activity happening there like three or four updates every day. So it's happening at a development is happening at a fast pace. I think what Facebook is trying to do is this my hunch again maybe down the line they'll migrate everything to this. That's how I see that maybe they won't maybe they will but given the level of interest and activity around this I think it is fair to say that it'll be a pretty major part of Facebook's Android strategy and that means that this framework is going to be pretty well supported. One last as I see the Titanium code Titanium framework code we write two different you know we write differentiate Android and iOS code for example in notification we use GCM and we use post notification. So do we do the similar way of functioning in React.js as well? Right because you know you want the Android users to get the Android experience you want the iOS users to get the iOS experience. So you will still write iOS specific code for iOS and Android specific code for Android but the difference is that it is now in the using the same framework and the same language. So it's not like one is Java and the other is Objective-C and entirely different concepts. The same concept the only difference comes that the names of the views will change. So in Android you'll have a different name and an equivalent thing on iOS will have a different name. It means is the person still need to have some information of related to Android and iOS as well? Of course of course because you want to give that experience right. So you need to know how that looks like. So yeah but you don't need to have a lot of so you don't need to learn a whole new framework and whole new language right for developing on iOS. You can just so 80 to 90 percent of your logic you can keep the same. Only the view parts will have some changes. So in that way it is better. I'm afraid again we are running out of time. So that's about it for in short this talk.