I've done this on a small scale for web, never for mobile/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's essentially using git as the build tool.
If I were to do it again I'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.
Make sure you talk to your clients about what their branding requirements are. Some companies get very very specific about what they 'need' and as soon as you offer the ability to customise something they can get irritated if their brand doesn'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.
You didn't say if the white labeled app would be a public download of it it's intended for company staff. If it's the latter you can probably have a single app that gets configured on the first start up, i.e. it's blank when you open it, sign in and it pulls in the required config and then takes on the customer's brand.