Skip to content
Logo Theodo

Building Whitelabel Mobile Apps: A Comprehensive Guide of Technical Considerations

Mo Khazali9 min read

A wireframing for a blank app


Imagine this scenario: You’ve just joined as a lead engineer at Burrito Ring, an international chain of average tasting TexMex fast food. Your first project is to develop a mobile app that allows users to view the menu, check allergens, and order food within the restaurant. After six months of hard work, the app is rolled out, and everyone is happily enjoying their burritos.

Burrito Bell Logo & App

However, management at Burrito Ring suddenly announces their plans to diversify and launch a new restaurant chain called Burger Queen. Your manager approaches you the next day and asks, “Could we make another app like the one we built for Burrito Ring, but for Burger Queen?” Reluctantly, you agree and start working on the task. Surprisingly, the requirements are quite similar, and you end up copying some code from the Burrito Ring app. Building the Burger Queen app takes only five months instead of six. Success!

But the story doesn’t end there. Management announces yet another brand: Metro, a build-your-own sandwich fast-food chain. Once again, you find yourself building another app, with much of the code being copy-pasted. You heave a sigh of relief, thinking there won’t be any new brands for a while due to the recession.

But then, they come back to you and say, “We want to show our offers to boost sales. Can you roll out this feature to all three apps ASAP?” You estimate that implementing the feature in each app would take around a month, making it a three-month process overall, give or take.

Now you’re faced with a predicament: managing and maintaining three different apps. With each additional brand or app subtype, your workload increases, which becomes a significant risk. Wouldn’t it be great if you had a single app in a single codebase that could be easily customised for each brand and business?

All three apps

What is Whitelabelling?

Whitelabelling is an approach that involves abstracting the skeleton of your application and producing multiple apps based on that skeleton. These apps can be customised to match the look and feel of each brand while sharing a common codebase. They can display brand-specific data (within certain flexibility restrictions) and be published with different names, icons, and bundle IDs to the app store.

The benefits of using whitelabelling are significant. You gain the ability to create multiple branded apps with a single codebase, allowing for faster development time and more efficient use of resources. It also simplifies the maintenance of the codebase since feature parity is maintained across all apps.

When do you need a Whitelabel app?

Whitelabelling is suitable when the core functionality of your app remains the same across different brands, with minor differences in features. For example, in the case of our food app, the basic features of browsing the menu, placing orders, and viewing allergen information are consistent. Additionally, the UI components should be generic and reusable across different apps, allowing for minimal customisation. Lastly, the backend calls and data shapes should be shared, even if different instances of APIs are used.

Building the App

Creating a Design System

To successfully implement whitelabelling, it’s crucial to have your entire team aligned with this approach. Involving your designers in the process is vital to ensure a cohesive experience. Begin by creating a “Slate” skeleton application that serves as a design system. Define the atoms, molecules, organisms, and layouts that can be shared across apps, and identify the areas of flexibility you want to provide.

When building each app, utilize the same design system while modifying the base-level colors, fonts, and assets to match the brand’s identity. Making tradeoffs regarding customization is important since increasing customizability adds complexity to the codebase.

I’m a mathematician by study, so I like to think of these things as equations 😅. Consider the formula:

Complexity = Number of Components to the power of Number of variations


Split of whitelabel architecture

The architecture of a whitelabel app consists of two main components: the whitelabelled source app and configurations for each app that modify it. Additionally, a robust build system is essential for combining these components effectively.

Whitelabelled Source App

The whitelabelled source app encompasses various elements that form the foundation of the app:

Theme Types and Component Definitions

Product Item components

The final folder structure in a sample React Native app would look something like this:

Final folder structure for the whitelabel source


The configuration section contains assets, app-specific configurations, themes, and text localisations for each app. These configurations modify the whitelabelled source app to create the desired branding and functionality.

Build Tools and Workflow

Build Process Diagram

Building and maintaining whitelabel apps require a robust build system and a streamlined workflow. Here are some important considerations:

By following these architectural principles and adopting efficient build tools and workflows, you can create and manage whitelabel apps effectively, offering a range of branded products while minimising development efforts.

Final folder structure for the whitelabel source


Some of the challenges and considerations that we faced are the following:

Handling Different Data Shapes

In large organisations, there are usually different teams handling different backend services. As a result, data shapes are unlikely to be identical across the board. This disparity can affect the rest of the app and its functionality. In our case, we used a Backend For Frontend (BFF) approach to handle data transformations and unify APIs. Although this introduces some overhead and costs, it provides a solution to ensure consistent data handling across apps and isolates the dependency away from the actual app.

Backend for frontend as intermediary

Customising Components for Specific Apps

In certain cases, you may require custom components for specific apps that cannot be isolated to separate screens. You might be tempted to just introduce feature flags, with conditional rendering of components based on app-specific requirements. However, as the number of apps increases, managing a growing number of if/else clauses becomes a soup of mess. A more extensible solution could involve handling component rendering from the Backend For Frontend, using a JSON blob to define which components should be rendered on each screen. This approach maintains flexibility while reducing code complexity.

Dependency Management & Bundle Sizes

Managing different native libraries and handling dependencies across multiple apps can be challenging. To minimise complexity, it is important to prioritise high commonality in the feature set. Avoid introducing different dependency versions unless absolutely necessary, as they add additional layers of complexity to development and building processes.


Whitelabelling provides an efficient and scalable approach for building multiple branded apps from a single codebase. By abstracting the common features and components, you can save development time, efficiently utilize resources, and easily maintain the codebase. By following a well-defined design system and architecture, and leveraging appropriate build tools, you can effectively create and manage whitelabel apps. However, it is crucial to address challenges related to data shapes, customization requirements, and dependency management to ensure smooth app development and maintenance.

Whitelabelling offers developers and organizations a powerful strategy to expand their product offerings while minimizing development efforts. With the ability to create and maintain multiple branded apps from a single codebase, you can achieve faster time to market, reduce costs, and ensure a consistent user experience across your portfolio of apps.


I want to give a big shoutout to Jon Wagner and Callum Helmsley from our team who helped me with the research of this article (and the talk I gave about it at DevDays Europe). Their experiences and learnings from working on the white label app for Immediate Media was invaluable.

Feel free to reach out

Feel free to reach out to me on Twitter @mo__javad. 🙂

Liked this article?