The subprojects – modules as I refer to them – yes, do have an app and a framework as products. The sub-apps are there for testing – and are just placeholder examples of the pattern. The idea is that you treat each module as an isolated component that can re-used in any other project. If you want that kind of reuse, each component should – in, and of itself - be available for use and demonstration. I find that when you are working in teams and components are isolated, it’s better to set up lightweight demo apps of everything in that layer – so you won’t tread on others toes and others can test intent.

With this method you can also mock up other ways of integrating the framework you are ultimately delivering. You can add multiple apps to the workspace – as the component that ultimately the rest of your team are working with is your framework. The app also serves as a form of documentation on how to use the framework. You can also send out these micro-apps out to people for user testing – again whilst having no impact on the greater project, but getting good feedback.

I only linked to that article to get your feet wet. And to start thinking about not building a monolith. My example goes a little further.

The next stage is make each sub-workspace a Git Submodule and merge and compile the frameworks as static libraries – to overcome Apple’s maxiumum Dynamic framework rule of 6 frameworks. But more on that later.