Nel contesto di consulenza su prodotti mobile del gruppo Flutter Entertainment ho lavorato su brand come Sisal, SNAI e PokerStars. Il problema interessante non era semplicemente condividere codice: era farlo senza assumere che tutti i prodotti avessero lo stesso backend, gli stessi provider o lo stesso calendario evolutivo.
Contesto
Le app enterprise multi-brand hanno un equilibrio delicato. Da un lato conviene riutilizzare componenti e competenze; dall’altro ogni brand può avere dipendenze, integrazioni e versioni backend differenti. Una libreria realmente riusabile deve quindi evitare di imporre un’unica evoluzione a prodotti che si muovono con velocità diverse.
La complessità reale
Riuso senza rigidità
Componenti riutilizzabili sono stati portati su più brand, compresi contesti PokerStars in Italia, Francia e Spagna. In alcuni casi il kit è stato rilasciato con versionamenti differenti proprio per mantenere compatibilità con backend che non erano sulla stessa release.
Questo è un punto importante nelle architetture condivise: riuso non significa sincronizzazione forzata. La libreria deve creare una base comune lasciando spazio alle differenze che hanno una ragione operativa.
Un componente comune è utile quando riduce duplicazione senza trasformarsi in un vincolo che obbliga più prodotti a rilasciare insieme.
Provider e integrazioni
Per alcune funzionalità, come le notifiche push, brand differenti hanno utilizzato provider diversi. La responsabilità del componente mobile diventa quindi offrire un comportamento coerente verso l’app isolando il più possibile i dettagli del fornitore esterno.
È lo stesso principio che applico in generale alle integrazioni enterprise: l’applicazione dovrebbe dipendere dal contratto funzionale che le serve, non dalle peculiarità di un singolo vendor.
Streaming e live widget su iOS
Nel perimetro iOS sono state inoltre sviluppate funzionalità di streaming e live widget. Sono componenti che aumentano la complessità perché si inseriscono in flussi già ricchi di stato, aggiornamenti, lifecycle dell’app e dipendenze lato servizio.
Cosa dimostra
Il caso mostra perché nei prodotti enterprise la qualità dell’architettura non coincide con l’eleganza teorica. Conta la capacità di assorbire differenze reali tra brand, provider e backend continuando a mantenere il codice evolvibile e governabile.
Hai un’app enterprise con troppe varianti e dipendenze?
Posso entrare sulla codebase, separare ciò che è davvero comune da ciò che deve restare specifico e ridurre il costo delle evoluzioni future.
Parliamo di iOS