Expo builds to same project even if the name of the app changes

So for our project we have a version of our app that is for consumers and then a version that is for us that is for administration purposes. Currently when I want to build the app I build on the default release channel for the consumer version and then I build on another release channel for ours. I wish to make it to where I can share the codebase while also having the app for us be built as a different a project so that there is a lower likelihood of deploying the admin version of the app to consumers and vice versa. Also I currently use the classic build system (expo build:[android|ios]).

I hope this was enough detail. Let me know if you have questions of course.

While still requiring some deeper technical knowledge, I think monorepos are now in a much better place for this sort of thing. We have a similar situation with a Bare app where we keep sharing more code between a consumer and a business version. I was pretty satisfied with a proof-of-concept I made where I had three packages within my monorepo:

  • common (shared code)
  • consumer-app
  • business-app

The consumer and business app would import the common package, include their own app.config.js with their own slug, etc., and presumably change some variable that activates the different modes. Running publish on each one would use the respective config, there should be basically zero chance of mixing up the two.


One thing… note that I said “proof of concept”… the reason I haven’t implemented a monorepo yet is because you really need to clear the deck for a bit in terms of open PR’s and otherwise in-progress code. Trying to merge pre-monorepo code with post-monorepo-code would almost always be a big mess, and the conversion is something that’s going to take a few hours to a few days to ensure everything went smoothly. So, it just happens that I have not yet found a window where I can get this done, but hopefully you have better luck!

1 Like

Thanks for your response. It definitely seems be in the right direction. I’ve been looking at this option and it seems useful for some other projects that also use code from the app. But I’m not sure how I’d effectively use this for what I originally intended. I haven’t messed with packages before so that’s probably why. I’ve got a demo app working in a monorepo with a package so I think that means I’m figuring it out. But do I have to split all the common pages and code from the two apps? And if so, how would I implement it afterwards?

Writing this, I feel like I’m asking for my hand to be held. I’m willing to read any articles or pages you send my way though so you shouldn’t have to.

I don’t really have any other resources to point to other than the Expo docs for setting up a monorepo. How you split up the common code really depends on what you’re sharing. It sounded to me like you were already building both apps from the same codebase, and that you must’ve had some kind of flag or variable that changed whether it was for admins or consumers. If you have something like that, then your common package could be everything you have right now, minus App.js and app.config.json, and then those would be specific to each app package.

1 Like

I don’t have a flag currently so that would be a great addition to add. Thanks for the help, I think that’s all I should need.

To clarify, I’m going to use what you just suggested as well as a monorepo.

1 Like

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.