Todd Werth:

Welcome back to React Native Radio Podcast, episode 3 45 Expo SDK 54.

Mazen Chami:

Welcome back everyone to React Native Radio. I'm Mazen joined by Tyler and Frank and we are React Native Radio. Today we're going to jump right into our topic. This is a part two of our React Native 81 episode, and this one will be covering Expo SDK 54 because they tend to go hand in hand and I think most people wait for Expo to release their SDK before upgrading their React native version, at least for most of our clients. I could say that. Before we get into our topic, let's hear from our sponsor. Infant Red is a Premier React native consultancy located fully remote in the us. We're a team of 30 senior plus level React native developers and support staff and have been doing this for nearly a decade. If you're looking for React native expertise for your next project, hit us up at Infinite Red slash Radio.

Don't forget to mention that you heard about us through the React Native Radio podcast. Okay, let's get into our topic Expo SDK 54. This one is going to be hand in hand with our React native 81 episode like I mentioned earlier. So I think there's going to be some parts where we refer our listeners to the previous episode, but we will still cover some specific topics like the first one I'm going to ask Tyler to dive into, even though it's the same topic as the first episode, expo did some changes of their own to this topic. So Tyler, what's our first topic?

Tyler Williams:

Yeah, like you said, this is a really good bridge from the prior episode, so if you're just coming from that, this will feel a little familiar and we won't get too deep into the details on this, but Expo has also enabled the pre-compiled React native dependency for iOS builds. So like we talked about on the prior episode, it basically makes your build process faster and less error prone on iOS. It's a huge win. I think a lot of people are going to be super happy with it. I know I've already played around with it and I miss it on projects that don't have it. I've only gotten to sort of toy around with it on demo projects, but Expo is all in on this change, so their pre-build template works with it. This setting, I think they've kind of changed it a little bit, but as far as I can tell from the current state of things and the beta, the setting will be on by default.

So if you end up in Expo SDK 54, especially if you're starting a new project, you'll just notice your iOS builder much faster than they would be. We mentioned in the last project that you can't debug with these prebuilt binaries or you can't debug the React native source code specifically. So there is an option to build from source and this is something that you'll have to in expo, you'll have to drive that with the expo build properties config plugin, and they have some syntax. It's just build React native from source. It's actually really nice. It was a great, when Frank and I were messing around with this in Ignite, we wanted to run a bunch of tests and benchmarks and it's actually really nice just to toggle a value instead of messing with environment variables and stuff. So this is another, I think this is a good thing to start on because it demonstrates the way that Expo takes cool React native innovation and wraps around nice developer experience.

So pre-compiled React native, same thing as React Native 81 release, but just a little nicer to use here in Expo SD SDK 54. We'll also probably link a blog post where Expo wrote about this and something just sort of like a sneak preview here is Expo mentions in that blog post, and some people might remember it, they used to do this same pre-packaging of the expo dependencies. They moved away from it for a handful of reasons, but now that Meta is doing it with React, native expo is expecting other third party packages to start bundling and shipping these prebuilt binaries and it sounds like they're going to plan on doing it too. So I think overall we can expect more and more packages including expo packages to start sending pre-compiled binaries and improving everyone's build times in a really dramatic way.

Mazen Chami:

Yeah, that's pretty cool. And like you said, improving build times is the objective and goal here. So pre-compiled does help and thanks for mentioning that blog post. I do remember, I think we mentioned it on the radio a while ago where they were doing this to help speed things up because if you think Expo Go is almost like a pre-compiled binary in sorts, it has all the expo packages built into one and set up that way for you so that you can run something quickly on the fly and get your answer. So for example, the other day I actually ped Frank and I was like, Hey, I want to test this I 18 N thing, but my machine's not set up right now. I don't have Ignite, I don't have Ignite on my client laptop right now. Any chance you have this setup. And as we were talking, I was like, I wish we had an Ignite Expo go that way. I can just do this on the fly and get it done quickly without having to set up my machine to manage that.

Tyler Williams:

And I think in a lot of ways the more packages that pre-compiled, the more and more people's experiences setting up React native native builds are going to feel like Expo go and that's good because at this point Expo go is still a really valuable tool, but I know that in general development clients are more useful for the long term. So anything we can do to get people in that workflow earlier but still having those sort of same speed pickups is going to really again improve both the developer experience and just everyone's the longevity of their projects.

Mazen Chami:

The next one's actually one that I want to highlight because it's something that I've been doing for a while now. Frank, you're on Android, right?

Tyler Williams:

Yes.

Mazen Chami:

And Tyler, you are?

Tyler Williams:

I'm an iOS person now. I used to be Android.

Mazen Chami:

I was going to say I do remember you carrying an Android run. Okay, cool. So I kind of was like, I'll pick this topic up. I'm talking to two Android guys, so whatever they won't know about this one, but Tyler you do. Are you on the iOS 26 beta or no,

Tyler Williams:

I'm not. Again, I'm a new iOS person, so I'm taking it real slow. I'm not in the betas, I'm just learning. Oh, it's so funny. My wife has been in the iOS ecosystem forever and so when I first got on my phone I was like, how do I clear all my apps? Because on Android you can open up all the processes and you clear them all. That's the thing that you should do on Android, you should not do that on iOS. The operating system handles all that for you. She's like, what are you talking? She's like, why would you do this? And I was like, oh, because I want to free up the ram, I don't know, it'll make my phone go faster. She's like, no, that won't F it at all. But for a few weeks I still did it. I would just manually do the task switcher and go, I still do

Mazen Chami:

That. I love that. I dunno. It's satisfying. Yeah,

Tyler Williams:

Yeah. Anyway, so no, I'm not on iOS 26 yet. I am just getting into the ecosystem. I'm just learning it, so I'm trying to keep it a little basic for a bit.

Mazen Chami:

I usually jump on the bandwagon the day it's announced. So iOS 18, which is the current one, 17 and 16. I did join the beta from Beta zero. That's cool. I was 26. I did jump on the beta itself too. I believe now they're on beta nine, if I'm not mistaken. It was just the other day. It has come a long way.

Oh yeah, a long way. Beta zero was rough. I mean it got to the point where I almost didn't use want to use my phone and oddly enough, well not oddly enough, but funny enough talking about your wife helping my wife grab my phone and she's like, yeah, no, and just put it down. She's like, what is this? As we all know, iOS 26 comes with Liquid Glass, a whole change to the visual layout of iOS. So Expo SDK 54 does bring in liquid glass icon support, which is pretty cool. I know Beto has a video on how you can do this to have your bottom nav tab look like liquid glass. Not a lot of apps do this currently other than the native iOS related ones. So you kind of be on the edge bleeding edge there if you're using Expo ui, which some components are strictly iOS Expo UI for iOS, which is still in beta includes liquid glass support out the box. So you're getting free liquid glass support by using Expo ui, which I think everyone should kind of use. And just the last point here, if you want to use start using iOS 26, which I think you should because by the time this episode comes out, I think the full release will be out. EAS also gives you access to EXCO 26 beta support, so you could do builds that way on EAS.

Tyler Williams:

As a side note, I really like the new numbering system for iOS going to 26, which I think is the suffix of the 2026 year number, which I know that some c plus plus does. That C plus plus suffers from having a c plus plus 99, which comes before the like c plus plus 17, which can be confusing, but I think for iOS jumping from going from where they were before to 26 in 2026 gives them a long lead time of updates where the incrementing number will only be useful and meaningful. So I'm excited about that Nomen nomenclature change.

Frank Calise:

Do you think in the year 3000 when it would flip, do you think we're going to see how clothes come back in style? Like liquid glass will be gone and the old stuff will come back?

Mazen Chami:

Think we'll see. Will we be using phones at that point or will it be

Frank Calise:

Chips? Yeah, I don't know. I just hope I don't get spam calls to my head. That'd be fantastic. Alright, next up is the updates for React native for Android. They're now targeting Android 16, which is API 36. So you can check out part one the prior episode to this for more details, but Expo piggyback off of Meta here, edge to Edge is now always enabled by default, which if you've been using that SDK for the last few versions, you've been aware that you could opt in very easily. Matthew AKA Zoom Tech did a lot of fantastic work there. I think first with Expo or very early on, he built this React native Edge to edge, brought it up upstream to expo packages in status bar and then now it's been since pushed upstream to React native itself. So if you need to configure those navigation bars properly, look into the documentation on that for your Android applications.

Also introduced in this SDK is the predictive back gesture, which when it was first announced in the beta it was enabled by default, but they've since gone back on that and you have to opt in now and the reason for that is at this time React Native screens doesn't quite support it. So if you want to opt into that and check it out, you can configure your app config with the predictive back gesture enabled key under the Android paring key there. And this is the navigation change where we're going from the hardware back button to, there's a small gesture as you swipe from the edge of your screen. For me it's the left side, but I guess in RTL world, right zen, you would go from the right and that just gets you going backwards in your navigation stack.

Tyler Williams:

Frank, as mentioned, I've been out of the Android ecosystem for a little bit of time now, so I've missed this one. Are you seeing this show up in other apps that are likely just full native Android? Are you starting to feel the ecosystem move into this?

Frank Calise:

I've been using this back juster pretty early on. I think either I opted in or because I'm on the pixels all the time, it was one of the early betas that I got into it and it felt so weird at first coming from the harbor backs and stuff, but I really like it now. It feels smooth. I don't know, I grab my wife's iPhone and I don't know how to go back anymore or she used my phone, where's the back button? I'm like, just go back, just swipe. So it's feeling pretty natural because we swipe up and down all the time, so why not left right

Tyler Williams:

Kind of thing. Left, left and right.

Frank Calise:

Yeah.

Tyler Williams:

Yeah.

Frank Calise:

And then the final update to Android 16 very quickly is the 16 KB page size compliance. So that was in React native previously, but if you haven't updated in some time, I think you need to get to 77 if that's correct, your app will be compliant, but if you're behind, you want to think about that day cutoff sometime in November I believe. So check your emails from Google Play Store and you'll want to upgrade your app and get a new binary published.

Tyler Williams:

This change primarily it just makes overall apps faster, right? That's the idea is that IT idea gives the phone processor the ability to address RAM or page out the RAM it needs in larger chunks than the 4K.

Frank Calise:

Yeah, I believe so. I am not sure how it's going to act on older devices all their Androids, right? Typically the problem when it comes to React native apps, I don't know if this will help that or if they're just not capable either way and this is more of like a newer device feature in a way. But yeah, it'd be interesting to see how in your development if things feel more snappy now on device, I'm sure emulators are not going to get any faster when it comes to the Android emulation, right? Yeah. Next up in the change log expo updates and EAS update, these are some pretty exciting changes that remove a barrier that we used to have when using over the air updates previously. So the first bullet point is the HTTP headers update sends channel information and that can now be overridden at rum time with the updates that set update request headers override call, which is pretty cool. So I think Tyler, you mentioned you had some experience where you needed something like this and now you have it.

Tyler Williams:

Yeah, I'm stoked. We ended up taking a different approach as is the way that software often goes when you don't have what you need. Our plan was we were doing maestro tests on individual prs with our client and we wanted to test the most up-to-date JavaScript bundle if we could and avoid building natively if we could. So our plan was an EAS workflows and I wrote a blog post about this, which is now totally obsolete for reasons I'll get into the plan was to reuse native builds if they match the fingerprint dynamically, build EAS update channels based on branch names and then pull the latest from the last push and load those up. So this works really well if you're trying to do that kind of flow in a development client because development clients can swap dynamically all the time used to be and that used to be the easiest way to do it.

But when you're running misho tests, you want to make sure that you run in release mode because if you run in debug builds, the misho tests are so slow that they always flake out. So we swapped a release mode and we couldn't dynamically change the EAS update channel that we were on without. There were a couple steps, there were essentially a couple of hacks that you could do to do this. You had to opt into a particular option that was very scary and tough to get past code review with people who weren't as familiar with it because it was like disable anti bricking measures was the name of the configuration option and just submitting a PR that's like, Hey, I'd like to disable our anti bricking measures was didn't always sail through. But once we got there, the other thing was that you had to fully quit and restart the app, which in maestro, the iOS command kill app does not do the full thing that Expo is looking for here. So this change is really exciting to me in a world where if we were still looking for that kind of solution, I would love to use this. I think there's also practical use cases if you want to send release builds to stakeholders at your company, but give them the option to switch over to different EAS channels so you're sending fast builds because you don't want to send the CEOA debug build that's slow

Frank Calise:

Because

Tyler Williams:

You don't want to spend time explaining why this is slow, but the users are going to get won't be slow. So now you can send this out to stakeholders, swap to different preview channels. It's awesome. I'm stoked on this. We ended up, for my use case, we updated the blog post EAS workflows, shipped that really cool repack job and now they have a whole bunch of pre-build steps that use Expo repack to do the repacking based on your JavaScript changes per branch in EAS workflows. So actually a little bit nicer than the updates workflow, but I was looking for this a while ago and I'm glad it's here.

Frank Calise:

And as you mentioned, yeah, so you don't need to restart the application anymore for this new configuration to take effect. So that means after you make this call to update the headers, you can call your updates fetch, update async, reload async, and it'll send those new headers along for the ride. So I imagine you could use this for, maybe you want to provide, we're talking about liquid glass and beta stuff. Maybe you want to provide a beta opt-in for your user base and there could be a button somewhere deep down on the menus where it's like, Hey, yeah, I realized risk, I want to jump into this. And you switch up the release channel they're getting their latest and greatest from. So that's pretty cool. Another update here for the use updates hook, it now includes a download Progress property. So it lets you track the progress of the asset download during an update so you can show status bars, give the user an idea when things are going to finish up and just have that better UX feel.

And finally they've also updated Reload Async, which will accept an object for reload screen options. And this can give you some control over what's presented while your app is reloading, which is really nice because it used to just kind of flash or flicker quick and look, basically it would be almost like a macro for swiping the app away and bringing it back up and whatnot, but you can have that granularity here visually to be a little bit nicer on the update experience. So these three things I think can really help the users understand what's going on instead of the, oh, I opened my app, things are happening, it restarted, I'm looking at a different screen, that sort of thing. So you can really smooth out that experience.

Tyler Williams:

There's not a smooth transition between that idea and the next one, so I won't even try. The next item on our list is about expo auto linking. So up until now, expo auto linking. So this is where you take native dependencies and get them sort of talking between the native layer and the JavaScript layer. So some dependencies are JavaScript only. They just get bundled and run via Hermes. Others have native dependencies and those need to get linked differently for Android, iOS. Different platforms typically in React native and we have a blog post about this dependencies that have transitive dependencies don't get auto linked when they are native transitive dependencies. The reason for this is that NPM is what is called a nested dependency manager, which means that it has ways to duplicate dependencies and figure out what should be linked up where, whereas native dependency managers like Gradle and Cocoa Pods, swift Package Manager, they're flat dependency managers, so they need to be deduped.

So these are two just totally different models. And a long time ago the React native community CLI made the decision to just not support transitive dependencies because there were so many complications that would lead to native modules getting registered twice, which was a huge problem at runtime. So expo through their expo module system has had a way for a while to auto link transitive dependencies that were other expo modules. This didn't work for non expo modules in expo CK 54. That promise has been expanded. Phil from Expo has a really, really great article about this and the reason I know some of those details I've just got into was because I've read it like three or four times, I highly recommend it. This is something that has been I think a real stumbling block in the React native ecosystem for quite some time. And I think this sort of change, I think it won't be as flashy as pre-compiled binaries, but I do think that this is going to be one of those things that continues to build up Expo as the defacto way of building React native apps because what it's really doing in my estimation is it's taking a JavaScript ecosystem expectation and managing to map it back onto native ecosystems.

It's a really difficult challenge. I think they nailed it here right now as of recording, I think there's still a couple bugs in this. There's an open PR to fix it. So if you're on the beta, you may not have noticed this working as nicely, but if you are listening in a few weeks from when we record, when we actually publish, I'm sure it'll be smoothed out by then. And so to give a practical example that people will be familiar with, so if you've ever installed React native reanimated, you probably recall that reanimated has a handful, two or three other things you need to like yarn at or NPM install alongside it, which is different than a JavaScript only package that says, Hey, you install this package and then we'll define all the things we need. So what's happening is Reanimated is defining peer dependencies that the consumer must provide because they want you the consumer to only provide it once, but that puts all of the responsibility of managing that dependency on you and then you have to upgrade it separately.

You have to make sure you have it. It just runs into all these sorts of problems. This change will allow packages on NPM that have native dependencies to simply define their transitive dependencies and then you can just install the first one that you're trying to go into and get what you need based on their dependency list, which is again, sort of the promise of NPM and the way that that works. So this is super cool. I'm just really excited about it. I do think it's worth noting that it will cause some drift between people using Expo and the React native community CLI, because they'll just work very differently. So there's going to be a little bit of churn here. Hopefully people listen to this podcast episode, keep that in mind.

Frank Calise:

I was going to mention, hey, there's free PRS out there to delete step two of every how to get started on a third party library, but it's going to have to remain with this whole, are you using Expo or you're not? Anyway, so nevermind.

Tyler Williams:

Yeah, the divide grows there a little bit, but I think it's worth it, but that's because I use Expo pretty much everywhere and I think it's also a good forcing function for more real conversations in the community about where do we want to take React native in one direction. Right.

Mazen Chami:

Awesome. Yeah, thank you guys for that recap. The next item on the list is Expo SDK 54 is the final release that'll include the legacy architecture support. So if we all remember in React native 80, the team at Meta introduced a code freeze for the legacy architecture work and then they also announced that React native 82. So the next version that's coming out potentially by the end of the year,

Frank Calise:

I think November,

Mazen Chami:

November will no longer, you will no longer be able to opt out of the new architecture or rather the architecture. So it's either the architecture or the legacy architecture, let's just put it that way. There's no new architecture anymore. So React native 82. So by the end of the year, if you upgrade to the latest version of React native, you will no longer be able to opt out of the architecture and go back to the legacy architecture, which we can assume means Expo 55 will only support the architecture. So I think you see what I did there. There

Tyler Williams:

Can only be one.

Mazen Chami:

There can only be one. Moving forward to 2026 is when we go to 1.0,

Frank Calise:

We'll have RN and RNL Legacy.

Mazen Chami:

Legacy, yeah, someone will create a fork for the legacy architecture, I guess

Tyler Williams:

It's like wow, classic.

Frank Calise:

They'll immediately name it 1.0.

Mazen Chami:

Okay, so I'm going to do a speed roundup here of the remaining items since we're getting close to time. S SDK 54 includes React native 81 like we've mentioned and React 19.1. We're not going to dig into that. We discussed it in the previous episode in depth, so we can go back and listen to that. Expo. SQL Light now includes a drop in implementation for local storage web API cross-platform development here. So hopefully one package can kind of rule all of them for us. Apple and Android TV updates are also included in here, so making that experience much cleaner and tighter Expo CLI better stack traces finally read those stack traces and know exactly what's happening and be able to kind of trace back to them. I mean that's big. I mentioned in episode one we're getting much, much better with that. React compiler is now enabled by default in the template for the expos dk, and then there's also a bunch of expo router updates. Evan Bacon is doing a lot of good work there with all that, everything else we mentioned in the last episode as far as breaking changes, deprecation, all that, that still applies here, so keep that in mind. And then last one is Prebuilt template is now included in the expo package rather than needing to download it from MPN.

Frank Calise:

Yeah, this is a cool one because personally on a client project, we ran into this issue where the registry they wanted to use for MPM was private and some of the commands, you're just following the documentation on expo, the template's just not there. The Repository's not there in the private one. So there are ways to download it and read it from a zip or tar file and all that, but it's nice that this will come along for the ride in the actual expo package.

Mazen Chami:

For our listeners that aren't familiar with it, what is the pre-built template and why is it important?

Frank Calise:

Yeah, so the pre-built template would be when you spin up your new project and you need to generate your Android and iOS directories and those specific Android and Excode projects under the hood. This is the skeleton files that Expo is saying, Hey, here's what those NATO files should look like for this specific version of React native and the expo SDK. And they have templates of all these for all the versions and they change over time. So in the CNG world, continuous native generation, you reach for this pretty often. This keeps you from having to manually touch these native files between React native upgrades, which has been amazing. If you are not doing it, you that's like another mind blowing thing like faster bill times, you should check it out and now this pre-built template in the expo package will help alleviate some pain points with private registries and I'm sure a few other notes there.

Tyler Williams:

I think supporting private registries like that is a huge step forward for expo and enterprise readiness. Definitely. This is something we've seen a lot this last year is that I think Expo and React native are really stepping up ready for the big time at enterprises and private registries that are one of those big hurdles to getting things going. So I'm excited about this one.

Mazen Chami:

I think this takes me back to a tweet Evan Bacon had yesterday, September 3rd. Main thing we heard from Enterprises is that we're trying to add Expo to a Brownfield project was that they need prebuilt React native XC frameworks. We invested heavily in making this a reality for their entire React native ecosystem for expo SDK 54 integration guides coming soon. So Expo is no longer just for the hobbyist or the one app person or the smaller teams,

Frank Calise:

Right? Or the Greenfield startup.

Mazen Chami:

Exactly. It is now also enterprise ready, so there's no more being like, oh, I'm a large, large Fortune 500 company and Brownfield app. I don't want to do full React native and I would love the benefits of Expo, but it doesn't work. That's no longer a thing, right? This seems to be a trend in React native in our industry where there's always someone that comes up and say, but if fall short here for me, no more of that, those gaps, no more of that, right? Those gaps are being plugged in all over, even on the enterprise level, A level that you would think like why go that high? Just start low and do all that. Those are blocked off now. It's just like, Hey, let's get the enterprise in the Brownfield in, let's make that experience better because making that enterprise and Brownfield experience better helps us when we're building apps feel very native because it's that much easier for the non enterprise and non Brownfield apps to dig into the native side and do the native stuff that needs to happen, right? Jamon had a little talk about it where we shouldn't be afraid of going into Native to build our applications, right? It is React native, react native for a reason. So don't be afraid to do that and Expo makes it easy for us to do that if we need to. Cool. And Frank Tyler, I assume the work you all have been doing that we talked about in the previous episode on getting Ignite upgraded to React 81 also includes Expo 54, is that correct?

Frank Calise:

Yes, sir.

Mazen Chami:

Awesome. So that will be out soon and I think all our listeners can get to check all that goodness out and thank you guys for coming on. I really appreciate it. This was a lot of fun going through these two new episodes and for our listeners, I hope you like this new host layout. It'll be me and a mix of Frank and Tyler for potentially the rest of the year. Jamon might come on in a couple episodes for me. They're taking a little break from the podcast. I want to close off by saying if you haven't booked your tickets to Chain React, this is another call to action chain react comp.com. Please do that. We'd love to see you all there, and we'll be doing workshops, talks, making announcements. We're co-hosting this one with Expo, so that's going to be a major event that's happening over in Portland again and again, subscribe to our YouTube channel for more episodes from me on the React native mornings side. I will be, again, like I'd mentioned, this episode might not be out by then, but I'll be talking to a lot of industry people from Expo. We did one with Maestro and hopefully other people out there I'll have on the show. Reach out and let us know if you have any topics that you'd like me to cover in that or even on this show too. Awesome. Thank you all for your time and we'll see you all next time.

Todd Werth:

As always, thanks to our editor, Todd Werth, our assistant editors, Jed Bartausky and Tyler Williams, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.