Thoughts on Expo config plugins
As someone with experience in native Android/iOS development, Expo seemed higher overhead when considering a project that I knew was going to need many native modifications. But now my stance has changed beacuse they've come up with a sweet workflow.
Devs using vanilla React Native projects tend to end up with very unique Android/Xcode issues after years of mutating their projects and largely deviating from the original React Native template they started with.
Config plugin architecture encourages us not to commit the /android and /ios folders to git at all and instead have them be the product of transformations of code.
import { ConfigPlugin, withXcodeProject } from "@expo/config-plugins"
import type { ExpoConfig } from "@expo/config-types"
const withCustomProductName: ConfigPlugin = (config): ExpoConfig => {
return withXcodeProject(config, (config) => {
const xcodeProject = config.modResults
xcodeProject.productName = "Custom Product Name"
return config
})
}expo prebuild generates the projects in the base state. To modify native project settings we use config plugins: JS scripts which target files specific files within the /ios /android directories such as the gradle file, the podfile, the Xcode project etc.
With this workflow we no longer have to maintain the /android and /ios directories. Instead we regnerate them and let the plugins apply the changes afterwards. This means we can very easily upgrade React Native to the next version automatically via the Expo SDK. After upgrading, we only have to adapt our scripts – should there be any changes needed – to the updated template instead of figuring out our unique and mysterious situation with the the Xcode and Android projects.
Well what about writing native code in Swift/Kotlin you ask? To do that we would have to create our modifications as an installable native module. While this is more overhead, it is far more maintainable as all mutations to native code are simple plug and play.
