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

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

Multi-tenancy in React Native with Expo + Turborepo

Offline mode is extremely important for most mobile apps in the market. Different companies with apps related to travel, weather, gaming, or finance, for example, find it vital to allow users to access certain data anytime, anywhere. With this blog post, we’re gonna explore how to create a seamless offline experience using React Native and Apollo.

In the past, we’ve explored different options, including maybe the most popular approach which is to use SQLite. This is a fine solution, but it can get pretty tedious in terms of extra configuration and needing to read and write manually directly from this database.

In this simple todo app example taken from 

, we need to manually read and write on initial render:

useEffect(() => {   
   db.transaction((tx) => {
      tx.executeSql("create table if not exists items (id integer primary key not null, done int, value text);");    
   }); 
}, []);

Here, we need to initialize our table if we haven’t done so yet.

Same goes for any other function that needs to write to the db. Let’s take a look at adding a todo below.

In this function, we are directly calling our database to insert our new todo items, as well as then read them.

While all of this effectively works, you can quickly see how this can become difficult to maintain for larger apps.

With our current architecture, we have over 40 federated GraphQL micro-services. So we share these API’s amongst all of our clients, including both web and mobile. We consume these API’s using Apollo Client. “Apollo Client is a comprehensive state management library for JavaScript that enables you to manage both local and remote data with GraphQL. Use it to fetch, cache, and modify application data, all while automatically updating your UI.” For the purposes of this blog post, I won’t get into the details of what Apollo accomplishes for us, but you can read more about it in their 

One of the main benefits from Apollo is its out of the box caching implementation. They store all of your query results in a local, normalized, in-memory cache. What this means for your mobile app is that if you navigate to a screen, fetch the data, and then return to that screen (all while your app is still open), you won’t need to re-fetch all of that data again from the network. Instead, Apollo is simply smart enough to get that data from the in-memory cache.

There’s a lot of different strategies in the way you should properly cache data using Apollo Client. You can configure how you want to balance fetching data from your cache through Apollo’s 

. It’s also very important to make sure your data is being cached properly. Apollo does this by generating a cache ID using a typename and an “id or _id” field on your data object. So it’s vital that you specify a unique identifier on each of your data models, otherwise, you can specify how you plan on merging those objects in your 

So now we should have our cache properly working, but we notice that once you close out the app, you’ll be forced to fetch from the network again, since Apollo Client simply provides an in-memory cache. Going back to earlier, this won’t work for certain industries. Travelers on the road need to be able to access their data offline, which means once they close out their app, they won’t be able to fetch data from the network and they also won’t have the cache available in memory. So what do we do?

! Apollo Cache Persist is a library which seamlessly saves and restores your Apollo cache from persistent storage.

The setup is extremely simple. First, we need to decide which configurations we want to add. For example, if we want to change the maxSize, which defaults to 1MB, we can set this here. You can reference the additional configuration 

. For our example, we’ll focus on just providing our storage provider, which will be AsyncStorage.

import { ApolloClient, InMemoryCache } from "@apollo/client";
import AsyncStorage from "@react-native-async-storage/async-storage";
import { AsyncStorageWrapper, CachePersistor } from "apollo3-cache-persist";
import { useEffect } from "react";

const cache = new InMemoryCache({
   // your cache configuration
});

const persistor = new CachePersistor({
   cache,
   storage: new AsyncStorageWrapper(AsyncStorage),
});

useEffect(() => {
   async function initializeCache() {
      await persistor.restore();
      const client = new ApolloClient({
         // your Apollo Client initialization
      });
      client.onClearStore(async () => {
         await persistor.purge();
      });
   }
   initializeCache();
}, []);

First, we set up our initialize our CachePersistor from apollo-cache-persist. We reference our cache by passing it in, and we determine our storage and initialize our AsyncStorageWrapper with AsyncStorage from 

@react-native-async-storage/async-storage

. Then, in our app initialization, we restore our cache using 

. This takes care of the hard work for us by checking against Async Storage and seeing if we have any data that we need to restore as part of our cache. Once we have this part setup, we can close our app and you’ll notice you have data available without needing to make network requests (Assuming you already fetched at least once before and have it in your cache). You can switch to airplane mode to properly test this out.

Since we have proper authentication, we still have one more step. We need to make sure this data is cleared from storage on logout because of security and to prevent any bugs with data from any other users logging in using the same device. In your app initialization, we can add 

client.onClearStore(async () => { await persistor.purge() });

 , which now allows us to purge our async storage whenever we clear our Apollo Client store. So now, when we sign our users out, we can simply clear the store.

<Button
   title="Sign out"
   onPress={async () => {
      await client.clearStore();
   }}
/>

That’s it! Now our users are happy on the road being able to access their data making the user experience that much better.

You can find a working demo here. It is made so you can see a working app with the examples we’ve outlined in this blog post.

https://github.com/nicobermudez/expo-offline-app-example

Photo by <a href="https://unsplash.com/@stenslens?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Sten Ritterfeld</a> on <a href="https://unsplash.com/s/photos/offline?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>   

Optimizing React Native offline mode using Apollo Cache Persist

#expo.

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

Optimizing React Native offline mode using Apollo Cache Persist