Splitting your XCode project into modules

[phucledien]

Swift Packages

Swift Packages are great if you're starting a new Swift-only project or building something for Linux as well.

There’s nothing a Swift Package can do that I can’t using Xcode’s library and framework targets.

Library Targets

You can think of libraries (static or dynamic) as a collection of code objects (like books in a library). Unlike frameworks, libraries don’t have a built-in way to associate resources such as .strings, images, etc. But for most of these features, this wouldn’t be a problem as they usually code only.

The problem with these targets is that they don’t define a module by default.

Dynamic Frameworks

Dynamic frameworks are undoubtedly the most common, but if you’ve been reading some performance blog posts you already know they can seriously hinder your app’s startup time.

Static Frameworks

Static frameworks solve both problems mentioned above. They automatically define a module usable from Swift and Objective-C and their code is included in your final binary at compile time. So there’s no need to do dynamic symbol resolution at startup for them. You don’t even need to embed these frameworks in your app bundle.

But more often than not you’ll want to have one or more dynamic frameworks. Either because you need to bundle them with resources or you don’t want to duplicate your code in all the executables you’re shipping (with all the extensions an iOS app can bundle nowadays this can add up).

The problem with mixing dynamic and static frameworks is that if they depend on each other, you can easily run into to duplicate symbols issues.

ref: https://pfandrade.me/blog/splitting-your-xcode-project-into-modules/