Any reason why not support Expo Go?

[ansh]

It seems as though all the used libraries are compatible with Expo Go.

Expo Go provides a great way to quickly prototype apps without having to worry about a build-stage.

Will it be possible to give an Expo Go version too? With instructions on how to enable expo-dev-client when necessary.

[premdasvm]

react-native-mmkv and react-native-avoid-softinput needs expo-dev-client.

[yjose]

@ansh as @premdasvm mention we are using mmkv and softinput packages that require custom dev client.
Regarding your question, @ansh, from our experience, most of the apps we are working on use custom client development. In most real-use cases apps you will end up using libraries that requires custom dev client. our main goad with the starter is to provide a production ready starter for react native app and using a custom dev client is the right choice here.

Anyway, you can easily delete those two libraries and use other alternatives that support Expo Go. I am thinking of writing a quick guide on how to update the starter to run it with Expo Go. Let me know if you are interested.

[ansh]

@yjose Completely understand and that makes sense.

My 2c: making Expo Go support the default gives you the benefit of knowing that all packages are tied with that expo version and can be easily updated with the expo-cli.

Whereas, with expo-dev-client, anyone can install any version of any package and then if they report bugs, it'll be harder for you to reproduce because:

1. You'll have to clone and install the reproduction locally instead with Expo Go people could easily make reproductions on Expo Snack. This will make tracking and solving issued that raised easier instead of trying to debug whether the issue was simply due to a different version of some 3rd party packages.
2. When you are updating the starter kit for the next time, to the next Expo version, or any updates. Doing it on Expo Go would limit native code changes since that's all managaged by Expo. And then when you updating Expo, that is managed too.

[yjose]

First, I don't think knowing that all packages are tied to the Expo version is related to Expo Go. You can find out by using expo-doctor. We provide a script specifically for that in the starter.

Regarding your other points :

1. You are right here, even if it's very debatable. Most of the weird issues are related to the native side. But since you have full control over your build, you can easily spot the errors with more effort, of course.
2. Migrating to a major Expo version will require updating the Expo Go version as well in this case.

I don't see that Expo Go is bad here, but it isn't aligned with our philosophy of providing a production-ready starter instead of just a simple starter for prototyping new ideas