


Expo went a step further by going ahead and packaging up two pre-compiled native clients (for iOS and Android) which you can’t update yourselves. Additional native modules can be added into your React-Native app by either compatible npm packages or your own code. What Facebook did was nothing short of miraculous: they pre-assembled two mobile native clients with various native modules so that you could work with most common mobile features together with a Javascript engine to handle the actual business logic of the application.

For that to happen, we need the native code (Objective C / Java) in place to act as “bridges” between the JS code (actual application logic) and the native features (camera, audio, sensors…). It can also be updated dynamically without recompiling the app. React Native’s goal is to give you the ability to write your application in pure JS so that the application can run independently, yet separately from the mobile application. To understand Expo detach, it’s worth revisiting the architecture of a React-Native app. Since you still have access to ExpoKit, everything else should still be running the same as before (with some exceptions, which we will discuss later). A feature exists called Detach giving you what is essentially a simplified version of Expo client that you can tinker about with and build by yourself. Luckily, Expo provides a way out of this sticky situation. Still, doing this can prove problematic if your code has already been built based on Expo specific features because you would have to remove a whole bunch of code and/or replace it with equivalent modules.

Yet, as there aren’t many pure-JS react-native packages around at the moment, the only way to continue your development would be to move the whole app back to a pure React-Native environment. This is because the Expo package cannot add native modules - a huge obstacle for some projects. When developing with Expo, one of the challenges developers typically encounter is finding a compatible npm package.
