I&#x27;ve done this on a small scale for web, never for mobile&#x2F;apps though. My approach was a git repo containing the main code then a branch for each brand which only had config changes. It  works ok but gets difficult to manage once your size grows - it&#x27;s essentially using git as the build tool.<p>If I were to do it again I&#x27;d likely not use the branches for branding config, but keep them all in one place and use a build tool to make sure the required settings are in place and merged before deployment. As long as you tag your releases you can fix certain clients to certain releases.<p>Make sure you talk to your clients about what their branding requirements are. Some companies get very very specific about what they &#x27;need&#x27; and as soon as you offer the ability to customise something they can get irritated if their brand doesn&#x27;t look quite right. As others have said make all of these customisations part of a config file and just reference that in your code. Once you start making specific changes for a client your life becomes difficult and you end up managing a specific bunch of code just for them.<p>You didn&#x27;t say if the white labeled app would be a public download of it it&#x27;s intended for company staff. If it&#x27;s the latter you can probably have a single app that gets configured on the first start up, i.e. it&#x27;s blank when you open it, sign in and it pulls in the required config and then takes on the customer&#x27;s brand.