Modular iOS Application Architecture Demo Project
Sample Code from a Talk Held at the Cocoaheads Berlin October 2015 Meeting
An example how to structure an iOS application using modules.
When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole), several smaller modules are written separately so that, when composed together, they construct the executable application program. Source: Wikipedia.
Design Decisions:
A Service Locator is used to decouple modules from their dependencies.
-
The Service Locator is a global dependency, but has only one interface. This makes the coupling not too bad and easily replaceable.
-
Resolving service dependencies should only be done in init(), causing it to work more like a dependency injection framework.
-
Configuration is only done once at application start, making it immutable afterwards and removing the need for locks.
-
Services are guaranteed to be available. Misconfiguration of the service locator is a programmer error, resulting in the application to “Crash Early”.
-
Dependencies should form a directed acyclic graph (without loops), mirroring “Clean Architecture”.
Regarding structuring dependencies, see “Design information flow” in WWDC 2014 Session 229: Advanced iOS Application Architecture and Patterns.
Regarding asynchronous modularization techniques, see “Subdivide app into independent subsystems” in WWDC 2012 Session 712: Asynchronous Design Patterns with Blocks, GCD, and XPC.
Note that for passing data across asynchronous boundaries (which interfaces can represent) it might be advisable to use some Future– or Rx–style library. Otherwise I would discourage most other global dependencies, since it tends to become a PITA fast.