I used to build react native app several years ago, and at that time, we couldn’t use custom native module (the module that Expo doesn’t have in its runtime) in managed workflow.
But currently, according to docs, it seems that we can use custom native module in managed workflow as well.
So my question is: are there any differences between managed and bare workflow in terms of use of native module?
If there’s still limitation in managed workflow when I were to use custom native module?
Hi @ynakamura
Yes, that is correct.
Yes.
When you build a managed workflow app using eas build, there is one step in the process where the build server runs npx expo prebuild. This generates the native projects on the fly. So it basically turns your app into a Bare workflow app just before building it.
During “Prebuild” Expo will run any Config Plugins that you have defined in app.json or app.config.js. in the “plugins” section. These config plugins make modifications to the native projects that are needed by the native modules. e.g. they might modify build.gradle or Podfile or AndroidManifest.xml or Info.plist, etc.
If a native module only needs you to run pod install and everything else is handled by autolinking then you do not need a config plugin.
If a module requires some changes to the native project before it will build, then you do need a config plugin to make those changes during Prebuild. Here are some examples
Some native modules will already include a config plugin (check for app.plugin.js in the module’s root directory), so you can just add the module’s name to “plugins”. Here are some examples.
For some native modules there are third party config plugins. Here are some examples.
If there’s a native module that you want to use that needs changes to the native projects but does not have a config plugin already, you can write one yourself. Depending on what changes are required this might be easy or hard. If you want to do this, read the config plugins documentation and also read the source code of existing config plugins (e.g. search for withAndroidManifest or whatever you want to use in the expo/expo and expo/config-plugins repositories on GitHub or find another config plugin that makes similar changes to the ones you need to make.)
When adding config plugins to the “plugins” array in app.json, some plugins can take props that get passed to the plugin when it is run.
e.g.:
"plugins": [
"plugin1", // no props
["plugin2", { "prop1": "value1", "prop2": "value2" }] // with props
]
So in the managed workflow you would not run npx expo prebuild and the build server will run it automatically and the config plugins will be run to make the necessary modifications to the native projects before the app is built.
Note: Expo Go still doesn’t support native modules because the native code from the native module was not compiled into it. But you can create a Development Build of your app, which is basically a custom version of Expo Go that has all of your dependencies built in. Then use that instead of Expo Go. If you later add another dependency you will need to create a new development build.
Hi @wodin
Thank you for quick reply and elaborating the workflow in detail!
So there are some differences as you explained. Does that mean it’s harder than bare workflow?
Or it’s just a difference, not difficulty?
To give some background, I’m supposed to use custom native modules in this development. so I want to make sure the managed workflow has no limitation with custom native module integration.
I would not say so, but I suppose it depends on exactly what you are trying to do.
Could you elaborate on this? Are you going to be using existing React Native modules? Or are you going to write your own ones? Are you able to say which native modules you intend to use?
The managed workflow might involve some more up front work when adding a native module (depending on the module), but it makes it much easier to upgrade to the next version of React Native or Expo SDK later.
If you find that you want to include a native module that does not have a config plugin already and you cannot work out how to create a config plugin for it, then you can “eject” (actually it’s not called “eject” anymore) by running npx expo prebuild. If later the authors of the module write a config plugin, or if you figure out how to do it, you can switch back to the managed workflow again by adding the config plugin to the "plugins" array in app.json and deleting the ios and android directories.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.