Basic Definitions

library

Library is a packaged collection ofobject filesthat program canlink against. So a library is a bunch of compiled code. You can create 2 types of libs:

• static
• dynamic

Mach-O file format

When you’re compiling the source files you are basically making object files, using theMach-O (Mach Object) file format. The object files are then packaged into executable code or static libraries.

framework

A framework is a hierarchical directory that encapsulates shared resources, such as a dynamic shared library, nib files, image files, localized strings, header files, and reference documentation in a single package. So let’s make this simple: frameworks arestatic or dynamiclibraries packed into a bundle with some extra assets, meta description for versioning and more.

package

A package consists of Swift source files and a manifest file. You can also check out the open sourcedswitf-corelibs-foundationpackage by Apple, which is used to build the Foundation framework for Swift.

module

Swift organizes code intomodules. Each module specifies a namespace and enforces access controls on which parts of that code can be used outside of the module. With theimport keywordyou are literally importing external modules into your sorce. In Swift you are always using frameworks as modules

Before modules you had to import framework headers directly into your code and you also had to link manually the framework’s binary within Xcode. The#importmacro literally copy-pasted the whole resolved dependency structure into your code, and the compiler did the work on that huge source file. It was a fragile system, things could go wrong with macro definitions, you could easily break other frameworks. That was the reason for defining prefixed uppercased very long macro names like: NS_MYSUPERLONGMACRONAME… There was an other issue: the copy-pasing resulted in non-scalable compile times. In order to solve this,precompiled header (PCH) fileswere born, but that was only a partial solution, because they polluted the namespace (you know if you import UIKit in a PCH file it gets available in everywhere), and no one really maintained them.

modules and module maps

module maps defines what kind of headers are part of a module and what’s the binary that has the implementation. Header files are defining the interface (API), and the (automatically) linked dylib file contains the implementation. There’s no need to parse framework headers during compilation time (scalability), so local macro definitions won’t break anything. Modules can contain submodules (inheritance), and you don’t have to link them explicitly inside your (Xcode) project, because the .modulemap file has all the information that the build system needs.

Linking libraries

Linking refers to the creation of a single executable file from multiple object files. Linking is just combining all your object files into an executable and resolving all the externals, so the system will be able to call all the functions inside the binary.

static linking

The source code of the library is literally going to be copied into the application’s source. This will result in a big executable, it’ll take more time to load, so the binary will have a slower startup time. if you are trying to link the same library more than once, the process will fail because of duplicated symbols? This method has advantages as well, for example the executable will

• always contain the correct version of the library,
• and only those parts will be copied into the main application that are really used, so you don’t have to load the whole stuff

dynamic linking

Dynamic libraries are not embedded into the source of the binary, they are loaded at runtime. This means that apps can be smaller and startup time can significantly be faster because of the lightweight binary files. As a gratis dynamic libraries can be shared with multiple executables so they can have lower memory footprints. That’s why sometimes they’re being referred as shared libraries. Of course if the dynamic library is not available - or it’s available but the version is incompatible - your application won’t run or it’ll crash. On the other hand this can be an advantage, because the author of the dynamic library can ship fixes and your app can benefit from these, without recompilation.

references

https://theswiftdev.com/deep-dive-into-swift-frameworks/

You’ll find this post in your _posts directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run jekyll serve, which launches a web server and auto-regenerates your site when a file is updated.

To add new posts, simply add a file in the _posts directory that follows the convention YYYY-MM-DD-name-of-post.ext and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Demo post displaying the various ways of highlighting code in Markdown.

Try click on the link icon.

Custom written post descriptions are the way to go... if you're not lazy.

A ton of text to test readability.

Just about everything you'll need to style in the theme: headings, paragraphs, blockquotes, tables, code blocks, and more.