Se voc\u00ea desenvolve um app white-label, provavelmente j\u00e1 passou por isso: um cliente pede um SDK (Software Development Kit) espec\u00edfico para analytics, deep links ou outras features, e voc\u00ea fica se perguntando como oferecer v\u00e1rias op\u00e7\u00f5es de SDK para clientes diferentes sem aumentar o tamanho do app nem comprometer a estabilidade. <\/p>\n\n\n\n
Neste artigo, voc\u00ea vai ver como resolver esse problema em projetos cross-platform. Seja com React Native<\/a> ou Flutter<\/a>, o objetivo \u00e9 o mesmo: criar uma arquitetura modular que permita ligar ou desligar SDKs por cliente, mantendo o app white-label leve, est\u00e1vel e f\u00e1cil de manter.<\/p>\n\n\n\n Ao montar uma solu\u00e7\u00e3o assim em um app white-label cross-platform, alguns desafios precisam ser enfrentados:<\/p>\n\n\n\n Leia tamb\u00e9m:<\/strong> Como criar um app React Native usando TypeScript<\/a><\/p>\n\n\n\n Uma forma eficaz de resolver o gerenciamento de dependencies em tempo de build \u00e9 usar um shell script que instala ou remove SDKs dinamicamente, com base em vari\u00e1veis de ambiente. Antes de o build come\u00e7ar, o script pode ler flags como ANALYTICS_ENABLED<\/mark>, DEEPLINK_ENABLED<\/mark> e qualquer configura\u00e7\u00e3o espec\u00edfica do cliente, e ent\u00e3o rodar os comandos yarn add ou yarn remove correspondentes.<\/p>\n\n\n\n Assim, s\u00f3 os SDKs necess\u00e1rios entram no projeto naquele build espec\u00edfico.<\/p>\n\n\n\n No ecossistema React Native, esse desafio fica bem mais simples gra\u00e7as ao Expo Prebuild<\/a> e aos Expo Config Plugins<\/a>. Com eles, voc\u00ea gera um c\u00f3digo nativo que inclui apenas os plugins de SDK necess\u00e1rios para aquele build. Ao envolver a defini\u00e7\u00e3o do plugin em uma condi\u00e7\u00e3o que depende do ambiente (process.env.KLAVIYO_ENABLED<\/mark><\/strong>), o SDK s\u00f3 entra quando aquele build precisa dele. Com isso, o app de cada cliente carrega apenas as integra\u00e7\u00f5es nativas de que precisa, sem c\u00f3digo extra nem dependencies desnecess\u00e1rias.<\/p>\n\n\n Se um SDK n\u00e3o oferece um plugin oficial do Expo, voc\u00ea ainda consegue aproveitar esse workflow criando seu pr\u00f3prio plugin. Veja esta documenta\u00e7\u00e3o<\/a> sobre mods dos Expo Config Plugins.<\/p>\n\n\n\n Quando voc\u00ea remove uma dependency em tempo de build, qualquer import direto daquele pacote nos seus arquivos falha, j\u00e1 que a biblioteca n\u00e3o est\u00e1 mais instalada. Isso pode quebrar o build ou gerar erros em runtime se n\u00e3o for tratado. Uma camada de abstra\u00e7\u00e3o unificada mant\u00e9m seu c\u00f3digo limpo e evita que voc\u00ea chame cada SDK diretamente. Se voc\u00ea tem v\u00e1rios SDKs de analytics, por exemplo, d\u00e1 para criar um adapter abstrato de analytics e uma classe global de analytics que concentra todos os m\u00e9todos necess\u00e1rios. Assim, o resto do seu app white-label conversa com uma interface \u00fanica.<\/p>\n\n\n\n Se o seu SDK n\u00e3o exige c\u00f3digo nativo customizado, est\u00e1 tudo certo. Basta abstrair os imports e a l\u00f3gica dos adapters.Os desafios a resolver<\/h2>\n\n\n\n
\n
Gerenciar dependencies em tempo de build<\/h2>\n\n\n\n
Garantir que o c\u00f3digo nativo n\u00e3o usado fique de fora<\/h2>\n\n\n\n
Veja um exemplo com o SDK da Klaviyo. Quando o expo prebuild roda, ele gera os projetos nativos de iOS e Android automaticamente, j\u00e1 com toda a configura\u00e7\u00e3o da Klaviyo, ent\u00e3o voc\u00ea n\u00e3o precisa escrever nem manter c\u00f3digo nativo.<\/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\nLidar com imports din\u00e2micos de dependencies<\/h2>\n\n\n\n
Uma sa\u00edda \u00e9 dar ao seu shell script a capacidade de gerar tamb\u00e9m um arquivo de mapeamento din\u00e2mico dos SDKs. Por exemplo:<\/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
Depois, use esse arquivo para tratar os imports dos SDKs com seguran\u00e7a, garantindo que seu c\u00f3digo nunca quebre quando uma dependency estiver ausente.<\/p>\n\n\n\nOferecer uma camada de abstra\u00e7\u00e3o unificada<\/h2>\n\n\n\n
A classe principal Analytics<\/mark><\/strong> <\/mark>decide quais SDKs carregar com base na configura\u00e7\u00e3o, enquanto cada SDK (como o da Klaviyo) apenas implementa o contrato compartilhado.<\/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\nComo fazer isso no Flutter ou no React Native puro?<\/h2>\n\n\n\n
Agora, se voc\u00ea precisa mesmo mexer em arquivos nativos, a coisa fica mais complexa. Nesses casos, d\u00e1 para criar scripts que aplicam patch nos arquivos de Android e iOS, montar um m\u00f3dulo wrapper para encapsular a l\u00f3gica nativa, apoiar-se em mecanismos como o manifest merging do Android ou at\u00e9 tentar ferramentas como o XcodeGen<\/a>.
Infelizmente, n\u00e3o existe nada equivalente ao Expo Prebuild para simplificar esse workflow no Flutter ou no React Native puro.<\/p>\n\n\n\n