Deploy Everywhere with Expo Router

All right. When I first discovered Exponent, the original name for ExpoGo, in 2017, I was amazed by the ability to quickly create beautiful mobile prototypes and then share them worldwide in an instant. Coming from a Swift background, I was used to spending weeks building an interaction just to share screenshots online. So I instantly fell in love with the idea of launching apps in minutes instead of months. Exponent pioneered tech like scanning a QR code to instantly launch a native app, but there were some limitations.

You needed to eject to add custom native code, the binaries were very large, and the tooling was very limited. So while it was at the forefront of app distribution, there were still a number of ways it could improve. The Exponent was essentially a prototype of what software should look and feel like. It should be instant and shareable with URLs and cross-platform like the web, but with the beauty and unlimited potential of a mobile app.

So I dropped everything in my life to join the expo team and turn this vision of the future into a reality, and today I'm going to show you how far we've come and where expo is going. So the first step was to make expo more than just a prototyping tool. To do this, we needed to remove all limitations and allow for any custom native code to be used. Expo apps are composed of two parts. There's the native runtime that works like a high-powered browser and the JavaScript layer which works like a modern React website.

In the original Exponent prototype, the native runtime was a single binary and the JavaScript layer would be swapped out for each build. This means no custom native code could be included, only the JS was mutable. Very similar to a browser. So to solve for this, we created a system where the native runtime would be automatically generated based on the React runtime. This meant you could progressively embrace native code instead of having to jump into Xcode and Android Studio headfirst. And the system is called continuous native generation, or CNG for short.

CNG simultaneously solved many of the biggest problems with both Expo and React Native, but most notably, upgrading projects became as simple as bumping the node modules and running Expo pre-build. Expo CNG changed everything, because it meant there were no limits and no compromises on the development velocity. You could use any native code you want and enjoy all the benefits of Expo. Because Expo apps are truly native, they have day one access to all the new platform features, like Apple's new Liquid Glass design language, with no code changes required. So you get all the beautiful native elements, just day one, built into the platform.

CNG enables you to push the native platform to its maximum potential. Just recently I released MPX create target, which enables you to easily add Apple home screen widgets, share extensions and app clips, live activities and more, to your iOS app. I used MPX create target to add an app clip to my game Pillar Valley, enabling users to instantly open the app from a URL, just like the web. This is great, because people can immediately experience the native app as it was intended to be used, with beautiful shaders and custom haptics during gameplay. And then you can download the app right inside of the app without ever having to visit the app store. So this very seamless experience.

And then you can download the app right inside of the app without ever having to visit the app store. So this very seamless experience. And after we overhauled the native runtime, it was clear that the next step was to make the React framework best in class two. React native primarily focused on the native aspects of the developer experience. So things like bootstrapping a project, which are instant on the web, would take minutes on native. Bundling would take 30 seconds to a minute, and it was easier to start over with TypeScript than it was to add it to an existing project. This is why I created Expo for web.

We had a dedicated target that focused solely on solving these issues universally and pushing the React framework to its limits. Expo for web powers everything from the massive social network BlueSky to my personal favorite website BK.com. I am an American and I love this website. These are universal apps that run not only on the web, but natively on mobile devices. They prove that with Expo, you can really write once and run everywhere. Expo for web is high-powered, enabling SEO, all modern CSS tooling, and React 19 features like React compiler and React server components. Additionally, Expo for web has radically improved Expo for native and React native as a whole, with many features that were written once for the web and work everywhere.

My personal favorites from our most recent Expo release, Expo DOM components where you simply mark files with use DOM to render them inside an optimised web view. We will cover this a little bit more in a moment. We rewrote the error logging to create human-readable messages when you get a React error. Just understand this is an acceptable error message for a native developer. This is what you would expect to see from a web framework. You can see the benefit of supporting both web and native. We even went as far as adding HMR to environment variables so you don't need to reset the dev server to see changes.

Setting our standards with React native as high as the web is what makes Expo feel so much better than traditional native tools, but perhaps the most important feature that we got by embracing the web is file-based routing. Since its inception, the web has had the most intuitive routing system, where every file in a hosted directory was linkable with URLs. This system withstood the test of time and proved to be the most human-centric way to define navigation, which is why I created Expo Router, the first universal file-based routing system for native and web at the same time.

With Expo Router, routes are defined by simply creating files in the app directory. Expo Router also completely solves entire categories of issues, such as deep linking and type safety. In Expo Router, all routes are fully linkable by default, which is not standard in a native app, there's really no other way to achieve that, and everything is completely type safe, which is awesome. TypeScript is pretty badass. So even though Expo Router is fairly new, it already powers many fantastic apps.

I found almost 100 in the iOS trending list already, including Partiful, which just won Google Play's app of the year award. We recently introduced Expo DOM components, which enable you to incrementally migrate from web-only React to universal React apps. You simply mark components with Use DOM to render them inside of an optimized web view. Additionally, native APIs, like notifications, haptics, and anything you want, can be called from the DOM component by simply passing function props to the component.

Here, I'll comment over it. They're like, oh my god, Partiful is amazing! This is the best app of the year! Congratulations on getting this award. That is the number one app in the Android Play store this year, built with Expo Router. It's not just helping you achieve the best, it's defining what the best is possible of.

I want to talk a little bit about incremental migration. All of this is awesome, but it's a whole new framework, we all have jobs. The web is a fantastic way to quickly discover product market fit and prototype an idea. But today, people are spending the majority of their time in mobile apps. So many fantastic websites exist today, and if you already have a powerful, beautiful website, responsive, you've optimized it, you found some product market fit, you shouldn't have to throw it away and start from scratch to reach mobile users.

And with Expo, you don't have to. We recently introduced Expo DOM components, which enable you to incrementally migrate from web-only React to universal React apps. You simply mark components with Use DOM to render them inside of an optimized web view. These components essentially run as mini Expo websites. You can move the Use DOM directive around to incrementally migrate entire sections of your website over to a beautiful, universal app. Let's see, what do we got here? Additionally, native APIs, like notifications, haptics, and anything you want, can be called from the DOM component by simply passing function props to the component. So we have this magic serial bridge where it takes the prop and then it interrupts it over, back and forth between the bridge. So it all feels very first-class to React. A great example here, let's see, I can get a little notification animation there.

So you can easily bind native APIs, like for example, Apple's new foundation models, to use offline LLMs for free in just a couple of lines. So here, I just built this yesterday where I'm using Apple's new offline LLM models where you can just prompt the model running on your phone, and then I'm rendering all this code here inside of a DOM component, essentially a web view. But I'm able to bind it from Swift and then call it in a single line from JavaScript, which is super fun.

And then I don't have to, I can just take my existing... Like imagine you do all this, but then it's like, oh my god, I have to write a code editor and get all the right styling, and it's like, nonsense. Here we're able to combine native, React native, and React DOM all in a single first-class pass. It's pretty sweet. But perhaps the best part of DOM components is that they work out of the box with less than zero config. A modern website requires tons of bundler functionality to work. And DOM components are no different.

I built a demo app to demonstrate migrating stock Shad CN blocks and templates over to mobile using beautiful native navigation, so you can try it yourself here to see how it feels and get a sense for how great we were able to make WebViews feel. But building beautiful front ends is only half the battle. If you really want to make an impact, you need to connect those front ends to a server. On native, this can be extremely difficult, which leads to apps that look far better than they function. A good example of this is Apple's intelligence, which looks incredible, but is mostly completely useless.

If you really want to make an impact, you need to connect those front ends to a server. On native, this can be extremely difficult, which leads to apps that look far better than they function. A good example of this is Apple's intelligence, which looks incredible, but is mostly completely useless. So that's why we created the Expo server platform. The server platform consists of environment variables for securely storing secrets that are never exposed to the client, API routes for building stable serverless endpoints using best practices, modern APIs, and React server functions for building type-safe functions that are capable of server rendering and streaming views to all platforms.

Native and web, everything here is completely universal, and it may look extremely familiar because it's all based on existing web APIs. And to top it off, we just introduced EAS hosting to streamline the production deployment of websites, server functions, and static assets with a single command, EAS deploy, which was down yesterday because build on CloudFlare. So EAS hosting enables realtime metrics for popular routes to help you better understand how much of your app is being used and on which platforms. This also includes detailed error information by default for all server errors.

For example, I have an AI chatbot app, and I can see here that sometimes it hits errors when it's called from a particular country or region. If we dig in a little bit deeper, we can see that these errors are originating from Hong Kong, and then we can see that OpenAI is disallowing requests to this region, which is extremely valuable. Inside of a native app, you really don't have the same kind of visibility as you do in a website. You can't just pop the console and see console errors. So I may not have ever really discovered this otherwise. And by simply using the Expo server platform, we now get actionable insights about how to fix our app and build the highest quality products with no extra setup.

The entire server platform was used to create this AI chatbot app, which I actually demoed last year. It was bad ass. It wasn't as hot in the conference hall either. And we can use it to render complex, interactive native views and stream them down to the client. I open sourced this entire project. It's on my GitHub, so you can clone it, build your own full stack chatbot app for both mobile and web.

The composability of the server platform means you can create robust, reusable full stack components. To demonstrate this, I split the movies card from my AI app into its own app, where you could get more information on a given movie or actors by simply tapping on them and moving between pages with server components. We're able to bundle the server and client logic together, making this extremely easy. And I love the idea of opening movie details so much that I pulled the entire movies app back into my AI app to create sort of an AI super app.

Putting these tools together not only creates the most powerful universal full stack framework ever built, but it enables you to solve real-world problems. So to prove this, I looked at a real-world problem that I was facing when building all these apps, and that is shipping them to users through the app store. On web, we simply run EAS deploy and we can get a link to share the website with anyone instantly. It's the gold standard. Web really has deployment cracked. So how do we bring this gold standard to native? Deployment to the Apple app store is painfully difficult, and there's really no way around it.

Just recently when the Apple tax was removed in America, I was able to build and deploy a full stack app with custom payments in just a couple of minutes to build native and web. This was then approved for external testing in 30 minutes, which means it was available to 10,000 users with the URL. Pretty bonkers. The Expo server platform makes the boundary between server and client just melt away, enabling you to seamlessly and securely build full stack applications that are easy to both deploy and maintain. We love using this at Expo and we're building more than ever because of it.

Putting these tools together not only creates the most powerful universal full stack framework ever built, but it enables you to solve real world problems. So to prove this, I looked at a real world problem that I was facing when building all these apps, and that is shipping them to users through the app store. On web, we simply run EAS deploy and we can get a link to share the website with anyone instantly. It's the gold standard. Web really has deployment cracked. So how do we bring this gold standard to native? Deployment to the Apple app store is painfully difficult, and there's really no way around it.

So you have to build the app, sign it, upload it, wait for it to process, and then submit it for review. But with Expo, you can simply run MPX test flight from any computer, Mac, Windows, whatever, and the iOS app will be built, signed, and uploaded to test flight. There's no ad hoc provisioning, expensive computers, UDIDs, or re-signing. You'll just get an email from Apple when the app is ready to download internally. This works great for deploying the app to yourself, but what about every other person? In the app store, reach isn't binary. It's phased. You can painstakingly get to 100 users with no review at all, just an automated binary scan for private APIs to ensure there's no malware.

With test flight review, you can unlock access to 10,000 users over a download link. This can be done in as little as 30 minutes, like I did with the Stripe demo. And finally, you can get to the app store with a complex, full review, a lot of metadata, forms, and you're subject to the highest level of scrutiny. But we do have options.

So I asked myself, if you can get to 100 users with a simple scan, then no review, why aren't more people doing this? And the reason is that getting a user on your team requires a multi-step process and a slow website with multiple communications between you and the potential user. There are so many steps here that if you were to just add a handful of team members, it would be easier to just go through full app review.

A better approach would be if you could split the work across each team member so they could move at their own pace. I know this would be a better approach because I made a prototype using Expo, which I will now attempt to demonstrate. It will be a quick one. The WiFi is a little crazy here and it's hot. So let's just go in here, change our extending type, start mirroring, all right, perfect. The slow website where you deploy an iOS app is this website.

Here I'll give it a quick reload. My favorite part is how you can see it just load in in chunks and layers. And then we can go to an app. And then another page. So it's very slow. You get the idea.

First thing I did was I built a better version of that website with Expo router. Super fast. You can see all my apps. I can come in here and click over to pages. It also has MacOS app. Just click that. Deploy right into the MacOS native version of the app.

I've got my two sections here. I can deploy for my team and I can deploy to the public. A lot of stuff for deploying to the public so I just made it this big, beautiful button. We can just click that. Actually, if I save it, it will pull up my phone number to verify. So let's not do that here. But then on the team, all I have to do, click get invite link. Like that.

It's going to generate this self-service link. And when I open that, let's see, just launch this right here, we get a page like this, which we can give to up to 100 people. I'll just open up a demo version of this real quick, join slash demo. So what happens here is you can deploy your app, you get one of these URLs, and then someone can type in their email address, hit join the beta, and then if they're not on the Apple developer team, then from here, you get this onboarding page where it tells you you're going to get an email. You click into the email, you sign into Apple, now you're on the team, which is way better than having the developer add 100 people.

And then you simply hit join the beta. And just like that, you will now get an email from Apple with the TestFlight download link. So pretty good, not terrible, but we're getting there. We are getting there. We are working our way towards deployments that are as easy as the web.

Let's switch back here real quick. You may have noticed my Mac is on the latest Mac OS version, which is a joy. So I built this prototype entirely in Expo using DOM components for the auth, server functions for interacting with Apple APIs, deep linking for sharing URLs, and I even added a config plugin from the beginning, quick action, so I can just long press the home screen, tap my phone to share access to apps with other people. It's pretty sweet actually. And then I deployed it to the web with EAS deploy and to iOS with MPX TestFlight. So pretty snappy.

So pretty snappy. You can solve real-world issues with real-world tools. With the upcoming improvements to deployment in Expo, I was able to easily publish every single app and website in the presentation today. So you can actually feel the quality of an Expo in a modern React Native app in your hands and not just take my word for it. We have AI, movies, music, payments, DOM components, all of which run on both mobile and in the browser. In just one year, we've added backends, hosting, we've slashed iOS build times in half, and we added direct deployments for TestFlight. So we are moving rapidly to deliver high-quality Native apps to just web developers, people who are trying to create beautiful technology and make the world around them a much better place. We've made incredible progress. The Expo vision of being able to build beautiful, limitless apps that can be shared instantly with anyone is quickly becoming a reality.

If you're interested in working on the bleeding edge of app development with us, come talk to us after the show or reach out to me on X. I've been Evan Bacon. Thank you. First of all, it's amazing. Even I had deja vu because I've watched this talk before. It's still so good seeing all the extra changes. And also, you've had a lot of time to spend editing videos. Like, you've gotten really good at it. Yeah, it's the funny thing about 30-minute increments waiting for apps to be approved. It's the perfect chunk of time to learn how to edit a video. That's awesome. All right. So, let's dive in. Let's jump into them. The first one which has been upvoted the most is by Senay Schoen. Sorry if I'm pronouncing it wrong. Is there an MPX TestFlight variant for internal testing at Android? Yeah. So, MPX TestFlight is a very snappy, cool NPM name. But it is an alias for EAS Build, which is a more comprehensive CLI tool, also by Expo. And it has Android. It has AdHoc.

It has basically every combination you want. The real magic here is the automatic code signing. So, we just look at your code and then we determine what all the network requests are to make to Apple to ensure that the app doesn't fail because of registering your merchant ID or something. Awesome. And also, you talked about the navigation in the app. So, does this mean we don't have stack navigation anymore? And how do people migrate from React to Navigation or React to RouterNet? Great question. So, we developed React Navigation, which is just like API for doing navigation. And then we built Expo Router on top of that. So, all the same primitives. Migration is pretty simple. You mostly are just deleting code and refactoring from this imperative API to a more declarative file-based router system. And what's that like, actually, kind of when you build a feature, like you obsolete a feature you've worked on yourself? Well, I mean, it's still used under the hood there. So, we still develop it. And then it just gives people that freedom. So, if you don't like file-based routing or you don't like the way we've approached it, you can still use the underlying primitive and then build your own system.

We've got a lot of migration questions. But the next one is about migration to Expo from people who are using frameworks like Next.js or Remix. Fantastic question. So, with DOM components, that just came out very recently. This feature enables you to really just take modern web code and migrate it over. So, as a lot of you probably know, a website has more than just rendering to a web view. You also have, you know, data fetching inside of it. So, Expo supports server components and React server actions out of the box. And we also experimentally support them in DOM components. We're still working on that. So, you could take web code that's using server actions, move it over into this market use DOM and then move the requests into a server action. You still get all the same API benefits. So it actually does have a really nice incremental... I did a talk a few months ago.

I did a talk a few months ago. I don't do that many talks. The whole thing was just migrating raw shadc encode over to an Expo app and then deploying it. And it worked. So, it's actually quite a magical experience. Because unlike traditional web view systems where that's the end. If you wanted it to be native, you have to start from scratch. Here you can move the boundary up and start working your way down. You can migrate entire pages one at a time and keep the rest of it as web views. So, the migration story is really clean.

All right. Last one in lightning round. Does Expo support native accessibility features? It depends and maybe there's more context? Yeah, yeah. All the accessibility. I mean, anything you go in, you hit A, you do all of the accessibility ARIA role. Styles come up. Lots of accessibility. We use the native primitives. Unless you turn them off, you're just getting all of the native accessibility built into the device as well. Awesome. Thank you so much.

Remember, if you do have more questions, you can come find him afterwards and let him know. But for now, let us give him a big round of applause. Thanks for joining us on the stage. Yeah.