Easing the Path for App Releases

Managed Development of React Native with Expo

This is the fifth in an article series about mobile app development from the perspective of an embedded systems designer using React Native. The series covers Bob’s experiences creating apps for both iOS and Android devices. This month he wraps up his observations on mobile app development with the React Native framework, by looking at available tools for releasing and testing an app.

As you might know, Android phones are deployed from the Play Store by Google, and Apple phones are deployed from its App Store. For the purposes of this article, I will be using “app store” for both when it applies to both, and Play Store or App Store otherwise.

Whether those fears were justified back then, I don’t know, but I can assure you that review by Apple is no longer a concern. Admittedly, testing a production release of an app on an Android is a piece of cake—easy to understand, easy to implement, and easy to test the “sealed” product. And you don’t need to involve Google at all. And yes, you do need to involve Apple once you are ready to release to the App store. But as it is now, this should not hold up any normal development cycle. Beta testing was a snap for my Android users; however, a few of my testers had problems with Apple’s method of beta testing, which I will talk about later.

I am getting a little ahead of myself, because I want to first explain the steps of release for testing that precede release to the app stores. So let’s review the process. By the way, I am going to describe this process from the perspective of what I have been calling “Managed Development of React Native with Expo.” There are other ways to release your code to the app stores, but since we are embedded-product engineers, we want the quickest and easiest path to app store release. I found the following method to work with zero downsides.

DEVELOPMENT TESTING

Step 1: In previous articles (Circuit Cellar 405, April, 2024; 407, June, 2024; 410, September, 2024; 411, October, 2024) [1-4], I mentioned a little about development testing a React Native mobile app. React Native is a framework that uses JavaScript and React concepts to write native mobile applications for both iOS and Android.

Starting at the simplest level, you can test some or all of your app using Expo’s Snack tool (Figure 1), which I discussed in an earlier article (Circuit Cellar 407, June, 2024) [2]. A Snack can be shared easily with your team or your customer, just as I shared some Snacks with you. It can be run on simulators in the Cloud or using your smartphones or tablets. You don’t need to install any tools, and don’t need a Mac computer. This is ideal when doing user interface design.

The number of custom libraries that you can install with Snack is limited, and the application does not run at top speed. But as I have said before, it is awesome for just getting started. The downsides are that the app will be larger and slower. You are also limited to using the Snack editor. It is not a bad editor, but it’s not my everyday editor, if you know what I mean. I developed the code using my editor, and then cut and pasted it into the Snack editor.

Step 2a—If You Don’t Use Native Code: The next step happens when you use Expo Go (Figure 2). This is a separate app that you load on your phone. If you are not developing any native code or incorporating any libraries that have native code, you can use Expo Go to develop and test your app. I was able to develop my entire app using Expo Go, until I wanted to add one more feature at the very end that required native code.

With the most recent changes, if you use Expo Application Services (EAS), your mobile device will no longer need to be on the same network as the server used by Expo Go (more on this later). Thus, you could share it to test with a local team with remote testers, or even customers (but they would need to install Expo Go). And since updates are handled with over-the-air updates without recompiling, you, the developer, can make a change, and your whole team can see the change within seconds. This works well when you are choosing from the hundreds of options for a user interface. For example, which widget or layout looks better? You can mock up a half dozen, bring them to your marketing team, a customer, or a focus group, and instantly go back and forth without compiling or app store updates. You don’t even restart the app, in many cases. (I love this feature!)

Step 2b—If You Use Native Code: If you have native code or are using libraries that employ native code, you will need to test your software with what Expo calls a “Development Client” (“dev client” for short). This has the same restrictions as Expo Go, but does not use Expo Go. Your dev client build will be what is loaded on the phone instead. Again, no Google or Apple app store involvement is needed. However, your team, customer, or focus group would need to load the dev client on their smartphones. It still has the advantage of hot loading changes. The initial set-up is a little more complicated, though.

TESTING FROM THE APP STORES

I was able to fully test my application using the dev client option of Expo. I demo’d the app to a select few customers with it. Now it was time to release it for beta testing. In my case I chose about 30 testers (22 iOS users and 8 Android users) to do these tests. The process for each was different so I will discuss them separately.

I should also say that there are other methods of beta testing—”open testing” and “closed testing,” for example. But since we are embedded designers, we wanted the quickest way to go to beta with the one most like an app-store environment. That was true for Android phones. One of the great things was that in all my development, I did not find a single bug that exposed itself in only one device during beta testing. If it worked on Android, it worked on iOS. I had one bug in a library that manifested itself in Android but not iOS using the dev client. But the problem went away in production.

Testing on Android: Google provides a way to make your app available in the Play Store, but have it visible only to a select group of testers. From the Google Play Console [5], you set up each tester with email. When you are ready to release or make an update, you tell the Google Play Console to send them an email. (You can even create different groups of beta testers.) They click on the link in the email, and it takes them to your customized Play Store page. Without the link, no one could find the app on the Play Store, and it allows you to have them test out the Play Store interface.

I am skipping a ton of details needed to get you to that point, but they are all fairly well documented [6]. Using the Expo Application Services (EAS) makes this trivial. They do all the heavy lifting by building and signing the app on their servers, without a need for Apple Xcode (which only runs on Macs) (Figure 3) or Android Studio (Figure 4). Once you have decided on which of the score of options you want to configure your app, from the command line, type:

eas build -p android –profile[development | production]

EAS will use either the development profile (for development client testing with Expo) or production profile (for beta testing or full releases) to build your app. Within that profile you can tailor differences to suit your needs. It takes my app about 12 -15 minutes to build on the cloud servers of EAS.

Once built, you log into the Google Play Console and let it know to whom you want to release the app. In production, you can even tailor it to do staged releases-–in the unlikely event that your release will crash and burn with your entire customer base, due to some (heaven forbid) bug of yours, or more likely, some bug in Expo’s build process.

Other Android Details: I have skipped over a number of details that you will have to go through for your full production release. You will need a paid Google Developer’s Account. You will also need a Google Service Account and obtain a JSON private key for signing your app. For the full production release on the first release, Google will make you jump through scores of hoops, giving answers to a lot of questions in an archaic wizard-type process. It is lengthy and uses a ton of terms; I had no idea of their meanings, but was able to find them or sometimes guess. You will also have to go through a lengthy process of their verifying that you are who you say you are. All of this took me several hours and a $25 one-time, lifetime fee.

Once you have done this, EAS will take you through the build and submit in a pretty smooth process.

One other detail. Expo allows you to use their servers free of charge for up to 30 builds per month. Only at the height of the initial release did I come close to doing 30 builds in one month. (Note: an iOS build counts as two!) But going over the maximum is not terribly expensive to buy ($1 to $2 based on the size of the app). Once released, during my updates every 6-months, it only takes me 3-4 builds. For more info about pricing, see the Expo website [7]. The free servers are not always immediately available, so sometimes I needed to wait several hours for a build server. But hey, I’m retired, so time is not money! On average, I could get a build server in the Cloud in less than 15 minutes.

Once built, you can issue another command to EAS to submit the app to Google and/or Apple:

eas submit -p android –profile [development | production]

Debugging a Production Android Release: As embedded developers, we know the challenges of going from our development environment to a sealed box. Prior to my first Play Store development release, everything ran fine using the dev client release using Expo. When I first released the app to the Play Store for alpha testing, the app crashed and burned just after the splash screen. I was shaken. What should I do now? It crashed and burned on all my devices—both iOS and Android.

Android provides a platform tool –Android Debug Bridge (adb) [8], which allowed me to debug my crashing app. Within a few minutes after installing it and connecting it, it identified the offending React Native package. It was an animation package. I don’t know why it worked under Expo but not in production, but I decided I did not need Winnie the Pooh to dip his hand in his honey jar during start up. For now, he just sits there, statically eating his honey.

There’s one other nice feature with Google. Prior to launch, they actually test your app on hundreds of devices, and issue you a report with screen shots on scores of devices. They report on stability, performance, accessibility, and security. There is so much data, it can create a lot of work for you to go through. For example, they flagged that some of my screens did not provide enough contrast for ease of use. But no matter what I did, the problem did not go away, and the text was easily readable (to me) on all screens. So you might run into some bugs on their end.

iOS RELEASES

The process for releasing to the App Store is both similar to and totally different from the one for Android. You first need to get a paid Apple Developer Account ($100 per year) [9]. Then you have a plethora of questions to answer for Apple. Mostly,, they are similar to but different from Google’s questions. It seemed like Apple had more questions and were much more obscure (no surprise there).

From EAS, the build and submit process looks like this:

eas build -p ios –profile[development | production]

eas submit -p ios -–profile [development | production]

You can also (if you are brave) build and submit for both Android and iOS with a single EAS command. Both Google and Apple have to review the release. For Google, this usually took minutes. Typically for Apple, this took a day or two. Sometimes they would find a minor compliance issues, but for me there were never any code issues.

With the iOS process, I discovered how impatient I am as a developer. You jump through all the hoops to release a product, and then you have to wait for up to a couple of days to get it out the door. By the way, I did get reviews through on the weekends, which was something I had feared I couldn’t do. Why is that we developers release so much on Fridays?

iOS Beta Testing: When you are ready to do beta testing, the process is somewhat analogous to beta testing with Google. At the Apple Developer site, you create a list (or group of lists) of beta testers with their Apple ID email addresses. This was a problem with about 10% of my testers, who didn’t know their Apple ID email address. Instead of the App Store, the testers use an app called Test Flight (Figure 5). Of course, it doesn’t work like the App Store and doesn’t look like the App Store. This created problems for about 30% of my testers. They needed hand holding—but who doesn’t with Apple products? Once the app is released, the beta testers get an email telling them to go to the Test Flight app to download the updated app. Although that doesn’t sound like a difficult problem, it was for some of my testers.

Debugging Your App from the App Store: There is no equivalent to Android Debug Bridge (adb) with iOS devices. I suspect if a problem I experienced was only on my iOS devices, I would be forced to have an Apple device running Xcode or iOS console. With either of these (and the learning curve involved), I could get something similar to what is provided with adb. Although I didn’t have to use it, I imagine I would have to add code to my release to write to the console and view it. That was not required by adb.

CONCLUSION

As I wrap up my overview of mobile app development from the perspective of an embedded systems designer using React Native, I realize that the thin slices I have provided are micro-thin. I could easily fill several months of entire Circuit Cellar issues with details of what I have learned.

If you take nothing else away from this article series, know that both Apple and Google provide an excellent process for releasing and testing your app, providing you with more options than you could ever consider in one lifetime. And therein is the problem. It is much more complicated than necessary.

If you want to see the app I created, search for “Wintonbury Sermon Engagement” in either the Apple App Store or Google Play Store, and install the app.

In my next article, I will launch into Flutter development. According to the latest (2024) Stack Overflow survey [10], compared to React Native, Flutter is being used by more developers (9.4% vs. 8.4% or 450 more developers). But of course, I will look at it only in micro-thin slices! 

REFERENCES
[1] Bob Japenga. “An Embedded Designer Looks at Mobile App Development.” Circuit Cellar 405, April, 2024. 
[2] Bob Japenga. “React Native Ecosystems.” Circuit Cellar 407, June, 2024.
[3] Bob Japenga. “Mobile App Development with React Native.” Circuit Cellar 410, September, 2024.
[4] Bob Japenga. “React Native Hooks: The Closest Thing to System Calls.” Circuit Cellar 411, October, 2024.
[5] https://play.google.com/console/u/1/signup
[6] https://docs.expo.dev/deploy/submit-to-app-stores/
[7] https://expo.dev/pricing
[8] https://developer.android.com/tools/adb
[9] https://developer.apple.com/
[10] https://survey.stackoverflow.co/2024/technology#most-popular-technologies

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2024 #413 – Get a PDF of the issue

Sponsor this Article