Eric profile pic

Senior Software Engineer

Eric Zeiberg

At EF World Journeys, we operate three distinct travel brands: Go Ahead Tours, EF Adventures, and Ultimate Break. 

Each brand has its own visual identity, marketing voice, app store presence, and loyal customer base. What they share is almost everything under the hood: trip management, flight tracking, itinerary views, chat with tour groups, payments, excursion booking, and dozens of other features. 

Here's how the World Journeys mobile app team handles designing and maintaining 3 separate apps on the iOS App Store and Google Play Store, all under one codebase. 

When you first encounter the multi-tenant problem, the obvious solutions seem reasonable:

Fork the app three times. Each team maintains their own version. This works until you realize that:

 , etc checks throughout. This works until:

Make everything configurable via JSON or environment variables. This works until:

to orchestrate tasks across them. The root of the project is called 

 , and all subprojects inherit from the root. 

{
  "name": "wojo-app",
  "workspaces": [
    "apps/*",
    "packages/*"
  ],
  "scripts": {
    "gat:start": "dotenv -- turbo run start --filter @wojo/gat-app",
    "adv:start": "dotenv -- turbo run start --filter @wojo/adv-app",
    "ub:start": "dotenv -- turbo run start --filter @wojo/ub-app",
     ...
  }
}

This allows a developer to start the Expo dev client for a specific tenant with one command. 

Packages never import from apps and the dependency arrow only points downward. In other words, anything below the apps is completely tenant agnostic. 

Each app contains only tenant specific assets and configurations. This is a snapshot of the directory structure of a tenant:

apps/gat-app/
├── App.tsx                 # ~45 lines - just wires things up
├── app.config.ts           # Expo config (bundle ID, icons, etc.)
├── eas.json                # EAS Build configuration
├── assets/
│   ├── branded-images/     # Brand-specific PNGs, SVGs
│   ├── branded-animated-images/  # Lottie files
│   ├── localized-content/  # Brand-specific strings
│   │   ├── prod/
│   │   │   ├── en.ts       # English base strings
│   │   │   ├── en-US.ts    # US-specific overrides
│   │   │   └── en-CA.ts    # Canada-specific overrides
│   └── settings/
│       └── BusinessSettings.ts  # Runtime config for this tenant

The heart of our multi-tenancy architecture is dependency injection via React Context. This allows tenant specific content to be injected into components without the consumer having any knowledge of what the underlying data is. 

A sample of the injection interface is shown below:

export type AppProps = {
  assets: {
    brandImages: ImageAssets;
  };
  businessSettings: AppBusinessSettings;
  localization: Record<string, any>;
  clientName: string;
  theme: {
    dark: Theme;
    light: Theme;
  };
};

Each app provides an implementation of this interface:

const App = () => (
  <RootApp
    clientName="gat-app"
    assets={{ brandImages}}
    localization={{ en, en_US, en_CA }}
    businessSettings={businessSettings}
    theme={{ dark, light}}
  />
);

Let's walk through how a component receives the theming colors for a specific tenant. 

 to make tenant colors, typography, spacing, and component styles available throughout the app.

// Inside RootApp
<ThemeProvider
  theme={scheme === "dark" ? theme.dark : theme.light}
>
  {children}
</ThemeProvider>

Each tenant provides complete light and dark theme objects that confirm to our theme types, such as this one

export const light: GATTheme = {
  darkMode: false,
  palette: {
    primary: {
      main: "#57a197",      // GAT's signature teal
      accent: "#89bdb6",
      dark: "#468179",
    },
    // ... full palette
  },
  colors: {
    brand: "#378712",       // GAT brand green
    green: {
      darkest: "#103B30",
      dark: "#164e3e",      // GAT's deep green
      // ...
    },
    // ... all color definitions
  },
  global: globalTheme,
  semantic: semanticLight,
  component: componentLight,  // Button colors, alert styles, etc.
};


 hook and passing the tokens directly to the styles, like so: 

import { useTheme } from "@emotion/react";

export const PrimaryCard = ({ children }) => {
  const theme = useTheme();
  
  return (
    <View style={{
      backgroundColor: theme.semantic.color.surface.primary,
      borderRadius: theme.semantic.borderRadius.background.standard,
      ...theme.semantic.shadows.standard.default,
    }}>
      {children}
    </View>
  );
};

One of the trickiest parts of the multi-tenant architecture is 

 (Expo Application Services) and more to create a flexible pipeline that can build all the tenants for all the platforms. 

On PR open (and any subsequent commits to the git branch), a GitHub Workflow starts that, after running common actions such as linting, typecheck and our test suite, publishes updates for all the tenants using 

Using a matrix strategy to run multiple jobs from one workflow, the pipeline is able to spawn up workers that automatically deploy a new EAS branch based on the name of the PR. 

 eas update --auto \
            --branch="${{ github.event.pull_request.head.ref }}" \
            --message="Update with commit ${{ github.sha }}" \
            --non-interactive

Then, any member of the team who wishes to test the PR can simply navigate to the branch in their dev client, which pulls down the changes directly to their device and allows them to QA and verify the changes. 

Note: This technique doesn't work if the PR contains native changes (such as new packages, or interactions with the underlying iOS / Android APIs). For those scenarios, a new native build is require before team members can QA the branch

EAS allows us to do something similar to automate our app store publishing and release workflows. When a production build is triggered via a workflow dispatch, all the usual checks happen, and then 

No manual uploads, no XCode, no Google Play Console. 

All three tenants share the same version number, defined in 

. While our strategy would allow for different tenants to diverge and be updated separately, we don't do this for a few reasons:

If you're facing a similar challenge—multiple products, shared functionality, distinct identities—this architecture might be your answer. The initial investment pays dividends in velocity, quality, and peace of mind. And when your team ships a critical fix to three production apps in under two hours on a Friday afternoon, you'll know it was worth it.

 Reach out to the World Journeys engineering team or connect with us on 

Building three travel apps from one codebase: How we use Turborepo and Expo to maintain separate App Store listings while sharing business logic

Eric Zeiberg

Multi-Tenancy in React Native: Building Multiple Apps from One Codebase using Turborepo and Expo