• Initialization
• Switching Brands
• Configuration Injection Approach
• File Structure Overview
  • Common Configurations
  • iOS Brand Configurations
  • Android Brand Configurations
  • Flutter Brand Configurations
• Summary

Upon initialization, as detailed in the Getting Started section, Solara generates a solara/ folder in the project's root directory:

my_app/
  └── solara/
        └── brands/
              ├── brands.json
              ├── current_brand.json
              └── INITIAL_BRAND_KEY_HERE

It's important to understand the approach used by Solara for managing dynamic configurations. Solara organizes all dynamic configurations for each brand within a dedicated folder named after the brand's key (e.g., brand1/). The brands, such as brand1/, brand2/, etc., are located inside the brands folder, all encapsulated in the solara/ folder in the project's root directory.

my_app/
  └── solara/
        └── brands/
              ├── brands.json
              ├── current_brand.json
              ├── brand1/
              ├── brand2/
              ├── brand3/
              ├── brand4/
              ├── key../
              └── key../

Every brand is represented with a key and name in solara/brands.json:

{
    "brands": [
        {
            "key": "brand1",
            "name": "Brand 1"
        },
        {
            "key": "brand2",
            "name": "Brand 2"
        }
    ]
}

• key: A unique string for the brand. All brand-specific commands depend on this key. It must start with at least a letter and contain no spaces. The configurations are located in a folder with that key.

• name: Used for identifying the brand within Solara only. It can contain spaces, numbers, or any symbol, and it is not used in the product app.

  It's important to note that the key and name are used exclusively within the Solara context and do not impact the final product. The actual brand configurations, including the name, are stored in the brand configuration files.

This approach ensures efficient management and easy access to brand-specific settings.

Now that we understand the solara structure, we need to know how to apply a specific brand's configurations in our codebase, allowing us to run that brand with all its specific settings. This process is called Brand Switching in the context of Solara.

Upon switching, Solara performs the following important steps:

• Generates the brand configuration components and places them in target artifacts folders in the target project.
• Moves the brand resources into their target artifacts folders.
• Dynamically injects configurations into the target project (e.g., iOS). For instance, the AppIcon in iOS should be referenced from the artifacts folder.

By executing these steps, the codebase is prepared to run with the new brand configurations, including theme, app icons, brand name, and more.

The artifacts folders are crucial in this approach as they are Git-ignored. Keeping these folders out of version control allows for seamless switching between brands without altering the Git status. This helps avoid conflicts, especially in team environments with multiple developers, ensuring a smoother collaborative workflow.

Solara doesn't hardcode the configurations of the brand in the target code. Instead, it references the dynamic configurations from the auto-generated files. Let's explain this with an example in Android and another in iOS.

• In Android, the generated dynamic configurations are located in artifacts/brand.properties. When we need to change a configuration such as applicationId, Solara generates this to reference the configurations from brand.properties.

defaultConfig {
    applicationId = project.ext.brandProperties.getProperty('applicationId')
    versionCode = project.ext.brandProperties.getProperty('versionCode').toInteger()
    versionName = project.ext.brandProperties.getProperty('versionName')
}

• In iOS, the generated dynamic configurations are located in Artifacts/Brand.xcconfig. This config is set as the base config for all Xcode configurations. When we need to change a configuration such as PRODUCT_BUNDLE_IDENTIFIER, Solara generates this to reference the configurations from Brand.xcconfig.

config.build_settings['PRODUCT_BUNDLE_IDENTIFIER'] = '$(PRODUCT_BUNDLE_IDENTIFIER)'

$(PRODUCT_BUNDLE_IDENTIFIER) is referring to the value from Brand.xcconfig.

solara/
 └── brands/
      ├── current_brand.json
      ├── brands.json
      └── brand1/
            ├── android/
            │   ├── assets/
            │   ├── res/
            │   ├── android_config.json
            │   └── android_signing.json
            │
            ├── ios/
            │   ├── assets/
            │   ├── ios_config.json
            │   └── ios_signing.json
            │
            └── shared/
                ├── assets/ // For Flutter only
                ├── brand_config.json
                └── theme.json

• current_brand.json: Contains the key of the currently switched brand, used internally by Solara.

• theme.json: Defines brand colors.

  {
    "light": {
      "primary_color": "0xFF2196F3"
    },
    "dark": {
      "primary_color": "0xFF1976D2"
    },
    "shared": {
      "error_color": "0xFFFF0000"
    }
  }

• brand_config.json: Contains configurations for the brand. The content of this file is moved to an auto-generated file when switching brands. Basic configurations like PRODUCT_NAME are auto-added during generation.

The generated file based on the platform:

• BrandConfig.swift for iOS
• BrandConfig.kt for Android
• brand_config.dart for Flutter
  The class name is BrandConfig.

• assets: Holds the iOS assets, including AppIcon.appiconset, LaunchImage.imageset, etc. All contents of this folder are copied to the iOS Assets folder when switching brands.

• ios_config.json: Contains basic configuration for the iOS app.

  {
    "PRODUCT_NAME": "",
    "PRODUCT_BUNDLE_IDENTIFIER": "",
    "MARKETING_VERSION": "1.0.0",
    "BUNDLE_VERSION": "1",
    "APL_MRCH_ID": ""
  }

• assets: Holds the Android assets. All contents of this folder are copied to the Android src/main/assets folder when switching brands.

• res: Contains Android resources, which may include directories like mipmap, drawable, etc.

• android_config.json: Holds the basic configuration for the Android app.

  {
      "brandName": "",
      "packageName": "",
      "versionName": "1.0.0",
      "versionCode": "1",
      "sourceSets": []
  }

• signing.json: Contains the configuration for code signing.

  {
      "storeFile": "",
      "keyAlias": "",
      "storePassword": "",
      "keyPassword": ""
  }

• shared/: Contains configurations shared between iOS and Android platforms.

• assets: Holds the Flutter assets. All contents of this folder are copied to the Flutter /assets folder when switching brands.

This structured overview of the Solara approach to brand configuration ensures that all necessary steps and file structures are clearly outlined, facilitating easier implementation and understanding for developers.