You’ve likely heard about white-label websites.
It's a popular approach among small businesses that use platforms like Wix or WordPress to establish an online presence, as well as larger companies like AXUS who fuel their growth by white-labeling their products.
What you might not know is that the white-label approach is applicable to mobile apps too.
Mobile white-labeling is slightly more complicated than on web, however, I will:
show you the most common use cases for white-label mobile apps,
explain the risks and challenges related to this model, and finally
show how to seamlessly manage, build, and release multiple applications at once with Fastlane (Dear gentle reader: If you are a technical professional hungry for details, this is the section for you.)
By the end of this article, you’ll not only understand what white-label apps are but how they can fit into your business strategy.
Choosing the White-Label App Strategy for Your Business
White-label applications are customizable, generic apps that adapt to certain specifications set by the owner. The white-label creator provides a number of customizations, often offering creators monetization opportunities and cost-saving means for their buyers. Let’s take a look at the two most common use cases for the white-label apps.
1. Single app for a small business
A very common use case of white-label mobile apps is ordering a single app built from an already existing blueprint. Such a model gives smaller businesses with constrained budgets an opportunity to enter the mobile market at a fraction of the cost of building a custom app. In such scenarios, the buyer doesn’t fully customize its product and will remain dependent on the provider of the blueprint.
A quick Google search will yield dozens of companies offering to build a white-label mobile app at a fraction of the cost of maintaining a development team. If a low-cost single app is what you’re after, and you’ve found a provider whose customization options suit your needs, this solution is worth considering. Just remember to discuss with the potential provider how to avoid falling into the cloned app trap (see Avoiding the Cloned App Trap section below).
2. A set of white-label apps for a bigger business
In this scenario, the buyer is interested in having ownership and control over the white-label blueprint so that they can build multiple apps for their business, regardless of whether they are in the same service category or not.
When it comes to real-life examples, it can be hard to tell if an app is a white-label unless the source code is accessible. However, let’s take a look at the similarities between San Clemente Palace Kempinski and Çırağan Palace Kempinski apps. The similarities between them might suggest that we’re dealing with white-label apps.
Avoiding the Cloned App Trap
When purchasing and developing white-label applications, it's crucial to understand the substantial business risk associated with this model. An app that closely resembles others on the Play Store and Apple Store might face issues with release approval.
Unlike the web, where nearly anything can be published, the vast majority of mobile apps are released through two primary channels: the Google Play Store for Android and the App Store for iOS. Each platform has its own terms and conditions to release an app. Before public release — and even before test release — each app undergoes a review process, which if found out of compliance, may be blocked. One specific requirement of these stores presents a significantly greater risk for white-label apps compared to custom apps: duplication, also known as spam. If white-label apps are too similar in content, design, or functionality, they risk being flagged for duplication.
Let’s take a look at the exact wording of the Apple and Google Play stores' T&Cs that introduce this limitation.
(a) Don’t create multiple Bundle IDs of the same app. If your app has different versions for specific locations, sports teams, universities, etc., consider submitting a single app and provide the variations using in-app purchase. [Applies to notarization of iOS apps in the EU] (b) Also avoid piling on to a category that is already saturated (...) We will reject these apps unless they provide a unique, high-quality experience. Spamming the store may lead to your removal from the Apple Developer Program.
We don't allow apps that merely provide the same experience as other apps already on Google Play. Apps should provide value to users through the creation of unique content or services. Examples of common violations: Copying content from other apps without adding any original content or value. Creating multiple apps with highly similar functionality, content, and user experience. If these apps are each small in content volume, developers should consider creating a single app that aggregates all the content.
The best course of action to go about this risk depends on the business scenario.
If you are planning to purchase an app which has been created off a blueprint, you should expressly discuss this risk with the provider and agree what will happen shall your app be not allowed to be released or be taken down.
If you are considering purchasing the entire blueprint to create multiple white-label apps then you should consider if the white-label solution is indeed the best solution for you — wouldn’t a versatile app be a better (cheaper and less risky) solution?
In either case, if you decide that white-label is the best way to go for you, here are some tips on how to make sure your app passes the review process when it comes to this key requirement.
5 Tips to Ensure Your White-Label App Meets the Originality Requirement
1. Unique icon and name
Similar icons and app names can instantly raise a flag with the reviewers as your app(s) appear as a copy of an existing app. Ensure that their style is unique and avoid having names follow the same pattern unless absolutely necessary.
2. Unique audience with different needs
Make sure to highlight the fact that the apps have different audiences with different needs. For example, it wouldn’t make sense for a fitness chain to offer separate apps for each gym location, as users may visit a few locations and want to access them in the same app. On the other hand, it makes sense for a school district to maintain separate apps as their users are typically only interested in one school at a time.
3. Unique content
Make sure that each application has different content. Data across apps might come from one source (e.g., API), but its usage should be tailored to the specific needs of each app, ideally limiting the scope of data to what is necessary. Make sure that the copies and links are unique too.
4. Unique but simple design
Provide multiple options to customize the app, such as assets, colors, fonts, shapes, and sizes. If you are working with a white-label blueprint, make sure designers take into consideration the special nature of the app to ensure that all of the elements fit with each other in all configurations. It’s also important to remember that the white-label applications will be built in an automated pipeline (see the Fastlane section for more details), so you should limit any unnecessary complexity.
5. Unique features
Where possible, a good white-label blueprint should offer an option to request additional features which can be tailored to the specific needs of a particular client. This not only helps with proving the uniqueness of the app but also provides a custom experience in a white-label process. Doing so gives you and users the best of both worlds.
Preparing, Building, and Releasing White-label Applications with Fastlane
Now that you’ve decided that the white-label format is for you, you might wonder how you can effectively manage 5, 10, 15, or 50 applications without a large support budget. Don’t worry! Fastlane, a platform aimed at simplifying Android and iOS deployment, allows you to run custom scripts and offers a ton of ready-made tools such as actions and plugins for building, releasing, and updating mobile apps.
In the following section, I provide additional information about how to take advantage of Fastlane when dealing with white-label mobile apps
The Basics
The use of Fastlane is very similar to CI tools where “lanes” (steps) are defined in order to run one or multiple tasks simultaneously. Imagine you have two white-label applications and store their config in an app_config.json file.
{
"apps": [
{
"name": "App1",
"bundleId": "com.myapps.app1",
// other config
},
{
"name": "App2",
"bundleId": "com.myapps.app2",
// other config
}
]
}
In a Fastfile, where Fastlane steps are defined, you’ll iterate over the list of your apps and for each app you'll do the actions necessary to build and release it. Exciting!
lane :build_apps do
config_path = File.expand_path("app_config.json", __FILE__)
app_config = JSON.parse(File.read(config_path))
app_config["apps"].each do |app|
# steps eg. assets preparation, build, release
end
end
Et voilà! That's the backbone of our Fastlane pipeline.
App Renaming
Let's start with the first challenge - setting the apps' names. Each application needs a unique name and bundle ID which will then be widely used within the code in the file names and imports. Since all apps are built from the same blueprint, we need a tool that will rename all files and imports to match the name of a given app.
Manually it would take a really long time but you can save time using react-native-rename on Fastlane.
Although react-native-rename updates the vast majority of files, users have reported issues with imports and packages renaming on its Github repo. If you face issues, two steps can help. First, make sure you are on a recent, stable version. Then identify all files where the update was not made. Once you have them, you can write a custom Ruby function to target the remaining files. The ability to run custom scripts is one of Fastlane’s biggest strengths.
So you might wonder is there a point in using react-native-rename if errors may arise and I have to write a manual script? My answer is definitely yes! This package covers the vast majority of renaming (if not all) and ruby scripting easily covers the remaining cases.
Icons
As discussed, each of your applications will need a unique app icon. You can generate icons required by iOS and Android apps, and store all sizes via a master application icon. All you need to do is upload a 1024x1024px icon (no alpha layer) to the appicon plugin. Take a look at this sample implementation:
appicon(
appicon_devices: [:iphone, :ios_marketing],
appicon_image_file: "./fastlane/metadata/#{options[:app_name]}.png",
appicon_path: "./ios/#{options[:app_name]}/Images.xcassets",
)
android_appicon(
appicon_image_file: "./fastlane/metadata/#{options[:app_name]}.png",
appicon_icon_types: [:launcher],
appicon_path: "./android/app/src/main/res/mipmap",
generate_rounded: true,
)
Bootsplash
Each app should also have a distinctive bootsplash. You can generate them for each app by using react-native-bootsplash. Similarly to react-native-rename, it’s not exclusively a Fastlane-only tool but can be successfully called as part of the Fastlane pipeline.
Create the App in Apple Store
Next use Fastlane’s produce action to create a new iOS app on App Store Connect and Apple Developer Portal; with just one line you can get your app added. The produced action also is smart enough not to run when your app is already in the store. This is the minimal sample setup:
produce(
username: your_user_name,
app_identifier: bundle_id,
app_name: "#{app_name}",
language: "en-US",
app_version: "1.0",
sku: bundle_id
)
Create the App in Play Store
Unfortunately, there is no action that serves the same purpose for Google Play store. Each time you’d like to release a new application to the Play Store, you’ll have to go through a manual step of clicking through a form on Google Play Store’s website, which takes several minutes to complete.
Use Fastlane Match to Handle Code Signing for iOS
Releasing iOS apps requires signed code. For code signing at scale, unify the process with Fastlane match. As explained in its documentation, it “creates all required certificates and provisioning profiles and stores them in a separate git repository, Google Cloud, or Amazon S3. Every team member with access to the selected storage can use those credentials for code signing. match also automatically repairs broken and expired credentials.” Sample minimal implementation is as follows:
match(
type: "appstore",
app_identifier: bundle_id,
git_url: "",
git_branch: "",
username: your_user_name,
)
Versioning
In order to version the builds you can use ready-made Fastlane actions. For iOS, use latest_testflight_build_number to fetch the most recent build number from TestFlight and increment_build_number action to increment the build number of your project.
For Android, you can fetch the version codes with google_play_track_version_codes and then find the last build number, increment it and replace it with old school scripting.
Build and Release for iOS
Finally, Fastlane assists with building and releasing apps. For iOS, the build can easily be done with the gym action. It compiles the code and creates an executable app from your source files. It doesn’t require any arguments to run its default variant with fastlane gym but there are multiple parameters that you can use like which device to build for, the configuration (e.g., Debug or Release), and where to save the app file. Once built, gym packages your app so it's ready for distribution to testers or the App Store.
When using gym, it’s important to note the tool is highly dependent on Xcode. It uses Xcode's command-line tools (xcodebuild) to compile the source code, link it, and create the app executable. It also uses the settings and schemes defined in your Xcode project. It essentially automates the same steps you would manually perform in Xcode. However, if you are having issues with building via Xcode and are looking for an alternative, this is not it. Use gym to automate building multiple applications, not as an alternative to Xcode.
Lastly, you can use Fastlane’s upload_to_testflight (aka pilot action) to release the app to TestFlight. Instead of manually using Xcode or the App Store Connect interface, you can use a simple command to upload your build.
A sample implementation of these tools might look like this:
lane :test_release do
gym
pilot(
skip_submission: true,
skip_waiting_for_build_processing: true
)
end
Build and Release for Android
Building on Android is even easier than on iOS as you can use Fastlane’s gradle integration, which provides all Gradle-related actions, including building and testing your Android app. All you need to do to build an AAB is:
gradle(
task: "bundle",
build_type: "Release",
project_dir: "./android",
)
And then to upload your APK or AAB files to the Google Play Store, you can use the upload_to_play_store (aka supply action). It handles the uploading APKs, updating metadata, and managing in-app purchases.
supply(
package_name: bundle_id,
track: "internal",
aab: aab_path,
json_key: "./temp.json",
)
Conclusion
The white-label approach for mobile applications offers numerous benefits to all stakeholders, particularly when enhanced by Fastlane for automated build and release processes. It saves development time and reduces cost, ensures stable build and release processes, while providing an easy way to manage multiple products by non-developers.
Whether you are the purchaser or the developer, it is crucial to understand the additional risks, challenges, and prerequisites associated with developing and deploying white-label mobile applications. If you’d like to discuss this in more detail, contact us.
