I have a project which I'd like to white label. Basically only icons, launch images and info.plist have to be changed. The problem is that project is too big and I really don't want to add additional targets and resources to it.
The solution I see is to create a separate project and add the first one as a dependency project. This white labeling project would have no code but a bunch of targets with different images and info.plists for them. In this case every time I want to white label the app I would just create another target with its own set of images. And whenever I want to make another release I could easily build all of those targets and get a bunch of variations for the same app. Sounds easy.
The problem is in implementation. I linked the project as a dependency so did I the same with target. But every time I build the app it creates an executable with the original name, even though it is different in info.plist. Probably this is because original target has its own info.plist. Another thing is how to replace the resources from the original target with another ones.
Appreciate any help
I currently manage a whitelabeled iOS app. We add targets for each white label client to the main project, and have made most parts of our app configurable via a Theme.plist
file.
So, each target includes all the classes for the app but has custom Info.plist
, icons, launch screens, font files, and Theme.plist
.
We avoided the approach that @dtrotzjr mentioned above because there were a few things outside of the Info.plist
file that we needed to change per target... the Provisioning Profile being a good example as well as preprocessor macros to handle the occasional #ifdef
for per-client hacks.
It also made it easier for new devs to understand the build process.
I did this at my job and how I did it is I have a python script that I wrote that goes in and manipulates the Info.plist with a list of replacement values that I store in an alternative plist file. We also have a build step script that goes and injects any resources we need for that particular build.
You can manipulate the bundle all you want but you have to do it just before Xcode signs the app. In some cases you might want to go in and edit the Info.plist in the bundle as well which is fine, just do it before the signing step.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With