Although the review is limited to iOS only, this doesn\u2019t mean that you can\u2019t use these approaches for other Apple\u2019s platforms.<\/p>\n\n\n\n
Basics<\/h4>\n\n\n\n
\n\n\n\n
The concept of code organization and access control in Swift based on Modules<\/a>. The module represented as a single unit of code distribution. Frameworks, libraries, swift packages and build targets treated in Xcode as a separate module. Each with its namespace and access controls. Module, usually, solves a particular problem. It can be reused in different situations.<\/p>\n\n\n\n Bundle<\/strong><\/a> is a file directory with subdirectories inside. On iOS, bundles serve to conveniently ship related files together in one package \u2014 for instance, images, nibs, or compiled code. The system treats it as one file and you can access bundle resources without knowing its internal structure. Dylib that cannot be linked, only opened in runtime with dlopen()<\/p>\n\n\n\n Source file<\/strong> is single Swift source code file within a module.<\/p>\n\n\n\n Executable<\/strong> \u2014 main binary for application.<\/p>\n\n\n\n Object file<\/strong><\/a> \u2014 An object file is a file containing object code<\/a>, meaning relocatable format machine code<\/a> that is usually not directly executable. An object file may also work like a shared library<\/a>.<\/p>\n\n\n\n Object code<\/strong><\/a> \u2014 In computing, object code or object module is the product of a compiler. In a general sense object code is a sequence of statements or instructions in a computer language, usually a machine code language (i.e., binary or an intermediate language such as register transfer language).<\/p>\n\n\n\n In computer science, library<\/a> means collection of resources and code, compiled into one or more architecture. Working with iOS application you\u2019ll faced static and dynamic libraries. Let\u2019s take a look on what they are.<\/p>\n\n\n\n Static library<\/strong><\/a> \u2014 (*.a) ( static archive library, static linked shared library<\/a>) \u2014 collection or archive of object files. Static linker collects app compiled source code with library code into a single executable file, which loaded into memory in its entirety at runtime.<\/p>\n\n\n\n Since static library, in its general sense, is a sequence of statements or instructions in a machine code language, this is adding some limitations to create and distribute them:<\/p>\n\n\n\n You can create a Swift static library, this is supported from Xcode 9.0. Till Xcode 9 dynamic frameworks where required. Developers, who were using CocoaPods remember that it was required to add use_frameworks<\/a>. It tells CocoaPods that you want to use Frameworks instead of Static Libraries since it wasn\u2019t supported for Swift. But fortunately Swift and Xcode are constantly improving and now we have support for Swift static libraries.<\/p>\n\n\n\n Dynamic libraries<\/strong> (*.dylib) ( dynamic shared library, shared object, dynamically linked library<\/a>) are not copied into executable file, like static libraries. Instead, they are dynamically linked to at load or runtime, when both binary files and the library are in memory. Dynamic libraries stored and versioned separately. As a result, the dynamic library may be loaded not the same which was originally referenced if the update is considered binary compatible with the original version.<\/p>\n\n\n\n System iOS and macOS libraries are dynamic. This means that your app will receive improvements from Apple\u2019s updates without new build submission.<\/mark> This also may lead to issues with interoperability. That\u2019s why it is always a good idea to test the app on the new OS version before it becomes released.<\/p>\n\n\n\n There are some old discussions related to the creation and integration of own custom .dylib for iOS app: topic1<\/a>, topic2<\/a>. In spite of this Apples documents clearly says<\/a>:<\/p>\n\n\n\n Dynamic libraries outside of a framework bundle, which typically have the file extension .dylib, are not supported on iOS, watchOS, or tvOS, except for the system Swift libraries provided by Xcode.<\/em><\/p><\/blockquote>\n\n\n\n A framework<\/em><\/a> ( .framework): is a hierarchical directory that encapsulates a dynamic library, header files, and resources, such as storyboards, image files, and localized strings, into a single package. Apps using frameworks need to embed the framework in the app\u2019s bundle.<\/em><\/p><\/blockquote>\n\n\n\n Frameworks intended for the same purposes as a static and dynamic shared libraries<\/a>. But unlike libraries, frameworks:<\/p>\n\n\n\n There is also another point of view on the difference between frameworks and libraries, which based on the architect and clean design perspective. In the great article \u201c Inversion of Control<\/a>\u201d Martin Fowler<\/a> says that inversion of control is a key part of what makes a framework different from a library:<\/p>\n\n\n\n Frameworks supported from iOS 8.<\/p>\n\n\n\n Talking about frameworks also worth mentioning umbrella frameworks and universal frameworks (fat frameworks):<\/p>\n\n\n\n umbrella framework:<\/strong> is a framework bundle that contains other frameworks. Umbrella frameworks available for macOS apps<\/a>, but Apple do not recommend<\/a> using them. Umbrella frameworks are not supported on iOS, watchOS, or tvOS<\/a>.<\/p>\n\n\n\n universal framework (fat framework)<\/strong>: multi-architecture binary that contains code native to multiple instructions sets and can run on multiple processor types. In short, it contains code compiled for all the platforms which you are going to support. For example, x86_64 (64-bit Simulator), arm64 arm64e armv7 armv7s for devices. As a result, such a framework will have a larger size than a one-architecture framework. There are lots of tutorials on how to make universal framework using lipo<\/a>. This approach widely used for sharing a private binary. In this way, your framework consumer able work with your framework on a real device and simulator.<\/p>\n\n\n\n You can expect framework with To inspect all the dynamically linked frameworks and libraries to a binary you can use otool<\/a>:<\/p>\n\n\n\n Apple says that the app on average contains 100\u2013400 system dylibs. The loading of system frameworks is highly optimized. But loading custom embedded frameworks can be expensive. Apple\u2019s engineers encourage you to use frameworks wisely and limit the amount of used framework because it impacts on the app launch time. If you are interested in deep details on how the framework works and how it impacts on the app launch time, check the WWDC session Optimizing App Startup Time<\/a>.<\/p>\n\n\n\n This year Apple declare that Swift 5 provides binary compatibility for apps, that means that app built with one version of the Swift compiler will be able to talk to a library built with another version. Swift\u2019s ABI is currently declared stable for Swift 5<\/a> on Apple platforms.<\/p>\n\n\n\n XCFrameworks is a new supported way to distribute binary frameworks, available from Xcode 11. Actually a framework that now can containing code for multiple architectures and platforms. You will still be required to generate archives for different platforms and bundle them up together in single XCFrameworks. There is a great session from WWDC 2019: Binary Frameworks in Swift<\/a> that explain in detail how to create, integrate and distribute XCFrameworks.<\/p>\n\n\n\n There are few advantages of using XCFrameworks:<\/p>\n\n\n\n With the new package manifest API in Xcode 12, it is now possible to make Swift packages that include one or more XCFrameworks. The details of implementation you can find in the official documentation Distributing Binary Frameworks as Swift Packages<\/a> and WWDC 2020 video<\/a>.<\/p>\n\n\n\n Swift is a cross-platform language and requires a cross-platform tool for building the Swift code. One of the goals Swift Package Manager<\/a> (SwiftPM) is simplified distribute source code in the Swift ecosystem. SwiftPM is an open-source project, you can find information about it on GitHub<\/a> as well.<\/p>\n\n\n\n Swift Package contains source files and manifest file (Package.swift). Manifest describes the configuration for the Swift package. Swift Package is defined and used with Swift Package Manager<\/a>, that included Swift 3.0 and above<\/a>. Because distribution in Source form, there is no need anymore to maintain binary compatibility for clients. So if you can ship the source code, then Swift Package is a great tool for you. With new changes in Xcode 11, you can easily create and distribute Swift Packages.<\/p>\n\n\n\n Swift package consists of 3 parts: dependencies, targets and products:<\/p>\n\n\n\n Dependencies<\/strong>: other swift packages, that you are using inside your package. In Package file each dependency specified by source location and version.<\/p>\n\n\n\n Target<\/strong>: As Apple\u2019s document says, Targets are the basic building blocks of a package<\/a>. Is may be either a library or an executable as its product. Before Xcode 12 Swift package could contain only Swift, Objective-C\/C++, or C\/C++ files. Xcode 12 offers the new tools-version:5.3 which brings the new package manifest API. And now the Swift package can contain other resources types: images, storyboards, JSON files, Shell scripts, and much more. You can also localize those resources. That is great and desired improvement. Thank you to all who have contributed to making this available. Useful details and implementation details, you can find in the WWDC 2020 video Swift packages: Resources and localization<\/a> and in documentation Localizing Package Resources <\/a>.<\/p>\n\n\n\n Products<\/strong>: the output of your package, either a library or an executable produced by a package, and make them visible to other packages.<\/p>\n\n\n\n Below Pros and Cons of Swift Packages (at least at the time of writing this article).<\/p>\n\n\n\n Pros:<\/p>\n\n\n\n When you are making architectural choice between static libraries, frameworks or Swift packages for your iOS application, obviously, you should take into account the limitations of each specific project.<\/p>\n\n\n\n Linking too many static libraries into an app produces large app executable files, slow launch times and large memory footprints. Frameworks gives you much more flexibility than static libraries, they can contain resources. But each embedded framework added to project increases startup time as well.<\/p>\n\n\n\n If you can ship your source files, Swift packages may be the right choice for you. Xcode will take care of all the dependencies, versioning, platforms.<\/p>\n\n\n\n In Swift, packages are reusable components of Swift, Objective-C, Objective-C++, C, or C++ code that developers can use in their projects<\/a>. This is similar to packages in npm<\/a>.<\/p>\n\n\n\n Packages are primarily distributed through Cocoa Pods<\/a>, Swift Package Manager<\/a>, and Carthage<\/a>.<\/p>\n\n\n\n Packages can contain Frameworks and Libraries and can use other packages as dependencies.<\/p>\n\n\n\nLibraries<\/h4>\n\n\n\n
\n\n\n\n![\"\"\/](\"https:\/\/miro.medium.com\/max\/958\/0*SeaXdw0XFQNos6Yl.png\")
<\/figure>\n\n\n\n![\"\"](\"http:\/\/123.57.164.21\/wp-content\/uploads\/2022\/02\/\u56fe\u7247-53-1024x923.png\")
<\/figure><\/div>\n\n\n\n![\"\"](\"http:\/\/123.57.164.21\/wp-content\/uploads\/2022\/02\/\u56fe\u7247-54.png\")
<\/figure><\/div>\n\n\n\nFrameworks<\/h4>\n\n\n\n
\n\n\n\nfile<\/code> command in Terminal:<\/p>\n\n\n\nfile <PathToAppFramework>\/<FrameworkName>.framework\/<FrameworkName>\n<\/pre>\n\n\n\n
![\"\"](\"http:\/\/123.57.164.21\/wp-content\/uploads\/2022\/02\/\u56fe\u7247-55-1024x252.png\")
<\/figure><\/div>\n\n\n\notool -L <PathToArchive>\/Products\/Applications\/<AppName>.app\/<AppBinary>\n<\/pre>\n\n\n\n
![\"\"](\"http:\/\/123.57.164.21\/wp-content\/uploads\/2022\/02\/\u56fe\u7247-56-1024x846.png\")
<\/figure><\/div>\n\n\n\nXCFrameworks<\/h4>\n\n\n\n
\n\n\n\nSwift Package<\/h4>\n\n\n\n
\n\n\n\n