locked
Two apps, same functionality but different branding? (Product Flavors?)

    Question

  • I would like to release two versions of my application. The implementation is basically the same but with a different branding.

    So there may be different texts, images, resources, API endpoints. Also it should have its own Package.appxmanifest and Package.StoreAssociation.xml since these are going to be different for two different store builds.

    In the end I'm looking for something like "Product Flavors" on Android.

    Android Product Flavors

    "A product flavor defines a customized version of the application build by the project. A single project can have different flavors which change the generated application."

    It offers the functionality to overwrite basically everything you want to for each different product flavor.

    Is there a way to create something like different build targets to overwrite any files I want to?

    I think creating different projects won't be an options since the project is a Universal Project which already has 2 projects with a shared library. I would need to create 2 sub-projects for each of them to achieve such functionality?!


    • Edited by sust86 Thursday, November 27, 2014 3:07 PM
    Thursday, November 27, 2014 3:05 PM

Answers

  • There isn't anything like Product Flavours, but here's how I do it:

    Put all your code in one (or more) project, and have separate solutions for your different app versions. These solutions can just contain the images, package info, resources, etc. for that 'brand', and the code will come from simply importing the project you keep all your code in.

    Being a Universal App shouldn't make a difference - just have a separate Universal solution for each brand, and reference the shared code project as usual.

    You could possibly have one solution including multiple brand projects (containing only data/images/etc. for that brand), then only enable the project for the brand you want to build the app for.

    And if your branding is simple (i.e. not much graphics or large amounts of data) you could include it all in the same project/solution or perhaps use conditional compiling. I have an app with multiple brandings and all the data is kept in a single data file (the user can change the 'branding' at runtime, which changes the colours, online data sources, etc).


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Friday, November 28, 2014 10:53 AM

All replies

  • There isn't anything like Product Flavours, but here's how I do it:

    Put all your code in one (or more) project, and have separate solutions for your different app versions. These solutions can just contain the images, package info, resources, etc. for that 'brand', and the code will come from simply importing the project you keep all your code in.

    Being a Universal App shouldn't make a difference - just have a separate Universal solution for each brand, and reference the shared code project as usual.

    You could possibly have one solution including multiple brand projects (containing only data/images/etc. for that brand), then only enable the project for the brand you want to build the app for.

    And if your branding is simple (i.e. not much graphics or large amounts of data) you could include it all in the same project/solution or perhaps use conditional compiling. I have an app with multiple brandings and all the data is kept in a single data file (the user can change the 'branding' at runtime, which changes the colours, online data sources, etc).


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Friday, November 28, 2014 10:53 AM
  • Hello pumpkinzwan, your answer has really interested me because I'm confronted to a similar problematic.

    I have developed an Universal App Windows 8.1/Windows Phone 8.1. This app must be purposed in several versions: 
    - a default one: default name, default assets (icons, splashscreen, ...) and default UI colors 
    - customized versions: other name, other assets, other UI colors

    The customized version will be deployed for some clients which want to have their own app on the store.

    I first thought that I could do it through "pre build" steps but I need to change all items of the  manifest file, and I don't know how to manage the "Store association".

    I think now use PCL to do it, but I don't know what is the best way to convert my Windows / Windows Projects into Portable Class Libraries...

    - In my case, what is the best method for you?

    - Do you have samples for managing it with conditionnal compiling?


    Tuesday, March 31, 2015 2:31 PM
  • I'm still trying to come up with a perfect solution.

    The biggest issue is all the image assets (e.g. the tile icon, etc.). I haven't figured out a way to dynamically change the tile and store images or app package name. To overcome this I am using a mostly empty project that contains all that stuff and just calls a separate main project and passes along an object containing the other branding details (colour scheme, app name, etc.).

    So my apps have a branded project and a main project. You can build the main project separately and add a reference to it to your main solution (which contains only the branded components and no actual code or pages).

    In a sense the branded project serves as a 'head' to your app. It's essentially empty.

    I have no experience with pre-build steps, but you should be able to swap out the tile images. I will look into that myself as it may be a more elegant solution than what I'm using.

    You could set up conditionali compiling (you need to create different compile options like 'ReleaseBrandA', then in your code you can do this:

    #if ReleaseBrandA

    // brand A specific code

    #endif

    If you build your app with enough foresight you can probably avoid that by keeping any brand-specific code in the branded project.


    I'm a self-taught noob amateur. Please take this into account when responding to my posts or when taking advice from me.

    Wednesday, April 01, 2015 12:39 AM