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

When I was an intern I got my first accessibility audit back from a 3rd-party auditor. It listed out issues with the website I was working on and provided recommendations on how to make my code more accessible.  Then when it came to future features, I would copy-paste the same techniques to other parts of my code, but I wouldn't fully understanding why or when those techniques were needed.

Since then I've learned how much context I was missing around users and how they actually use and experience the web, part of that context being how to accurately test my work.  So let's talk about how we can check for accessibility!

Yay! Yes! Tools!  Gotta love it when you can just run testing software that tells you what's wrong with your code.  

 can be run by anyone and will scan a page and produce a list of code-level issues such as if an 

 tag, an invalid value has been passed to an ARIA attribute, and if an element has no programmatic text. There are also linters like the 

Automated testing tools are super easy to include into your development workflow and a quick way to learn about common issues and fixes.  However, while automated tools are great for correcting your implementations, they won't necessarily alert to when a feature needs some extra a11y love.  That's because automated tools don't necessarily know what it is that you're trying to achieve.  For example, there are certain ARIA attributes that a toggle button needs to be made accessible to all, but automated tools don't know that you're trying to build a toggle button, so it won't tell you what you're missing.  But 

 know.  And that's where manual testing comes in.

Manual testing is something we do all the time.  We interact with a feature or component and see if it does what we expect it to do.  But as mentioned in my post on 

the different ways people navigate the web

, there are so many different tools and methods that people use to interact with our websites and apps.  So 

 we should be testing our work with as many assistive technologies (ATs) as we can get our hands on, right?! Wrong. Since most ATs consume and make standard calls to the same accessibility APIs, we can usually say that if it works with one AT, it'll work for most others.  So we can easily cover most cases by testing with a few tools we likely already have at our disposal.

A lot of us are used to using a mouse to point and click our way through the web, but that's hard to do for users who have trouble seeing where elements are on a page, or even users who have difficulties with the minute movements a mouse can require.  Instead users should have the option to navigate solely with a keyboard.  When navigating with a keyboard, it's typical to scroll via Arrow keys, navigate to interactive elements using the Tab key (and Shift+Tab to reverse it), activate buttons with the Enter or Space keys (for link elements, only the Enter key is used), and use the Esc key to close menus, modals, etc.  The 

 is a great reference for how users expect to interact on a per component basis using a keyboard (and also a great place to view accessible versions of common components). During testing, you'll want to ask yourself the following:

Honestly, if at any point you're trying to use a keyboard and you get frustrated, it's a good indicator that your user will get frustrated as well. 

This is the most common tool used when navigating the web, but it's often overlooked how much we use the keyboard as well.  Most people without disabilities are hybrid users and will seamlessly switch between mouse and keyboard.  Just as there are those who only use keyboards, there are those who rely solely on "point and click" methodology.  

 is a popular speech recognition software that allows users to navigate via dictation, and the most preferred method of interaction is "saying and clicking" (check out this 

 if you need visualizations).  When, say, a quick search form in the header is only submittable by pressing the Enter key, it becomes harder for these users to perform the desired functionality.  We also want to keep in mind target size.  We don't all have the steady hand of a surgeon, so the general rule is to make sure that all interactive elements have a width of at least 44 pixels. Other than that, there aren't too many out of the ordinary things to test for with a mouse, but if you're looking for more rules like the keyboard list from earlier or you deal with crazy custom interactive components, you can check out the 

 section in the WCAG 2.1 for related rules.

Making sure that your website or app is resizable and customizable ensures that users with low vision can use your product.  Honestly this is a pretty big one considering people with low vision tend to be those who are older or even those who have lost their glasses to the sea while swimming at the beach after an earthquake...anyway, it's just to say that this helps more people than we think.  Users with uncorrectable low vision might use magnification software such as 

, which comes with a bunch of features like zooming in 200x, and enlarging text of webpages and apps.  We can check if our products will respond correctly in a few ways:

tl;dr Resize your browser window, zoom in 200%, and resize your text.  That's it.  That's how you test.  If anything looks wonky or unreadable, then it probably needs some fixing!

Okay.  So if you need one take away from this blog, it should be that you should 

 on your website.  It'll cover keyboard functionality and text-to-[insert preferred sense here] accessibility, which will pretty much cover 90% of your issues (I put a random percentile in there for the drama.  Please don't quote me!).

A screen reader is software a user can use to translate written text on a page to audible speech.  But it's not just the visible written text that it can announce.  If a website or app is marked up correctly, screen readers will announce 3 important pieces of information:

If you're testing with a screen reader and you don't hear those three things (save for exceptions noted earlier), then it's a good indication that you have an accessibility issue to log.  A lot of the success criteria of the WCAG relate to these three pieces of information being accessible, and if it works with one screen reader, it's likely to work with a majority of other ATs.

If you're on a Mac, the Voice Over screen reader is already installed and you can start using it right away.  For Windows or other OS's, popular screen readers are JAWS (subscription based) and NVDA (free and open-sourced). When using one of these screen readers, it's important to make sure you're testing with proper screen reader/browser pairings.   Based on the most recent 

, you should test your desktop sites with at least one of the following:

Just as Voice Over is available on Macs out of the box, it's also available on iPhones, and even most Androids come with preinstalled with TalkBack:

You'll want to test with the most popular pairings to determine if any bugs are implementation issues or compatibility issues, as it's often the case to report a bug with the AT for compatibility issues instead of trying to find a workaround on your end.

I would say that what we've covered so far will catch most accessibility issues.  If you're doing dedicated accessibility testing, there are a few other methods you could use to get more coverage.

This is actually a pretty big thing to test for, but I'm putting it in this section because it only applies to when you have animations, videos, or movement in general on your website or app.  Users with certain cognitive disabilities may have trouble using a product that has distracting movement and content on the site, and those who use a screen reader will have difficulty hearing if there's any audio content that plays automatically.  To help with this, pretty much all 

operating systems come with a way to reduce or turn off motion on their device

, and if implemented correctly, will also apply to websites and apps.

When it comes to animations, videos, and audio, make sure to check the following:

Windows users have a control setting called "High Contrast Mode" that enables them to set a sort of theme for their display.  They have the ability to decide what the color of their background, buttons, links, static text, selected text, and disabled elements.  This setting helps users with low vision and photosensitivity by allowing them to choose their own color scheme and set contrast levels of their preference.  Since essentially this mode overrides the CSS of apps and websites, it's useful to check to make sure that no meaningful content is loss.  

 is a subscription based testing tool that emulates many of the popular software-based ATs, and it has a good description of 

Phew!  That was a lot, and maybe even more information than you wanted.  But I swear: understanding what the issues are and how to reproduce them will help you understand the best approach towards fixing them.  Or even just helps you know what to search for.  Like "how to reduce motion based on user settings," ya know?  But if not, I'll talk about the most common accessibility issues on websites and how to fix them in another post.  For now, thanks for reading!

* You might be wondering if you should care about an AAA guideline when often websites only try to meet AA guidelines.  The answer is "yes," though they are more often considered as "best practices" to help provide an even better experience for users.  It might be helpful to think of conformance levels in this way: A = minimum needed to unblock users from using your site; AA = minimum needed to prevent users from rage quitting your site; AAA = minimum needed to provide a decent experience for users. It should be noted that it's near impossible to meet all AAA guidelines, as some actually may conflict with legacy systems, modern designs, and security practices.  So it's best to consider them as "best practice" and do what you can.

** I know y'all are itchin' to see some code and learn how to implement this, but that'll be in another post.  Look at how much text is already on this page!!

Learn about the tools you can use to check if a website is accessible to a variety of users

#testing.

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

How to Test for Web Accessibility