Deep dive into Swift frameworks

Primary definitions

Initially it’s best to have a transparent understanding concerning the fundamental phrases. In case you already know what’s the distinction between a module, package deal, library or framework you may skip this part. Nevertheless if you happen to nonetheless have some blended emotions about these items, please learn forward, you received’t remorse it. 😉

Package deal

A package deal consists of Swift supply recordsdata and a manifest file.

A package deal is a group of Swift supply recordsdata. In case you are utilizing Swift Package deal Supervisor you even have to offer a manifest file so as to make an actual package deal. If you wish to be taught extra about this software, it’s best to test my Swift Package deal Supervisor tutorial.

Instance: that is your package deal:

Sources
    my-source-file.swift
Package deal.swift

You may also try the open sourced swift-corelibs-foundation package deal by Apple, which is used to construct the Basis framework for Swift.

Library

Library is a packaged assortment of object recordsdata that program can hyperlink towards.

So a library is a bunch of compiled code. You’ll be able to create two sorts of libraries:

From a very easy perspective the one distinction between them is the strategy of “integrating” aka. linking them into your venture. Earlier than I let you know extra about this course of, first we must always discuss object recordsdata.

Mach-O file format

To create packages, builders convert supply code to object recordsdata. The thing recordsdata are then packaged into executable code or static libraries.

Once you’re compiling the supply recordsdata you might be principally making object recordsdata, utilizing the Mach-O (MachObject) file format. These recordsdata are the core constructing blocks of your purposes, frameworks, and libraries (each dynamic and static).

Linking libraries

Linking refers back to the creation of a single executable file from a number of object recordsdata.

In different phrases:

After the compiler has created all the thing recordsdata, one other program known as to bundle them into an executable program file. That program known as a linker and the method of bundling them into the executable known as linking.

Linking is simply combining all of your object recordsdata into an executable and resolving all of the externals, so the system will be capable of name all of the capabilities contained in the binary.

Static linking

The supply code of the library is actually going to be copied into the applying’s supply. This can end in an enormous executable, it’ll take extra time to load, so the binary may have a slower startup time. Oh, did I point out that if you’re making an attempt to hyperlink the identical library greater than as soon as, the method will fail due to duplicated symbols?

This methodology has benefits as effectively, for instance the executable will all the time comprise the right model of the library, and solely these components can be copied into the principle software which are actually used, so that you don’t need to load the entire stuff, however it looks like dynamic linking goes to be higher in some instances.

Dynamic linking

Dynamic libraries will not be embedded into the supply of the binary, they’re loaded at runtime. Which means that apps might be smaller and startup time can considerably be quicker due to the light-weight binary recordsdata. As a free of charge dynamic libraries might be shared with a number of executables to allow them to have decrease reminiscence footprints. That’s why generally they’re being referred as shared libraries.

In fact if the dynamic library will not be out there – or it’s out there however their model is incompatible – your software received’t run or it’ll crash. Then again this may be a bonus, as a result of the creator of the dynamic library can ship fixes and your app can profit from these, with out recompilation.

Thankfully system libraries like UIKit are all the time out there, so that you don’t have to fret an excessive amount of about this problem…

Framework

A framework is a hierarchical listing that encapsulates shared sources, comparable to a dynamic shared library, nib recordsdata, picture recordsdata, localized strings, header recordsdata, and reference documentation in a single package deal.

So let’s make this straightforward: frameworks are static or dynamic libraries packed right into a bundle with some further belongings, meta description for versioning and extra. UIKit is a framework which wants picture belongings to show a few of the UI parts, additionally it has a model description, by the best way the model of UIKit is identical because the model of iOS.

Module

Swift organizes code into modules. Every module specifies a namespace and enforces entry controls on which components of that code can be utilized outdoors of the module.

With the import key phrase you might be actually importing exterior modules into your sorce. In Swift you might be all the time utilizing frameworks as modules, however let’s return in time for some time to grasp why we wanted modules in any respect.

import UIKit
import my-awesome-module

Earlier than modules you needed to import framework headers straight into your code and also you additionally needed to hyperlink manually the framework’s binary inside Xcode. The #import macro actually copy-pasted the entire resolved dependency construction into your code, and the compiler did the work on that vast supply file.

It was a fragile system, issues might go fallacious with macro definitions, you might simply break different frameworks. That was the explanation for outlining prefixed uppercased very lengthy macro names like: NS_MYSUPERLONGMACRONAME… 😒

There was an different problem: the copy-pasting resulted in non-scalable compile occasions. In an effort to clear up this, precompiled header (PCH) recordsdata have been born, however that was solely a partial resolution, as a result of they polluted the namespace (you recognize if you happen to import UIKit in a PCH file it will get out there in in all places), and no-one actually maintained them.

Modules and module maps

The holy grail was already there, with the assistance of module maps (defining what sort of headers are a part of a module and what’s the binary that has the implementation) we’ve received encapsulated modular frameworks. 🎉 They’re individually compiled as soon as, the header recordsdata are defining the interface (API), and the (routinely) linked dylib file accommodates the implementation. Hurray, no have to parse framework headers throughout compilation time (scalability), so native macro definitions received’t break something. Modules can comprise submodules (inheritance), and also you don’t need to hyperlink them explicitly inside your (Xcode) venture, as a result of the .modulemap file has all the knowledge that the construct system wants.

Finish of the story, now you recognize what occurs underneath the hood, once you import Basis or import UIKit.

Now that you recognize the logic behind the entire dynamic modular framework system, we must always begin analyzing the instruments that make this infrastructure attainable.

All the time learn the person pages, aka. RTFM! In case you don’t wish to learn that a lot, you may obtain the instance venture from GitLab and open the makefiles for the essence. There can be 3 predominant classes: C, Swift and Xcode venture examples.

clang

the Clang C, C++, and Goal-C compiler

Clang is a compiler frontend for C languages (C, C++, Goal-C). In case you have ever tried to compiled C code with gcc throughout your college years, you may think about that clang is kind of the identical as gcc, however these days it might probably do much more.

clang -c predominant.c -o predominant.o #compiles a C supply file

LLVM: compiler backend system, which might compile and optimize the intermediate illustration (IR) code generated by clang or the Swift compiler for instance. It’s language impartial, and it might probably accomplish that many issues that would match right into a guide, however for now let’s say that LLVM is making the ultimate machine code in your executable.

swiftc

The Swift compiler, there is no such thing as a guide entry for this factor, however don’t fear, simply fireplace up swiftc -h and see what can supply to you.

swiftc predominant.swift #compiles a Swift supply file

As you may see this software is what truly can compile the Swift supply recordsdata into Mach-O’s or remaining executables. There’s a quick instance within the connected repository, it’s best to test on that if you happen to’d wish to be taught extra concerning the Swift compiler.

ar

The ar utility creates and maintains teams of recordsdata mixed into an archive. As soon as an archive has been created, new recordsdata might be added and present recordsdata might be extracted, deleted, or changed.

So, in a nutshell you may zip Mach-O recordsdata into one file.

ar -rcs myLibrary.a *.o

With the assistance of ar you have been in a position to create static library recordsdata, however these days libtool have the identical performance and much more.

ranlib

ranlib generates an index to the contents of an archive and shops it within the archive. The index lists every image outlined by a member of an archive that may be a relocatable object file.

ranlib can create an index file contained in the static lib, so issues are going to be quicker once you’re about to make use of your library.

ranlib myLibrary.a

So ranlib & ar are instruments for sustaining static libraries, normally ar takes care of the indexing, and also you don’t need to run ranlib anymore. Nevertheless there’s a higher choice for managing static (and dynamic) libraries that it’s best to be taught…

libtool

create libraries

With libtool you may create dynamically linked libraries, or statically linked (archive) libraries. This software with the -static choice is meant to interchange ar & ranlib.

libtool -static *.o -o myLibrary.a

These days libtool is the principle choice for increase library recordsdata, it’s best to undoubtedly be taught this software if you happen to’re into the subject. You’ll be able to test the instance venture’s Makefile for more information, or as normally you may learn the manuals (man libtool). 😉

ld

The ld command combines a number of object recordsdata and libraries, resolves references, and produces an ouput file. ld can produce a remaining linked picture (executable, dylib, or bundle).

Let’s make it easy: that is the linker software.

ld predominant.o -lSystem -LmyLibLocation -lmyLibrary -o MyApp

It might hyperlink a number of recordsdata right into a single entity, so from the Mach-O’s you’ll be capable of make an executable binary. Linking is critical, as a result of the system must resolve the addresses of every methodology from the linked libraries. In different phrases, the executable will be capable of run and your whole capabilities can be out there for calling. 📱

nm

show title record (image desk)

With nm you may see what symbols are inside a file.

nm myLibrary.a
# 0000000000001000 A __mh_execute_header
#                  U _factorial
# 0000000000001f50 T _main
#                  U _printf
#                  U dyld_stub_binder

As you may see from the output, some form of reminiscence addresses are related for a few of symbols. Those who have addresses are literally resolved, all of the others are coming from different libraries (they’re not resolved but). So which means they’ll be resolved at runtime. The opposite choice is that it’s important to hyperlink them. 😅

otool

object file displaying software

With otool you may look at the contents of Mach-O recordsdata or libraries.

otool -L myLibrary.a
otool -tV myLibrary.a

For instance you may record the linked libraries, or see the disassembled textual content contents of the file. It’s a very useful software if you happen to’re accustomed to the Mach-O file format, additionally good one to make use of for reverse-engineer an present software.

lipo

create or function on common recordsdata

With the assistance of the lipo software you may create common (multi-architecture) recordsdata. Often this software is used for creating common frameworks.

lipo -create -output myFramework.framework gadgets.framework simulator.framework

Think about the next state of affairs: you construct your sources each for arm7 and i386. On an actual machine you’d have to ship the arm7 model, however for the iOS simulator you’ll want the i386 one. With the assistance of lipo you may mix these architectures into one, and ship that framework, so the top consumer don’t have to fret about this problem anymore.

Learn on the article to see the way it’s achieved. 👇

These instruments might be invoked from the command line as effectively, however they’re rather more associated to Xcode than those earlier than. Let’s have a fast walk-through.

xcode-select

Manages the lively developer listing for Xcode and BSD instruments. In case you have a number of variations of Xcode in your machine this software can simply swap between the developer instruments supplied by the induvidual variations.

xcode-select --switch path/to/Xcode.app

xcrun

Run or find improvement instruments and properties. With xcrun you may principally run something you can handle from Xcode.

xcrun simctl record #record of simulators

codesign

Create and manipulate code signatures

It might signal your software with the correct signature. Often this factor failed once you have been making an attempt to signal your app earlier than automated signing was launched.

codesign -s "Your Firm, Inc." /path/to/MyApp.app
codesign -v /path/to/MyApp.app

xcodebuild

construct Xcode initiatives and workspaces

That’s it. It’ll parse the Xcode venture or workspace file and executes the suitable buid instructions based mostly on it.

xcodebuild -project Instance.xcodeproj -target Instance
xcodebuild -list
xcodebuild -showsdks

FAT frameworks

How one can make a closed supply common FATtened (multi-architecture) Swift framework for iOS?

So we’re right here, the entire article was made for studying the logic behind this tutorial.

Initially, I don’t need to reinvent the wheel, as a result of there’s a fantastically written article that it’s best to learn. Nevertheless, I’d like to provide you some extra detailed rationalization and a bit of modification for the scripts.

Skinny vs. FAT frameworks

Skinny frameworks accommodates compiled code for just one structure. FAT frameworks however are containing “slices” for a number of architectures. Architectures are principally referred as slices, so for instance the i386 or arm7 slice.

This implies, if you happen to compile a framework just for i386 and x86_64 architectures, it’s going to work solely on the simulator and horribly fail on actual gadgets. So if you wish to construct a really common framework, it’s important to compile for ALL the prevailing architectures.

Constructing a FAT framework

I’ve a excellent news for you. You simply want one little construct section script and an mixture goal so as to construct a multi-architecture framework. Right here it’s, shamelessly ripped off from the supply article, with some further adjustments… 😁

set -e
BUILD_PATH="${SRCROOT}/construct"
DEPLOYMENT_PATH="${SRCROOT}"
TARGET_NAME="Console-iOS"
FRAMEWORK_NAME="Console"
FRAMEWORK="${FRAMEWORK_NAME}.framework"
FRAMEWORK_PATH="${DEPLOYMENT_PATH}/${FRAMEWORK}"

# clear the construct folder
if [ -d "${BUILD_PATH}" ]; then
    rm -rf "${BUILD_PATH}"
fi

# construct the framework for each structure utilizing xcodebuild
xcodebuild -target "${TARGET_NAME}" -configuration Launch 
    -arch arm64 -arch armv7 -arch armv7s 
    only_active_arch=no defines_module=sure -sdk "iphoneos"

xcodebuild -target "${TARGET_NAME}" -configuration Launch 
    -arch x86_64 -arch i386 
    only_active_arch=no defines_module=sure -sdk "iphonesimulator"

# take away earlier model from the deployment path
if [ -d "${FRAMEWORK_PATH}" ]; then
    rm -rf "${FRAMEWORK_PATH}"
fi

# copy freshly constructed model to the deployment path
cp -r "${BUILD_PATH}/Launch-iphoneos/${FRAMEWORK}" "${FRAMEWORK_PATH}"

# merge all of the slices and create the fats framework
lipo -create -output "${FRAMEWORK_PATH}/${FRAMEWORK_NAME}" 
    "${BUILD_PATH}/Launch-iphoneos/${FRAMEWORK}/${FRAMEWORK_NAME}" 
    "${BUILD_PATH}/Launch-iphonesimulator/${FRAMEWORK}/${FRAMEWORK_NAME}"

# copy Swift module mappings for the simulator
cp -r "${BUILD_PATH}/Launch-iphonesimulator/${FRAMEWORK}/Modules/${FRAMEWORK_NAME}.swiftmodule/" 
    "${FRAMEWORK_PATH}/Modules/${FRAMEWORK_NAME}.swiftmodule"

# clear up the construct folder once more
if [ -d "${BUILD_PATH}" ]; then
    rm -rf "${BUILD_PATH}"
fi

You’ll be able to all the time look at the created framework with the lipo software.

lipo -info Console.framework/Console
#Architectures within the fats file: Console.framework/Console are: x86_64 i386 armv7 armv7s arm64

Utilization

You simply need to embed your model new framework into the venture that you just’d like to make use of and set some paths. That’s it. Virtually…

Delivery to the App Retailer

There is just one problem with fats architectures. They comprise slices for the simulator as effectively. If you wish to submit your app to the app retailer, it’s important to lower off the simulator associated codebase from the framework. The rationale behind that is that no precise actual machine requires this chunk of code, so why submit it, proper?

APP_PATH="${TARGET_BUILD_DIR}/${WRAPPER_NAME}"

# take away unused architectures from embedded frameworks
discover "$APP_PATH" -name '*.framework' -type d | whereas learn -r FRAMEWORK
do
    FRAMEWORK_EXECUTABLE_NAME=$(defaults learn "$FRAMEWORK/Information.plist" CFBundleExecutable)
    FRAMEWORK_EXECUTABLE_PATH="$FRAMEWORK/$FRAMEWORK_EXECUTABLE_NAME"
    echo "Executable is $FRAMEWORK_EXECUTABLE_PATH"

    EXTRACTED_ARCHS=()

    for ARCH in $ARCHS
    do
        echo "Extracting $ARCH from $FRAMEWORK_EXECUTABLE_NAME"
        lipo -extract "$ARCH" "$FRAMEWORK_EXECUTABLE_PATH" -o "$FRAMEWORK_EXECUTABLE_PATH-$ARCH"
        EXTRACTED_ARCHS+=("$FRAMEWORK_EXECUTABLE_PATH-$ARCH")
    achieved

    echo "Merging extracted architectures: ${ARCHS}"
    lipo -o "$FRAMEWORK_EXECUTABLE_PATH-merged" -create "${EXTRACTED_ARCHS[@]}"
    rm "${EXTRACTED_ARCHS[@]}"

    echo "Changing unique executable with thinned model"
    rm "$FRAMEWORK_EXECUTABLE_PATH"
    mv "$FRAMEWORK_EXECUTABLE_PATH-merged" "$FRAMEWORK_EXECUTABLE_PATH"

achieved

This little script will take away all of the pointless slices from the framework, so that you’ll be capable of submit your app by way of iTunesConnect, with none points. (ha-ha-ha. 😅)

NOTE: You must add this final script to your software’s construct phases.

If you wish to get accustomed to the instruments behind the scenes, this text will assist you to with the fundamentals. I couldn’t discover one thing like this however I wished to dig deeper into the subject, so I made one. I hope you loved the article. 😉