How to Build a White-Label App

White-labeling a mobile app is a great option that many businesses choose for its affordability, lower level of risk than custom development as well as sufficient flexibility and customization compared to app builders.

Taking the rising demand into account, the number of white-label app providers started to increase as well. And it makes perfect sense — it’s less time-consuming, doesn’t take that much effort (if compared to custom apps development), and can be sold to an unlimited number of customers with little adjustments to each use case.

The answer is pretty simple — yes it is. If you have a custom app, you most likely have full ownership of the app’s code

Thus, you can ask your development team to make a white-label solution based on this code. Even though it takes time and effort too, it’s surely easier than writing the code from scratch.

However, in this case, you would have to stick to the type of product that you have. For example, if you have a native app but want to build a white-label progressive web app, you won’t be able to reuse the code (unless it was built with React Native.

3rd-Party Integrations: Yes or No?

Actually, the answer here isn’t really about what you can or can not do — it’s more about whether it’s reasonable or not.

Many people choose white-label apps for their simplicity. If they need something more complex in terms of functionality, design, or technical infrastructure, they’re likely to go for a custom development since the price won’t be that much higher in this case.

If you decide that you want or need to enable a 3rd-party integration, it’s normally done with the help of APIs — an interface that has a set of tools for integrating relevant features in it.

With white-labeling, there are multiple options for how you can do it, and the choice is often not on you. Depending on which API you’ll choose, you could:

• Connect all apps to one account so the access will be mutual.
• Build a separate API access key for each app.
• Have several keys even for 1 client (for example, for iOS and Android App).

Do App Store & Google Play Really Delete Template Apps?

One more thing we wanted to cover is how app markets treat white-label apps.

Single-tenancy has certain special properties that basically define the architecture and its difference from multi-tenancy:

• They have an isolated database on the server.
• More customization possibilities like additional features or structural changes are possible since they won’t concern other tenants. Basically, there are customization options in multi-tenancy as well, however, such architecture means that changes will occur in each tenant’s app.
• Tenants are free to choose to update the app whenever they want in the future since they’re not bound to any other tenant or server, meaning that updates don’t apply to them in any way.

When developing this type of white-label app, you should consider implementing the CI/CD (Continuous Integration and Continuous Delivery). CI implies updating the code in the git-repository, where special CI tools test and build it automatically. CD then is used to apply the changes to the actual app’s code on the server. Continuous here means that changes are deployed right after the tests are completed successfully.

If you are interested in such a setup, you can talk to your dev team or to us about it — we’ll fill you in on the details like price, time input, etc.

Also, we at Stormotion utilize Xcode to build schemes that help us provide different versions of the same code with minor adjustments in each variant. These Xcode schemes help to set up different customizable items: for example, app name, app icon, bundle ID, info.plist file. The same feature in Android Studio is called “Build Variants”.

However, you should pay attention to the fact that the more apps you will have, the more resource-consuming it will be to introduce any new updates.

Multi-Tenant White-Label Apps

The alternative option is multi-tenancy. This Saas model (Software-as-a-service) supports more users (tenants), and while the UI design of such apps is adjusted, the underlying platform remains the same for all tenants.

In this case, there is one server that hosts the software and stores customer data. Multi-tenant apps are usually a more popular choice simply because compared to single-tenancy, they’re an easier and cheaper option for companies. However, this means that all activities like updating, breaches, etc., are applicable to each app on the server.

Just like in the previous case, customers can customize features or design elements. However, here providers focus less on customization and personalization but more on quick development and cost-efficiency.

Thanks to a single configuration of these apps, maintenance, QA & testing are much faster. Additionally, you as a provider have only one application — bug fixes are also automatically applied to all of your tenants.

Since it’s likely that with the multi-tenant architecture of your white-label app, you’ll work with multiple clients at once, you can make it easier for both you and them by making a tenant onboarding guiding set, which can include videos, text guides, support specialists that will walk clients through each stage of the onboarding, etc.

Furthermore, if you choose multi-tenancy, we dare assume that you’d like to cover a bigger audience and not focus on UX (features, integrations) customization that much. This is why it might be a good idea to define what functionality and terms of coworking will be customizable in advance and place it somewhere on your website, landing page, or whatever it is you have.

This way, potential clients will know what to expect and, perhaps, will prepare questions about whether additional changes are negotiable or not — it can save both of you a lot of time.

It’s also essential because the list of customizable elements in such a model is normally limited to the ones that you’ve enabled at the development stage. In other words, your tenants can easily change a logo or a color palette but can’t do the same with a page layout or some specific features — unless you as a provider foresaw and made it possible when building your white-label product.

Single- & Multi-Tenancy: Use Cases

So, let’s briefly review some use cases when it might be more suitable for you to opt for one of two options.

Splash Screen can be assembled by using either images and logos that represent the main message of the brand and is consistent with it or an introductory animation.

Additionally, you can offer clients to add widgets or animation so that onboarding will be as custom as possible.

You should think out a couple more aspects as well:

• Will you allow changing the layout of logos and images, in addition to changing colors?
• Are you going to limit the set of customizable splash screen elements to what you offer or allow users to upload their own ones?
• If you offer to place a video on the splash screen, what the time limit is, what size the video can be. Moreover, you should think about screen adjustment since each has a different size - it can be easily enabled by using certain tools that your development team is most likely aware of.

Regarding an app icon, the concept is similar. You can offer to change the color, provide a wide range of icon construction kit elements so clients can make it in case they don’t have it yet, and allow them to upload their own icon design.

In-App UI Elements & Colors

To make the app as custom as possible and still keep all the benefits (like cost-efficiency) that make white-label apps demanded, you can make in-app UI features adjustable. This usually includes colors, fonts (type, style, size, position, etc.), and spacing.

Let’s review the coloring system in detail. Normally, white-label app providers offer a convenient and easy-to-use two-level color system. It means that there are two color pallets that are responsible for different parts of the app — let’s call them primary palette and secondary palette.

The primary color palette is used to change the color of the app’s main components like CAT buttons, action icons, links. Here, it’s not reasonable to limit the color choice since you never know what a customer might need.

However, what you can do is to ask your client what colors they’ll need and simply add them, without having to burden the app with additional ones that they’re not likely to use. If they prefer to have the whole palette — so be it. Furthermore, you can allow them to change the shades, saturation, brightness, transparency, etc.

The secondary palette is responsible for coloring most backgrounds, sections, etc. Here, you can add basic white and black with several shades from lighter to darker tones. This palette probably won’t be too heavy in terms of data so there’s no need to exclude some of them even if clients think that they won’t need it.

App Components & Templates

Components, in this context, include titles, CTA buttons, regular buttons that help users navigate the app, and other parts that form a screen.

Some designers also divide them into primary and secondary. For instance, a primary button would mean a bigger size with more distinct UI elements.

Secondary would mean that these are less important, thus, they’ll take up not much space and can be less distinct if needed. Surely, it’s up to your clients, yet, we’d recommend not having more than 1 primary button on the screen to not confuse users.

We would recommend opting for Google App Engine since they focus on applications specifically, but surely, the choice is up to you.

Another important aspect is reporting and fixing bugs. In fact, if you use hosting providers that offer a wider range of services like Google App Engine, it’ll likely be included in your subscription package.

Yet, if you decide to handle such aspects independently, you can use API and software providers like Santry or Bugsnag that handle everything related to the technical support of the app.

When using such services, you can tie all apps up to a single account and tag each one of them. So, when the error is being reported, you can track down which app caused it. If it’s a general issue on the server, it can be labeled accordingly.

Client Dashboard

We were talking a lot about how and what can be customized when providing white-label services. Now, we’d like to give you some tips on how the customization can be simplified and made more user-centric.

To easily manage the customization, you can build a client dashboard where both they and you have access to the app’s components.

As for Canvas, we've fully rebuilt navigation patterns so that they are more user-friendly. Currenlty, our team supports this project by fixing all emerging bugs.

With News, our job was more substantial since the initial product needed more modifications. First of all, we added an upper navigation tab so that users can use it to swipe to other screens.