If you develop a white-label app, you\u2019ve probably faced some challenges when a client asks for a specific SDK (Software Development Kit) for analytics, deep links, or other features, and wondered how to offer multiple SDK options to different clients without increasing your app\u2019s size or compromising its stability. <\/p>\n\n\n\n
In this article, we\u2019ll explore how to solve this problem specifically in cross-platform projects. Whether you’re building with React Native<\/a> or Flutter<\/a>, the goal is the same: to create a modular architecture that lets you enable or disable SDKs per client while keeping your white-label app lightweight, stable, and easy to maintain.<\/p>\n\n\n\n When building a solution like that in a cross-platform white-label app, some challenges need to be addressed:<\/p>\n\n\n\n Read more:<\/strong> How to Create a React Native App Using Typescript<\/a><\/p>\n\n\n\n One effective way to handle build-time dependency management is by using a shell script that dynamically installs or removes SDKs based on environment variables. Before the build starts, the script can read flags such as ANALYTICS_ENABLED<\/mark>, DEEPLINK_ENABLED<\/mark>, and any client-specific configuration, and run commands like yarn add or yarn remove accordingly.<\/p>\n\n\n\n This ensures that only the required SDKs are included in the project for that particular build.<\/p>\n\n\n\n In the React Native ecosystem, this challenge is greatly simplified thanks to Expo Prebuild<\/a> and Expo Config Plugins<\/a>. With it, you can generate native code that includes only the SDK plugins required for a specific build. By wrapping the plugin definition in an environment-dependent condition (process.env.KLAVIYO_ENABLED<\/mark><\/strong>), the SDK is only included when required for that specific build. This lets each client\u2019s app include only the native integrations they need, without adding extra code or unnecessary dependencies.<\/p>\n\n\n If an SDK doesn\u2019t provide an official Expo plugin, you can still take advantage of this workflow by creating your own custom plugin. Check this documentation<\/a> for Expo Config Plugins mods.<\/p>\n\n\n\n When you remove a dependency at build time, any direct imports of that package in your files fail since the library is no longer installed. This can break the build or cause runtime errors if not handled properly. Having a unified abstraction layer keeps your code clean and prevents you from calling each SDK directly. For example, if you have multiple analytics SDKs, you can create an abstract analytics adapter and a global analytics class that will handle all the necessary analytics methods. This way, the rest of your white-label app interacts with one unified interface.<\/p>\n\n\n\n If your SDK doesn\u2019t require custom native code, you are good. Just abstract the imports and the adapters’ logic.Challenges to Solve<\/h2>\n\n\n\n
\n
Managing dependencies at build time<\/h2>\n\n\n\n
Ensuring unused native code is completely excluded<\/h2>\n\n\n\n
Below is an example using the Klaviyo SDK. When expo prebuild runs, it generates the native iOS and Android projects automatically, including all the Klaviyo configuration, so you don\u2019t need to write or maintain any native code yourself.<\/p>\n\n\n\n\/\/ app.config.js<\/span>\n{\n\u00a0 expo<\/span>: {\n\u00a0 \u00a0 name<\/span>: 'My app'<\/span>,\n\u00a0 \u00a0 ios<\/span>: {...},\n\u00a0 \u00a0 android<\/span>: {...},\n\u00a0 \u00a0 plugins<\/span>: [\n\u00a0 \u00a0 \u00a0 process.env.KLAVIYO_ENABLED && [\n\u00a0 \u00a0 \u00a0 \u00a0 'klaviyo-expo-plugin'<\/span>,\n\u00a0 \u00a0 \u00a0 \u00a0 {\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 version<\/span>: process.env.APP_VERSION,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 ios<\/span>: {\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 buildNumber<\/span>: process.env.APP_BUILD_NUMBER,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 bundleIdentifier<\/span>: process.env.BUNDLE_ID,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 infoPlist<\/span>: {\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 UIBackgroundModes<\/span>: ['remote-notification'<\/span>],\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 },\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 badgeAutoclearing<\/span>: true<\/span>,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 codeSigningStyle<\/span>: 'Manual'<\/span>,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 devTeam<\/span>: process.env.APP_TEAM_ID,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 },\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 android<\/span>: {\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 package<\/span>: process.env.PACKAGE_NAME,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 openTracking<\/span>: true<\/span>,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 logLevel<\/span>: 1<\/span>,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 notificationIconFilePath<\/span>: '.\/assets\/images\/icon.png'<\/span>,\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 },\n\u00a0 \u00a0 \u00a0 \u00a0 },\n\u00a0 \u00a0 \u00a0 ]\n\u00a0 \u00a0 ],\n\u00a0 }\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nHandling dynamic dependency imports<\/h2>\n\n\n\n
With that, one thing you can do is add to your shell script a capability to also create a dynamic SDK mapping file. For example:<\/p>\n\n\n\/\/ No SDK installed<\/span>\nconst<\/span> sdks = {\n firebase<\/span>: undefined<\/span> as<\/span> any,\n klaviyo<\/span>: undefined<\/span> as<\/span> any\n}\n\nexport<\/span> const<\/span> firebase = sdks.firebase\nexport<\/span> const<\/span> klaviyo = sdks.klaviyo\n\nexport<\/span> default<\/span> sdks<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\/\/ With the SDKs installed<\/span>\nimport<\/span> { Klaviyo } from<\/span> 'klaviyo-react-native-sdk'<\/span>\nimport<\/span> { getAnalytics, logEvent } from<\/span> '@react-native-firebase\/analytics'<\/span>\n\nconst<\/span> sdks = {\n firebase<\/span>: { getAnalytics, logEvent },\n klaviyo<\/span>: Klaviyo\n}\n\nexport<\/span> const<\/span> firebase = sdks.firebase\nexport<\/span> const<\/span> klaviyo = sdks.klaviyo\n\nexport<\/span> default<\/span> sdks<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Then, rely on this file to handle the SDK imports safely, ensuring your code never breaks when a dependency is missing.<\/p>\n\n\n\nProviding a unified abstraction layer<\/h2>\n\n\n\n
The main Analytics<\/mark><\/strong> <\/mark>class then decides which SDKs to load based on the configuration, while each SDK (like Klaviyo) just implements the shared contract.<\/p>\n\n\nabstract<\/span> class<\/span> AnalyticsAdapter<\/span> <\/span>{\n abstract<\/span> logEvent(event: string, payload: Record<string, any>): void\n abstract<\/span> initialize(config: any): Promise<void>\n}\n\nenum AnalyticsAdapterType {\n DEFAULT<\/span> = 'default'<\/span>,\n KLAVIYO = 'klaviyo'<\/span>,\n ...\n}\n\nclass<\/span> Analytics<\/span> extends<\/span> AnalyticsAdapter<\/span> <\/span>{\n type: AnalyticsAdapterType = AnalyticsAdapterType.DEFAULT<\/span>\n private<\/span> adapters: AnalyticsAdapter[] = []\n\n logEvent(event: string, payload: Record<string, any>): void {\n this.adapters.forEach<\/span>(adapter => adapter.logEvent(event, payload))\n }<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\nasync<\/span> initialize(config: any): Promise<\/span><void<\/span>> {\n \/\/ create adapter instances<\/span>\n if<\/span> (config.klaviyo.enabled && process.env.KLAVIYO_ENABLED) {\n this<\/span>.adapters.push(new<\/span> KlaviyoAnalytics())\n }\n\n \/\/ initialize all adapters<\/span>\n this<\/span>.adapters.forEach(adapter<\/span> =><\/span> \nadapter.initialize(config[adapter.type]))\n }\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\nimport<\/span> Klaviyo from<\/span> 'sdks'<\/span>\n\nclass<\/span> KlaviyoAnalytics<\/span> extends<\/span> AnalyticsAdapter<\/span> <\/span>{\n type<\/span>: AnalyticsAdapterType = AnalyticsAdapterType.KLAVIYO\n logEvent(event: string, payload<\/span>: Record<string, any>): void<\/span> {\n \/\/ ... Klaviyo SDK methods<\/span>\n }\n async<\/span> initialize(config: any): Promise<\/span><void<\/span>> {\n Klaviyo.initialize(config.key)\n }\n}<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\nHow to do it on Flutter or bare React Native?<\/h2>\n\n\n\n
However, if you do need to modify native files, things become more complex. In those cases, you can create scripts to patch Android and iOS files, build a wrapper module to encapsulate the native logic, rely on mechanisms like Android\u2019s manifest merging, or even try to use tools like XcodeGen<\/a>.
Unfortunately, there are no equivalent tools like Expo Prebuild that simplify this workflow for Flutter or bare React Native.<\/p>\n\n\n\n