Ejecting from Expo
2 years ago • 9 min read
A detailed guide on ejecting from Expo, fixing all problems that follow, and building a release bundle.
Ejecting from Expo
2 years ago • 9 min read
A detailed guide on ejecting from Expo, fixing all problems that follow, and building a release bundle.
After a week-ish of testing the app, I decided it was time to eject from the managed workflow on Expo and switch to the bare version of things so I could start implementing the in-app payments. I am also hoping this results in a reduced app size but let’s see how that goes.
Unfortunately, several Google searches later, I’ve realized there isn’t a lot of documentation around this. So I thought, why not just hit expo eject and figure it out as we go?
I’ll try and post every problem I run into and how I eventually solved it and link to whatever was helpful in doing so, because your solution might not exactly be the same as mine. Also, this is week 3(?) in React Native for me so you may notice something I didn’t. Alright, enough talk, let’s go.
Result of expo eject
The image above is what we see once we eject. It shows a bunch of warnings for both Android and iOS. At the moment, I am only worrying about Android but I am going to go ahead and ignore those warnings and just try running the app and seeing how it goes.
Splash Screen
Well, that didn’t take long, did it? To be fair to Expo, it already warned us about this. Upon some digging, I found out that AppLoading is an API that isn’t available in the bare workflow. So to fix this, we are going to have to use the expo-splash-screen package. Let’s start by installing it.
Next, we need to get rid of all our code that uses the AppLoading component from Expo and use our newly installed package to do the same thing. You can see some examples here and also what I ended up with below.
Splash Screen Configuration
Next, we need to hook into the native view hierarchy and tell it about our Splash Screen. There is an Automatic Configuration section in the README but that did not work for me and I had to configure it manually using the steps provided in the Manual Configuration.
If you also went for the automatic configuration and had it fail for you, you’ll probably have to delete res/values/colors_splashscreen.xml and res/values/styles_splashscreen.xml as they are just empty files. Again, if the automatic thing works for you, great. If it doesn’t, this might be something you need to fix or yarn android will keep failing.
The docs are pretty on point as once I followed them and restarted my server, I had the Splash Screen showing up and my app running as expected!
Push Notifications
If you’re using the push notifications setup that comes with the managed version of Expo, that’s probably going to break as well. Luckily, since SDK 37, it also works with the bare workflow. Let’s start by installing this package.
Next, we need to change how we get the push token from our user. In the managed workflow, Expo has access to the manifest and picks up your ID from there. But in the bare workflow, we have to pass it manually.
Updating Expo Push Token
Update your push token fetching code wherever applicable and now your app should be updating the push tokens as it was before and everything should be working fine. You can also test this by using the notification testing tool that Expo provides.
App Icons
While testing my notifications set up, I noticed that the app icon was the default Android icon, which means our icon setup is broken as well. At this point, we should have predicted this as the CLI even warned us about it. You know, in the warnings we chose to ignore. To fix this, I followed this guide on the official developer documentation for Android apps.
Basically, open Android Studio, go for a run, or something because it takes forever to read and understand your project, look for the res folder under app/src/main , right-click it, and click New -> Image Asset . This opens the handy little wizard and all you have to do is follow the guide linked above and choose the icon files that you used in your app.json file earlier with Expo.
Once you follow the guide, just uninstall and reinstall the app on your device/simulator and you should see your actual icon!
Keyboard
Another issue that randomly popped up for me was that my keyboard was suddenly covering all my inputs. This was surprising because this seemed to work perfectly fine when I ran my app with Expo.
To fix this, I simply had to wrap my view with the KeyboardAvoidingView component from React Native. Come to think of it, I probably should have been using it already. Here’s a small snippet of what needs to be done.
Building
This is the part you’re probably here for, right? So let’s get started.
To begin with, we need to fetch our existing keystore from Expo.
This should show you your Keystore password , Key alias , Key password and, also create a .jks file in your root directory.
Next, open android/gradle.properties and set up your Gradle variables.
Make sure you move the keystore file that Expo generates into the android/app directory. Then simply set the value of MYAPP_UPLOAD_STORE_FILE to be the name of your keystore file.
Now, let’s add the signing config to our android/app/build.gradle file. Make sure you’re editing the code in the proper sections of the file. Specifically the release section under signingConfigs and the release section under buildTypes .
Once we do all that, all that is left for us to do is to generate our release APK.
While building your APK, you might run into this error
To fix it, open your gradle.properties file and add these two lines
You can find the generated file under android/app/build/outputs/bundle/release .
You probably also want to test it before doing that. To test the app, simply run:
Make sure you uninstall any previous version of the app that you may already have on the device.
If your build works fine, that’s great. Test it well and move onto the next section. For me, it didn’t. The app would crash as soon as I opened it and I had to do a bunch of things before I got it to work again. If you’re facing the same issue, you might want to continue reading and try some of these techniques.
The best way to figure out why your app is crashing would be to look at the logs, to do that, run adb logcat *:E , wait for it to output whatever it outputs and once it stops/slows down, try opening your app and you should be able to see the stack trace.
Expo Publish
Another issue I faced was with the fact that I had never run expo publish before. This command, along with publishing your app, also creates the manifest and the bundle in your respective iOS and Android directories. Those files are necessary once you build your app and run it in production. Simply run expo publish and it’ll create the necessary files in the right place and that should that care of that.
A small note here, you must run expo publish every time you want to release a new version of your app. The manifest and bundle files it creates are basically the JS bundle that contains the code for your app. Your ideal process should be something like this expo publish -> bundle -> test -> release.
Another small note. If you have OTA updates on (and they’re on by default), this may break the app for the users that are already using it. I am not quite sure how to work around this but I personally have turned them off so this doesn’t happen in the future and will look into turning them back on later.
Assets
After running expo publish , I ran into a new problem. My app would throw an error saying certain assets were missing. The reason behind this is the bundledAssets key in the manifest that Expo generates. To fix this, I had to tell Expo to generate and bundle those assets in the standalone binary. To do that, simply edit/add the assetBundlePatterns key to your app.json with the path to all your assets. Here’s what mine looks like:
Once I fixed these issues, I rebuilt my app and it finally launched and proceeded to work perfectly on my device!
Proguard
So apparently this helps reduce your app size so let’s give this a shot as well. To enable Proguard, open your android/app/build.gradle and set this to true.
Once, I did this and built an APK, it was 2MB smaller but it crashed as soon as I opened it. The reason for this was that I was using the react-native-svg package in my app. To fix the crash, I had to add the following snippet to my proguard-rules.pro file.
After doing that and building my app again, everything seemed to work as expected.
Release
At this point, we have a release build that works and the only thing left to do is upload our app to the Play Store so our users can get access to it. Well. almost!
Permissions
This was something I noticed after I built my app and tried to release it. Somehow, my app now needed every single permission ever to run. I don’t quite know what caused this to happen but you may want to check your AndroidManifest.xml file and comment out the permissions you don’t need.
Another issue I faced with permissions was that even though I commented some of them out, my app would still ask for them. This probably happens because one of the packages (probably a unimodule) in your project might be asking for them even though you don’t need them. To fix this, you explicitly need to add tools:node=»remove» to that permission. Here’s a small snippet.
Versioning
Once we’ve tested our build and made sure everything works as expected, we want to update our versionCode and versionName . Earlier, we’d do this in the app.json but because we’ve ejected to the bare workflow, we must now do it in the android/app/build.gradle file. Remember, the versionCode must be an Integer while the versionName is a String.
After updating the values, build your app one last time and now, you can upload it to the Play Store and upon review, it should reach your users!
It’s been a long day so I am going to stop here for now. I may in the future explore reducing the app size further and seeing how that goes but in the meantime I came back to update this! Upon pushing the release to the Play Store, I noticed that the app was now only 9.62MB compared to the 25MB it was earlier! I hope this post helps you and if you have any questions, feel free to hit me up on Twitter with them!
Источник
gregfenton / EXPO_BARE_WORKFLOW.md
Debugging a problem with my Expo app
Table of contents
I have an Expo app, built with the Managed Workflow. It runs great on iOS and mostly fine on Android. except that the app has a tendency to red-screen in the Android emulator (and crash/restart on a physical device).
The stack trace indicates: com.facebook.react.bridge.ReadableNativeMap cannot be cast to java.lang.String
Googling around didn’t help much. Speaking with Very Helpful folks on the Expo Slack server, it was recommended to try debugging this at the Java level. I know Java development!
- (. enterprise Java development. )
- (. with Eclipse. )
My app uses Google Firebase for Authentication, Firestore, and Cloud Storage.
The nature of the crashes was less-than-predictable. Sometimes it would crash within minutes of the app starting and me clicking around. Sometimes if I just started the app and logged in, then let the app sit. and sit. and sit. it might crash after an hour.
The one consistent thing was the stack trace. It was always the above exception message with the fuller stack trace being:
Having avoided platform-specific coding (that’s why I went with Expo/React-Native), I was at the mercy of others. But following the advice from the Slack channel, I was empowering myself! (damn. )
Here is my experience getting from an Expo Managed Workflow running blistfully-platform-unaware with simple commands like expo start , to a Bare Workflow running with a native platform debugger via Android Studio 😬 .
Ejecting my project
Cedric from the Expo team pointed me to the starting docs for Expo Eject (the «bare workflow»). I followed the steps, but ran into problems (that I detail, and work out(!!), below):
cp -a rn_tick8s fred cd fred expo eject
Post-Eject «Additional Steps» From Output of expo eject
Added the expo-camera settings to android/build.gradle
Added the expo-camera settings to android/app/src/main/AndroidManifest.xml
Removed the reference to expo-constants from package.json (it wasn’t being used, I had already replaced all of its instances with Updates.manifest from expo-updates )
Added the entries for expo-image-picker to AndroidManifest.xml
Run npx @react-native-community/cli doctor
I pressed ENTER because I don’t care (right now) about building for iOS, just trying to debug Android.
Run expo fetch:android:keystore
FYI: not sure what to do about assetBundlePatterns in app.json . Current value is:
so am leaving it as-is for now.
Let’s get compiling
- more input from @bycedric on Slack (thanks Cedric!) — dev environment requirements are available from the React Native team: https://reactnative.dev/docs/environment-setup
- NOTE: on that page, you want to click the correct «tabs» (not necessarily intuitive):
- React Native CLI Quickstart (not Expo CLI Quickstart )
- macOS (or Windows , or Linux )
- Android (I’m trying to debug Android; don’t care about iOS at this time)
- NOTE: on that page, you want to click the correct «tabs» (not necessarily intuitive):
- I followed the instructions above.
- Found that I had Android SDK 9 installed, but not SDK 10 (Q).
- Ensure to install the correct SDK, and SDK Tools (all as per the instructions)
- Ensure you update your shell (bash, zsh, etc.) correctly, and that the shell you are running in has the enviroment variables ( ANDROID_HOME and PATH ) set correctly.
In the shell running the Metro server (started with the previous yarn android command), press ctrl-c to exit the server and press ENTER to close the terminal window
Googling I found these (the SO article points to the GH issue):
In the shell running the Metro server (started with the previous yarn android command), press ctrl-c to exit the server and press ENTER to close the terminal window
Run yarn android (third time is the charm! 🍀 ) (it is building. . . . . . .)
Metro server is up. App splash screen (the default one, not my custom one. will fix later) loads. But then Metro has stack trace:
/package.json I have:
Though this worked under an Expo Managed Workflow, it isn’t working in this Bare Workflow.
If you kept Metro running, in its window press r to reload the JS code. If you had shut it down, then run yarn android .
- WE HAVE GREAT SUCCESS!
- app running in emulator!
- log in, data shows. GREAT SUCCESS! (/insert happy dance here)
Shut down Metro with ctrl-c
Debugging in Android Studio
- Start Android Studio
- In its startup dialog, choose Open Existing Project.
- browse to
/android and click the Open button
(
2 minutes) Wait. wait a while. Studio opened for me showing just a couple of nodes in the Project (left-hand panel). But it was busy in the background building and inspecting the project. Let it do its thing. Eventually it finished and it was clearly aware of the project, the emulator. Lots of nodes listed in the project It was ready to run!
- com.facebook.react.bridge.ReadableNativeMap
- com.facebook.react.bridge.ReadableNativeArray
- ends up that the object attempted to convert to a string was: and having that data confirmed that these crashes are likely the result of expo issue #7371, which itself references this comment on expo/browser-polyfill issue #35 that shows the exact same data structure as the JSON string above.
Essentially, it looks like expo/browser-polyfill changes the React Native environment such that Firebase believes it is running in a web browser. And with that change, I think, what is happening is that Firebase mimics fetching an image as a form of «keep-alive» (or «session ping»). But the «browser» doesn’t really behave like one and unexpected interruptions cause React Native’s bridge to get «bad data» (. I’m sure I could dig for more specifics, but I have what I need for now: ditch expo-pixi / expo/browser-polyfill since I am not giving up on Firebase).
My app had been running on Android fine for quite some time. I have been doing a lot of tweaks to existing functionality in the past month — mainly UI tweaks and styling consistency and some code cleanup. I noticed the crashing a couple of weeks ago in development but ignored them to get a new beta-release out (and things were running fine on iOS). The one major feature that I did add in the past few weeks (why didn’t it occur to me earlier??) was Signature Capture using expo-pixi .
For more reading on specifics, see:
I captured all of the above steps to detail out to:
- expo eject a managed workflow project into a bare workflow
- configure a Android Studio development environment
- run the bare workflow from the command line
- run the bare workflow from Android Studio
- debug the bare workflow from Android Studio, capturing exceptions without terminating the app so that you can inspect the conditions around the exception
Conclusion: At this time (expo SDK 38 & SDK 39, Firebase v7.9.0) expo-pixi (or, more precisely, expo/browser-polyfill ) and the Firebase SDK do not play well together.
Источник
