30 ‐ About the architecture
The OUDS iOS library provides a library as a Swift Package so as to let users (i.e. developers) to integrate the library inside Xcode. It is not planned (yet) to expose the library as XCFramework or Pod.
The architecture of the project with the themes definition can be explained as bellow.
This package contains several modules with their own responsabilities and hierarchy.
The OUDS library contains high level utilities and objects.
It contains also the OUDSTheme, which can be seen as an abstract theme, a contract, to implement for white label themes for example.
This library will contain in the futur the modules exposed by the library, i.e. packs of components and features.
This library contains the components exposed by the OUDS package, i.e. buttons, etc.
This library may contain tokens of components, nothing yet.
This library contains the inverse theme, i.e. a kind of dark mdoe theme for specific use cases and apps.
This library exposes the Orange brand theme, as a default theme for subtheme.
This library contains all the semantic tokens, used by components pointing to raw tokens.
This library contains all the raw tokens, i.e raw values to apply on components through semantic tokens.
This library contains the foundations objects and utils
Today the project contains a demo application exposing the features provided by the library. In the future this project will be move elsewhere, inside an internal forge so as to be able to build the application with open source public content (this library) and also private assets which should not be exposed (fonts, resources, brands to not subclass, etc.).
If you look in the source code, you may find we use a lof of Swift protocols for semantic tokens and Swift enums for raw tokens. In fact, we declare all semantic tokens in protocols, with one protocol by "family" of tokens. It permits several things: to gather all tokens in one object, to force any thing wanting to implement tokens to implement all tokens. In addition, because these protocols containing the declarations of tokens are not updated by the tokenator (which updates the definitions of tokens, i.e. their implementations), we can write any documentation we want in the same file and this documentation is prevented to be erased by tokenator updates.
Extensions are used for the same logic: raw tokens are declared in a documented enum, and all tokens are generated in an extension of that enum. static let is used for optimization issues with namespaces.
The tokens are overriden thanks to @objc open combination so as to make possible to override these values in extensions declared in protocols (thanks to @objc) and from objects outside the module (thanks to open). Thus we can split values and responsabilities in different Swift Package Manager targets and keep overriding and inheritance possible.
Swift classes are used for themes implementation because they allow overriding and inheritance. Thus we can define subthemes and children classes for tests, overriding tokens we want. It matches perfectly the needs of this design system: define themes, which can be overriden or not (use of final or open keywords), with the possibility to override tokens.