Split a big swift project to frameworks with core framework and module frameworks

Question

I'm trying to split my large Swift framework to many module frameworks so every module in my application will be independent in order to reuse on another apps. Due to the fact that I have a big data like classes and libraries that shared with all of the modules I thought to create a core_framework contains share data and enforce the app to use this framework in order to enable use all the other frameworks (one or more)

I saw an example of FBSDK there is a core framework and other functionality frameworks : FBSDKCoreKit and FBSDKLoginKit

This is important to me that all the other frameworks will not contains the core framework for reasons of efficiency.

My question is - after creating the core framework what I have to do in my nodule framework so it's will recognize the core classes and functionality but will compile with out the core's files?

Thanks

Answer 1

When you split up a project into submodules, what you have to do is quite simple, though some details depend on how you partition your project.

Easiest case: 1 project with N targets

Say you only work on this one app and split it into modules. The easiest way is to add more Framework Targets to the project.

You then need to embed them in your app target. Make sure it's part of both "Embedded Binaries" and "Linked Frameworks and Libraries".

Now you have a new framework module.

1. Create a couple of them ("Core" and "Module 1", for example). Then:
2. In "Module 1"'s General project settings, add "Core" to "Linked Frameworks and Libraries". There's no embed option for frameworks, as they cannot include libraries, only the dependency on them.
3. In the app target, embed & link "Module 1".

That's all you need to set up.

I tried to diagram the embed and link settings so you see that only the app target contains the other frameworks:

Slightly more complex: multiple projects

The basic setup from above applies to all other variants: frameworks (modules) can depend on other frameworks, but they cannot ship with them. Only the application can finally resolve the binary file dependency.

If you split your project into multiple sub-projects, e.g. extracting deployable open source libraries for other people, then you have to make "Module 1" aware of "Core" in each project, linking to the "Core" module the same way as detailed above. What makes isolated Xcode projects a bit more complicated is: how does the "Module 1" project know about the Core.framework?

• You could expose each module via Carthage and depend on one from the other,
• you could use CocoaPods,
• you could check out dependencies via git submodule.

The options above keep each module project autonomous. Dependencies are part of the directory tree of a module.

A bit less orderly:

• You could create a Xcode workspace, drag all projects inside, then drag the Core.framework from the "Products" group of one project to the "Linked Libraries" list on another, or
• drag the Core.framework file from the Finder onto the "Module 1" project (optionally selecting "Copy files if necessary" to put the resulting binary into the "Module 1" directory tree).

The above options can work, too, but they form assumptions about the location of files in the file system. The workspace approach should help to reduce problems with outdated framework binary files, though, as the workspace can help create formalize build dependencies from inter-project dependencies. Just like the app target depends on its framework targets, and like test targets depend on the app target to be compiled first.