My app exists as standard and branded version, the branded version has some tiny additional features but most stuff is the same.
Right now i have a basic library with popups and visual elements that i can use in every app i make. Then there are several modules (libraries) (features of the app "things one can do") and two final app projects.
One module, in the branded version can use auxilliary hardware (ah). So my idea was to split up the module into a library base-module and create an additional library for the ah and then make two module one with and one without ah. This way any basic change to the module would be incorporated into all apps but the branded one would chose the module with ah and the standard app would take the one without.
There is a chance that a second branded version will come soon, with some modules different and maybe different hardware used by some modules. I would have to split up even more and i fear for chaos. But the only other way i see is that i create omni-modules that can handle every possible variation and will be instantiated with a selection of which features to contain. But it is clear that "brand a" will never use hardware of "brand b" and vice versa, so the selection will really just be "standard, a or b" but the module is built to handle them all which might bloat up the module.
So how would i split up my libraries and or module to handle this without much chaos ?
My main concern is long term maintenance. After 2 years someone wants to add a feature to brand version xyz and i have to figure out into which library/at what level to implement it to not touch other versions.
Having many libs may make it hard to figure out the relations/dependencies between them but that can be compensated by proper documentation. Having it all in one lib/module means that i need to follow variables that enable/disable features to find out where they change/do stuff.
But how far do i split stuff up?