Fernando Rojo – React Native 2030 | App.js Conf

where are we now and where are we going our lists are slow and our images flicker our keyboards cover our inputs and our inputs can't format text we can't use multiple modals and we can't put toasts on top of modals we can't use modern CSS our shadows barely work it's hard to do shared element Transitions and I don't know how to use native code if you've been a react native developer

facing these issues is almost a Rite of Passage but little by little people stepped up and donated their free time to solve many of react natives fundamental shortcomings as you can see in the past year react native's feature set has increased dramatically and many of these features have come from the community rather than react native itself and all this has made me wonder what would react native look like in its perfect form if we didn't have to accept

any of these issues as the way things are so let's travel through time to 2030 and explore what the future could look like through every release along the way my plan is to introduce these and see what the next years will look like and it might come in 2030 or maybe a little bit sooner and what better place to start than with Native modules what sets react native apart is the fact that you can use JavaScript to express truly native UI and since this is such a big selling point

it's important that we have really simple ways of interacting with native code otherwise you end up with a very minor subset of features and it becomes a bit of a false promise in the past year writing native modules has gotten a lot easier with the introduction of Expo modules I was able to write my own module with the help of chat GPT in just a few hours called burnt and even though it's very simple it gave me a lot of insight into what the experience is writing native code today with react native

this is what it looks like to do it today first you have separate code in your IOS and Android folders where you have your Swift and kotlin files respectively every time you make Native changes you have to rebuild your native app and restart the dev server to get it running next you have to import your native code using this function called require native module and lastly if you want to add typescript types you just have to manually cast it on top of them now this is pretty good if you ever try to write a native module without Expo

modules you know that the list is a lot longer but in the future it'll be even easier with the introduction of inline native modules notice that I'm importing burnt from a switch file and I can call its functions with types right in my JavaScript code with inline native modules you can suddenly import Swift and cotton files right alongside your react code you don't need separate folders it lives

right in the same place and while it doesn't technically use fast refresh whenever you update a native file your native app will automatically recompile and it'll be so fast that it feels like Fast refresh now probably my favorite part is the automatic typescript types using AST parsers for Swift and kotlin we can read in what the types are and automatically cast them and using typescript declaration merging we can apply these files with their types and all this will work without any additional setup

so if you're building a library that just needs one native file or if you have a ton of native files in your app all you need to do is write it import it and you're good to go so how do we deal with platform inconsistencies after all this is only showing a switch file and what happens here on Android turns out this will be pretty easy you can import your Swift and Android code separately and here I'm using platform select but you could use any of the different platform methods to do this and what's cool is this won't error on either platform on iOS the kotlin file will be tree