Modifying Brand Primitives

Hardcoding hex values into individual UI components is a legacy practice that guarantees a degraded user experience and massive maintenance headaches. Our templates operate on a strict, centralized theme engine driven by Material Design 3 (M3) specifications.

To modify the visual identity of the application, you must intercept the theme generation at the root level.

1. Locate the core theme configuration file (typically lib/core/theme/app_theme.dart).
2. Redefine the primary seed colors. By supplying a foundational hex value—such as your brand’s specific #0d6efd blue—the M3 engine automatically algorithmically generates the entire tonal palette for light and dark modes.

Dart

// The correct architectural approach to overriding brand primitives
final ThemeData lightTheme = ThemeData(
  colorScheme: ColorScheme.fromSeed(
    seedColor: const Color(0xFF0D6EFD), // Your primary brand color
    brightness: Brightness.light,
  ),
  useMaterial3: true,
);

Never manually override a color on a deeply nested widget unless absolutely necessary for a highly specific, contextual UI state. Trust the centralized engine.

Re-Engineering Application Identifiers

You cannot deploy an application to production using the default Stacklyn Labs identifiers. The Android Package Name (e.g., com.stacklynlabs.memberkeep) and the iOS Bundle ID must be uniquely mapped to your organizational domain.

Attempting to change these identifiers via a manual text search is a notoriously error-prone process that routinely corrupts native build files. We mandate the use of automated identifier re-engineering.

1. Utilize industry-standard CLI tools like rename_app or change_app_package_name.
2. Execute the rename command from your project root:
   Bash
   flutter pub run change_app_package_name:main com.yourcompany.yourapp
3. After execution, you must aggressively flush your local caches. Run flutter clean, followed by a full pod install in the iOS directory to ensure the native layers compile against the new schema.

The Asset Swapping Protocol

The physical assets of your application—specifically the launcher icons and native splash screens—exist outside the Dart runtime. They live in the highly opinionated native Android and iOS directories.

Replacing these manually requires generating over twenty different resolution variants, a massive time-sink that derails project timelines. Instead, utilize the programmatic asset pipelines baked into our architecture.

• App Icons: Replace the master icon.png in your assets/ directory. Run the flutter_launcher_icons package to auto-generate and distribute the correct pixel densities across both native platforms.
• Splash Screens: The native splash screen must render instantly, before the Flutter engine even initializes. Modify the flutter_native_splash.yaml configuration file with your brand’s hex background and logo path, then execute the generation script to bridge the native delay.

Localization Mapping: Rejecting Hardcoded Strings

If your application relies on strings hardcoded directly into Text() widgets, you are building a rigid, unscalable product. Stacklyn Labs architectures treat copy as dynamic data.

All user-facing text is routed through a centralized localization registry. To re-brand the application’s text or deploy to a new region:

1. Navigate to the lib/l10n/ directory.
2. Modify the standard .arb (Application Resource Bundle) files.
3. Run the Flutter generation command (flutter gen-l10n) to compile these raw strings into strictly typed, null-safe Dart accessors.

This ensures that a missing translation throws a compile-time error, rather than failing silently in production on a user’s device.