Video details

React Native EU 2021: Jon Samp - How to iterate on your app faster with Expo

React Native

This talk was presented during the React Native EU 2021 - the largest community conference in the world focused exclusively on React Native.
Abstract:You've got an idea for an app and you've thought through how you'll build it. Now it's time to make your idea a reality. Along your development journey, you'll almost certainly run into complexities when configuring your project, sharing it with your team, submitting it to the app stores, and keeping it updated over time. In this talk, you'll learn how to take your idea from back-of-the-napkin notes to a full-fledged app store app using open source tools and services from Expo.
Bio: Jon Samp is a software developer and designer at Expo. In 2019, Jon built a React Native app named Codecademy Go, which was featured as Apple's App Store App of the Day. Jon enjoys making pour-over coffee, distance running, and hanging out with his partner and their two pets.
Twitter: Github:


This conference is brought to you by Cold Stack, React and React Native development Experts Hello, everyone. My name is John Samp, and I'm a software developer at Expo, and today I want to talk about how to iterate faster. With Expo. I started thinking of this idea because of an app that I use named Tweetbot. This is an app that shows you your Twitter timeline with a nicer design and a bunch of other features that I find really nice and convenient. I've been using this app since the early days and it used to look like this. This design is really something and a relic of pastime, I think, is really cool. I love the SKU Morphic icons, and I like the glow around the different elements, but I know I can confidently say that if I were to ship an app that looked like this today, my users might think it's old or antique. So Tweetbot also had to update the look and feel of their app. If you remember when iOS seven came out, they introduced this design language of really thin line icons and everything being very flat. And so Tweet bot followed suit. And just like that, they also made a very current version of this app that looks a little different, that has some of those same elements from Tweet bot three that has the line icons, but now the icons are a little bit thicker and things still look clean. We've got soft shadows, which is like something that's very InDesign right now. And looking at the spread of these different designs, it got me to realize that Tweetpot has to change to match what its users expect and what the current design, language and philosophy looks like today, and they've really had to iterate a lot. They've had to take these features and change what they look like constantly. This means that the first version of our apps can never be the final version of our apps. It would be so nice just to design something and to build something and have it be done. But that's not really how apps work. They're living. They have to change, and they have to evolve. So to allow our apps to do this, what we really need to do is we must embrace iteration, and we must think about how our apps can change over time to better match what our users want. So let's talk about what iteration looks like in a React native app. Here's what I think it looks like. First you start with requirements, what your app should actually do. After that, there's the implementation of those requirements. Then you review that your implementation actually fits the requirements. Then you would make a build of your app, you'd submit it to app stores, and then once users have it, they're going to tell you things that are wrong and things that could be done better. So you're going to be fixing bugs and adding more features and making new requirements, and then this whole cycle starts over again. So usually we can get this circle spinning somewhat and hopefully at a good clip. But what if we could make this circle go even faster? I think we can do that with tools the Expo provides. So let's start with the first thing in this wheel, which is requirements. And so together today we're going to build an app together, and this app is going to be a coffee app. So let's brew a coffee app together. So let's talk about the requirements we need to implement to make a great coffee app. The first one is we need to know the amount of water we need to the amount of coffee we need when making a pour over coffee. And we can measure that with a scale. Usually a great ratio is 16 to one. So 16 units of water to one unit of coffee. One thing that's kind of hard to do in the morning, especially when you're feeling a little groggy is trying to say, okay, I've got 27 grams of coffee. All right. What is 27 times 16? So I can figure out the amount of water. So that's one problem and one requirement we will have for our coffee app. The second requirement is around pulse pouring. Pulse pouring is pouring a certain amount during a certain duration during the brew, and usually you'll pulse pour three to maybe six times throughout the brewing process. So our app should also count down and guide us through the brew and tell us how much to pour and when. So those are our requirements that we're going to implement today. The next step is implementation of our app. The first thing to implement our app is to start an app. We can do that by installing Expo CLI globally with an MPM installed global command. After we do that, we can run Expo and Net coffee app. This is going to result in a folder structure that looks like this on our computer. On the left you can see the directories, the Expo, and it made. And this is exactly what happens right after running Expo and that we've got an app, TSX file, a few assets, and just a couple of other standard files in our product directory. Notice that there isn't an iOS and an Android folder full of native code. Expo is able to handle that stuff for us, which can make our implementation much simpler and then later down the line. If we need native code or custom native modules, we can always add them. Next up, we want to start our app, which we can do with yarn start and through the prompts, we can open up an Android Emulator and an iOS simulator to let us preview in real time the changes that we're making to our app TSX. Now, one thing that would make this a little bit better. One problem I've had in the past is when I'm developing something in a simulator and then I actually open it on my phone after building it and getting it onto my device. Sometimes it appears a little bit differently, so it would be great if I could actually see the app on my phone right now. And Expo allows us to do this. And to me, this is such a big step and iteration. During development, you can download the Expo Go app, and then when you run the yarn start from the command that we did earlier, you can use your camera app to scan that QR code, which is going to open up your app, a development version of your app inside of Expo Go. Once it's in Expo Go and you make a change to App TSX, you'll see it appear almost instantly on your actual device. What a wonderful way to test the stuff that you're actually using and the stuff that you're actually developing. So I should mention we've been talking about Expo a lot. I work at Expo. So what is Expo exactly? Expo is a company that builds free open source tools and also hosted services that help you build an application with React Native, and it might be helpful to talk about what is React Native exactly. And what is Expo exactly. So here on the left, React Native is a set of component APIs. I think its main job is to render JSX from React into Native views on Android iOS and also the Web. It comes along with a small, unimpinionated core. It's got great third party libraries that you can plug in, but it doesn't come with a lot of the extra stuff you need to build a full application, and that's where Expo comes in. Expo provides a component SDK tools like Expo Go like we just showed you and also services to build, submit and update your app. It is powered by React Native and sits on top of it, and hopefully along with both of these, you can create incredible applications. So at this point we've got some requirements of what we need to build. It's always great to start with a design. I actually spent a while designing what this app could look like, and I went through a lot of different iterations, and I ended up making designs and then implementing them, and this is what they look like. So on the left, I'm implementing requirement number one. I ended up putting a question of how many ounces of coffee would you like to brew first? So you can say maybe I want 24oz. And then below it tells you how much water to heat and how many grams of coffee to grind. On the right. This fulfills requirement number two, which is pulse pouring. Once you tap, start it'll, do a countdown timer and then tell you how many grams of water to pour over your coffee and when throughout the entire brew process. This makes every brew really consistent. And if you can replicate a really great process every time you can wake up with a beautiful cup every morning. Also, when testing this app, it's definitely a Caffeinating process. You could say I was maybe a little bit shaky after all of this. So the next step is how do we review our app now that it's built? How do we make sure that the requirements are actually implemented? This is a problem. I can test it myself and think like, okay, this is looking good, but how can I let my teammates and my colleagues try this if I wanted to do this manually? What I'd probably do is create an ad hoc archive, at least for the iOS side. I would add the allowed devices through the Apple Developer UI, and I would also then build an APK for my Android users. After that, I would have to make builds of my app, and then I would have to distribute them either by giving my team download links or distributing them via the Play Store Internal track or via Test Flight for iOS. But there's a better way to do this, and we can distribute our app faster teammates with this solution, which is called Internal distribution. If we let XBO handle our credentials and the whole process of this and Expo can also build our app, we can distribute it to our team even faster. Let's look at how this works. So the first thing we need to do is install something called EAS CLI, which stands for Expo Application Services. Eis is the services part of Expo that will help set up your app for internal distribution. The next command to run is EIS Device create, and this is going to add a device to your credentials that we will then manage for you. So every time you make a build, you can say, okay, I've set up this device previously, make sure that this build is built for that device that I set up that I actually connected to. The provisioning profile is what it's called. After that, I can run a command called EAS Build Profile internal, and this is going to create two different builds for me that are set up to work with those credentials, which enables me after these builds are done. To do something like this where I can just send a link to someone and say, hey, try my app and then go to this link and then download the app that I just built and they can side load it on their phone. So what this whole process looks like is registering a device, then making a bill and then you can send a link to download. And that makes this whole process much faster and allows people on your team to try your stuff faster. And if you can try something faster, you might try more features. You might try stuff that you wouldn't try before, and this iteration is going to help us make an awesome app. Now we can automate this process even further by setting up a CI action. Expo has something called the Expo GitHub action, and we could make a CI action that looks sort of like this where we set up EAS to build. Every time we merge our code into the main branch, our Expo Action will install our CLI, and we can then install our dependencies and then we can say, let's build for all of our platforms and then also build the internal builds. So every single time someone are just to main, we can go and test our changes. Now there might be an even faster way to test our changes, which is using Expo Go and publishing our app with updates. So how does this work? We can do something called Expo Publish on our app locally. And when that occurs, we build a bundle of all of the JavaScript code and all of the assets in your app, and we make that into an update bundle that is stored on Expo servers. Then when you open up Expo Go, you can see I have this coffee app, and if I click on this thing that says Default right here, it's going to open up that coffee app in Expo Go itself. So anytime I have a change, I can run Expo Publish, and then that change will be visible right here in the app without me needing to download another build. Anyone in your organization that's logged into Expo Go can access that app, which makes it super fast to share the experiences that you're developing. And we can make this even faster just like before by using that same CI action that we showed previously, but this time using Expo Publish. So that makes that iteration cycle super fast. And also after we've tested it with our colleagues and our team means we're ready to build our app for the app stores. So the problem that we want to solve is how can we distribute our apps easily to the app stores? It's all built. Now we've reviewed it. It's ready to go. What steps do we have to take? Hopefully not that many. If we were to do this manually, at least for iOS, we want to enable the app transport security. We'd have to configure the release scheme, and then we'd have to build the app locally for release. And that is a lot of steps and a lot of configuration you have to deal with. Instead, we could use EAS or expose application services to do this for you and your team and in the cloud, which will hopefully make it an even easier process. And one where you don't have to set up everyone's computers identically to make this happen. So let's look at the steps to do this. We can use EAS build and then pass in a profile called Release, which is set up when you run EIS build, and that's going to create two apps for us. One optimized for the iOS App Store and another one for the Android App Store or Google Play. Then on our website we can see some UI where you can see all the bills that have ever been made for your app. You can download that build, and you can also submit that build, which is the next step of the process. If you were to submit manually, we would have to at least for Android, download the AAB file and then open up the Play Store console and drag and drop that thing in there, and then we have to wait for it to upload, make sure that everything is good. Same for iOS. We'd have to download the IPA file, and then we'd probably open up a program like the Transporter app, and then we'd have to drag and drop that in there and wait for it to upload and see if any logs. These are just manual steps that we have to do. You could automate this, but it would take some extra work. So instead EIS provides a command called EIS submit, and we've actually set up this automation for you already. So you don't have to deal with this process yourself, and you can take builds that you've made with EIS and then run EIS submit, and you can say take the latest build that I've built, and then it will take that build and we will submit it to the app stores for you. This is super convenient and makes building and submitting to the stores really quick, and it really speeds up our iteration cycle for those two steps of the iteration process. So our app is now out in the store, and we've actually found a bug. Or let's at least pretend that we did a popular way to brew coffee is using something called an Arrow press. But let's say that instead of writing Arrow Press, we accidentally wrote Sparrow Dress instead. So if I wanted to fix this bug in production, which is a pretty blatant bug, I would need to rebuild my apps. I would need to resubmit them to the app stores, and then I would need to wait for my users to download that new version. Instead, we can use Expo updates to help you provide small fixes between builds like this. So let's look at how this works. Expo Publish ends up making an update, and an update is a bundle of code that's JavaScript and also the assets from our app. So in order to fix the Sparrow address problem, we would go into our app, and then we would fix the Sparrow address to say Arrow Press. Once that code change has been made, we could run a command like Expo Publish and in the command line, you're going to see that it builds the app, at least all of the JavaScript and all the assets into what we would call an update bundle, and then that gets uploaded to Expose servers. So once we have the new update on our servers, it becomes available to users, and it's important to think about what users have in their app. So essentially, apps are built into two parts. One part is this native code that's built into the app binary, and the native code is stuff that you can't change with an overtheair update. This is stuff like the app's icon and some of the configuration about how the app runs. But then there's the second side of the app, which is this JS code and this update code that we're able to interchange with other updates. So if I'm a user using an Expo app and I open my app, there's a module that's going to query our servers and say, is there any new updates? And if there is, then we're going to look for any new updates based on a configuration inside of that app JSON file that we saw when we set up our project. This makes it. So if you have critical bug fixes and things that you need to get out to users right away, you can do that with Expo Publish. So in this case, if I ran Expo Publish with this arrow press fix, then my users would open up their app. They would download that new code, and then they would see the type of fixed it's at that point that I could start making new builds and then submit them to the app store to get review. Now there are a lot of different options that we can opt into with Expo updates. Let's look at those. Okay, so I'm here in the Expo documentation and inside of App JSON, there is an update configuration, which I can see here. On the left. There are three different configurations I could configure, which is whether they are enabled or not. When to check automatically. The different options are on load or on error recovery. On load is the default here. So when users force close their app and then open their app, it's going to check for an update. But probably the most important one is this fallback to cash timeout. This is saying, how long should we wait before launching your app while we download the new update? If there is a new update. So if this era press update was actually like, really large and it took people a while to download or if they're on a very slow connection, we could cap it at 30 seconds or 3 seconds or something. And if they don't download the update within that time frame, then they will fall back to the cash version of the app that's already downloaded on their phone. We want to make sure that users can always get their app so that they don't get stalled on that splash screen. Now there is sort of a trick here. By default. We set this fallback to cache time out to zero, which means we won't wait at all for any new updates, which means if we push an update out to user and they open their app. It's not going to wait for the new updates to download, and it's actually going to download in the background while they continue using the app. Then the second time that they open their app, it's going to load the update that was downloaded in the background the last time they used the app. This is preferable for some developers, but it also might be preferable for you to let users wait a couple of seconds to download the new update so that they can get those new updates even faster. So it's just good to know about the different configurations we can set with updates. So this is a lot of stuff that you can do with Expo, and there's a lot more configuration to all the stuff that I haven't talked about yet, but I do want to mention just quickly some of the recent updates and things that have been going on at Expo in case that you've used Expo before. So one awesome change that we've come up with this year with EIS is that you can build an app with any native code. You can add native modules like Bluetooth, or you can also add inapp purchases or things like a blur hash module that will allow you to add in a native module that blurs out your images as placeholders. There's tons of these and you can add codes like this, and we will still build your app for you, and that is not possible. We also have something called Custom Dev clients. Before I showed Expo Go and Expo Go works great if you're not using any custom native code. If you are using your own custom native code, you can make your own version of the Expo Go app and still get all of those niceties around opening up updates on your phone, and also your colleagues can do this too. And finally we're coming out with a service that updates our updates called Es Update, and this is incoming this fall and early spring. We'll be rolling this out, so keep an eye out for that. You're going to be able to do things like roll out updates to your users and see exactly which builds are pointed at which updates at all times. So the point is let's iterate together and figure out how to iterate faster. Expo allows you to do this in development by implementing an app without requiring knowledge of your native code. You can also review your work faster with internal distribution or with Expo Go, and you can build and submit your apps, enlightening speed in the cloud and make it consistent across all of your teammates. Finally, you can fix critical bugs with updates, which helps you fix things that might have slipped through the review process, which means, hey, it's coffee time. So if you haven't had a coffee today and you like coffee, please have one. I would love to have one with you next time. We can have something in person. Hit me up. I'm always free and available and thank you so much for iterating with me and listening to this talk, I hope you enjoyed it and continue and take some of these concepts into your work life and into the projects that you build in the future. Let me know if you have any questions and we can't wait to see what you build. With React native and with Expo.