Enterprises and organizations that manage products with overlapping feature sets often confront a unique challenge. Their core dilemma involves creating multiple branded mobile applications that share a common codebase while enabling each app to provide a distinct user experience with minimal development overhead. As a leader in custom mobile solutions, Perficient excels in white labeling mobile applications using the power and flexibility of Azure DevOps.
Tackling the White Label Challenge
Consider a scenario where your application has gained popularity, and multiple clients desire a version that reflects their own brand identity. They want their logos, color schemes, and occasionally distinct features, yet they expect the underlying functionality to be consistent. How do you meet these demands without spawning a myriad of codebases that are a nightmare to maintain? This post outlines a strategy and best practices for white labeling applications with Azure DevOps to meet this challenge head-on.
Developing a Strategy for White Label Success
White labeling transcends merely changing logos and color palettes; it requires strategic planning and an architectural approach that incorporates flexibility.
1. Application Theming
White labeling starts with theming. Brands are recognizable through their colors, icons, and fonts, making these elements pivotal in your design. Begin by conducting a thorough audit of your current style elements. Organize these elements into variables and store them centrally, setting the stage for smooth thematic transitions.
2. Establishing Your Default Configuration
Choosing a ‘default’ configuration is crucial. It sets the baseline for development and validation. The default can reflect one of your existing branded applications and acts as a unified starting point for addressing issues, whether related to implementation or theming.
3. Embracing Remote/Cloud Configurations
Tools like the Azure App Configuration SDK or Firebase Remote Configuration allow you to modify app settings without altering the code directly. Azure’s Pipeline Library also helps manage build-time settings, supporting flexible brand-specific configurations.
Using remote configurations decouples operational aspects from app logic. This approach not only supports white labeling but also streamlines the development and customization cycle.
Note: You can add your Brand from the step 2. Adding Your “Brand” Configuration to Your Build into your build artifacts, and reference the correct values in your remote configurations for your brand.
Coordinating White Labeled Mobile Apps with Azure Pipelines
With your application ready for theming and remote configuration, use Azure Pipelines to automate the build and release of your branded app artifacts. The structure of your build stages and jobs will depend on your particular needs. Here’s a pattern you can follow to organize jobs and stages for clarity and parallelization:
1. Setting Up Your Build Stage by Platforms
Organize your pipeline by platform, not brand, to reduce duplication and simplify the build process. Start with stages for iOS, Android, and other target platforms, ensuring these build successfully with your default configuration before moving to parallel build jobs.
Run unit tests side by side with this stage to catch issues sooner.
2. Adding Your “Brand” Configuration to Your Build
Keep a master list of your brands to spawn related build jobs. This could be part of a YAML template or a file in your repository. Pass the brand value to child jobs with an input variable in your YAML template to make sure the right brand configuration is used across the pipeline.
Here’s an example of triggering Android build jobs for different brands using YAML loops:
stages:
- stage: Build
jobs:
- job: BuildAndroid
strategy:
matrix:
BrandA:
BrandName: 'BrandA'
BrandB:
BrandName: 'BrandB'
steps:
- template: templates/build-android.yml
parameters:
brandName: $(BrandName)
3. Creating a YAML Job to “Re-Brand” the Default Configuration
Replace static files specific to each brand using path-based scripts. Swap out the default logo at src/img/logo.png with the brand-specific logo at src/Configurations/Foo/img/logo.png during the build process for every brand apart from the default.
An example YAML snippet for this step would be:
jobs:
- job: RebrandAssets
displayName: 'Rebrand Assets'
****:
vmImage: 'ubuntu-latest'
steps:
- script: |
cp -R src/Configurations/$(BrandName)/img/logo.png src/img/logo.png
displayName: 'Replacing the logo with a brand-specific one'
4. Publishing Your Branded Artifacts for Distribution
Once the pipeline jobs for each brand are complete, publish the artifacts to Azure Artifacts, app stores, or other channels. Ensure this process is repeatable for any configured brand to lessen the complexity of managing multiple releases.
In Azure, decide whether to categorize your published artifacts by platform or brand based on what suits your team better. Regardless of choice, stay consistent. Here’s how you might use YAML to publish artifacts:
- stage: Publish
jobs:
- job: PublishArtifacts
****:
vmImage: 'ubuntu-latest'
steps:
- task: PublishBuildArtifacts@1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop-$(BrandName)'
publishLocation: 'Container'
By implementing these steps and harnessing Azure Pipelines, you can skillfully manage and disseminate white-labeled mobile applications from a single codebase, making sure each brand maintains its identity while upholding a high standard of quality and consistency.
For more information about Perficient’s Mobile Solutions expertise, subscribe to our blog or contact our Mobile Solutions team today!
