Primary definitions
To begin with you need to have a transparent understanding in regards to the fundamental phrases. In case you already know what is the distinction between a module, bundle, library or framework you’ll be able to skip this part. Nonetheless if you happen to nonetheless have some combined emotions about this stuff, please learn forward, you will not remorse it. 😉
Package deal
A bundle consists of Swift supply information and a manifest file.
A bundle is a group of Swift supply information. In case you are utilizing Swift Package deal Supervisor you even have to offer a manifest file to be able to make an actual bundle. If you wish to be taught extra about this instrument, you need to verify my Swift Package deal Supervisor tutorial.
Instance: that is your bundle:
Sources
my-source-file.swift
Package deal.swift
You can even take a look at the open sourced swift-corelibs-foundation bundle by Apple, which is used to construct the Basis framework for Swift.
Library
Library is a packaged assortment of object information that program can hyperlink towards.
So a library is a bunch of compiled code. You possibly can create two sorts of libraries:
From a extremely easy perspective the one distinction between them is the strategy of “integrating” aka. linking them into your undertaking. Earlier than I inform you extra about this course of, first we must always discuss object information.
Mach-O file format
To create packages, builders convert supply code to object information. The article information are then packaged into executable code or static libraries.
Whenever you’re compiling the supply information you might be principally making object information, utilizing the Mach-O (MachObject) file format. These information 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 information.
In different phrases:
After the compiler has created all the article information, one other program is named to bundle them into an executable program file. That program is named a linker and the method of bundling them into the executable is named linking.
Linking is simply combining all of your object information into an executable and resolving all of the externals, so the system will be capable to 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 may lead to an enormous executable, it’s going to take extra time to load, so the binary could have a slower startup time. Oh, did I point out that in case you are attempting to hyperlink the identical library greater than as soon as, the method will fail due to duplicated symbols?
This methodology has benefits as nicely, for instance the executable will at all times include the right model of the library, and solely these components will likely be copied into the primary software which can be actually used, so you do not have to load the entire stuff, nevertheless it looks as if dynamic linking goes to be higher in some instances.
Dynamic linking
Dynamic libraries are usually not embedded into the supply of the binary, they’re loaded at runtime. Which means apps might be smaller and startup time can considerably be sooner due to the light-weight binary information. As a free of charge dynamic libraries might be shared with a number of executables to allow them to have decrease reminiscence footprints. That is why typically they’re being referred as shared libraries.
After all if the dynamic library is just not out there – or it is out there however their model is incompatible – your software will not run or it’s going to crash. However this may be a bonus, as a result of the writer of the dynamic library can ship fixes and your app can profit from these, with out recompilation.
Happily system libraries like UIKit are at all times out there, so you do not have to fret an excessive amount of about this concern…
Framework
A framework is a hierarchical listing that encapsulates shared sources, reminiscent of a dynamic shared library, nib information, picture information, localized strings, header information, and reference documentation in a single bundle.
So let’s make this easy: 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 way in which 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 at all times 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-moduleEarlier 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 unsuitable with macro definitions, you may simply break different frameworks. That was the rationale for outlining prefixed uppercased very lengthy macro names like: NS_MYSUPERLONGMACRONAME… 😒
There was an different concern: the copy-pasting resulted in non-scalable compile instances. With the intention to clear up this, precompiled header (PCH) information had been born, however that was solely a partial answer, 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 all over the place), 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 is the binary that has the implementation) we have encapsulated modular frameworks. 🎉 They’re individually compiled as soon as, the header information are defining the interface (API), and the (mechanically) linked dylib file incorporates the implementation. Hurray, no have to parse framework headers throughout compilation time (scalability), so native macro definitions will not break something. Modules can include submodules (inheritance), and you do not have to hyperlink them explicitly inside your (Xcode) undertaking, 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 below the hood, once you import Basis or import UIKit.
Command line instruments
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 do not prefer to learn that a lot, you’ll be able to obtain the instance undertaking from GitLab and open the makefiles for the essence. There will likely be 3 fundamental classes: C, Swift and Xcode undertaking examples.
clang
the Clang C, C++, and Goal-C compiler
Clang is a compiler frontend for C languages (C, C++, Goal-C). When you have ever tried to compiled C code with gcc throughout your college years, you’ll be able to think about that clang is kind of the identical as gcc, however these days it will possibly do much more.
clang -c fundamental.c -o fundamental.o #compiles a C supply file
LLVM: compiler backend system, which may compile and optimize the intermediate illustration (IR) code generated by clang or the Swift compiler for instance. It is language impartial, and it will possibly achieve this many issues that might match right into a e book, however for now as an instance 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 be concerned, simply fireplace up swiftc -h and see what can supply to you.
swiftc fundamental.swift #compiles a Swift supply file
As you’ll be able to see this instrument is what really can compile the Swift supply information into Mach-O’s or ultimate executables. There’s a quick instance within the connected repository, you need to verify on that if you would like to be taught extra in regards to the Swift compiler.
ar
The ar utility creates and maintains teams of information mixed into an archive. As soon as an archive has been created, new information might be added and present information might be extracted, deleted, or changed.
So, in a nutshell you’ll be able to zip Mach-O information into one file.
ar -rcs myLibrary.a *.o
With the assistance of ar you had been capable of create static library information, 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 sooner once you’re about to make use of your library.
ranlib myLibrary.a
So ranlib & ar are instruments for sustaining static libraries, often ar takes care of the indexing, and you do not have to run ranlib anymore. Nonetheless there’s a higher possibility for managing static (and dynamic) libraries that you need to be taught…
libtool
create libraries
With libtool you’ll be able to create dynamically linked libraries, or statically linked (archive) libraries. This instrument with the -static possibility is meant to switch ar & ranlib.
libtool -static *.o -o myLibrary.a
These days libtool is the primary possibility for build up library information, you need to undoubtedly be taught this instrument if you happen to’re into the subject. You possibly can verify the instance undertaking’s Makefile for more information, or as often you’ll be able to learn the manuals (man libtool). 😉
ld
The ld command combines a number of object information and libraries, resolves references, and produces an ouput file. ld can produce a ultimate linked picture (executable, dylib, or bundle).
Let’s make it easy: that is the linker instrument.
ld fundamental.o -lSystem -LmyLibLocation -lmyLibrary -o MyApp
It might probably hyperlink a number of information right into a single entity, so from the Mach-O’s you can make an executable binary. Linking is important, 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 to run and your entire capabilities will likely be out there for calling. 📱
nm
show title listing (image desk)
With nm you’ll be able to 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’ll be able to see from the output, some sort 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 don’t seem to be resolved but). So because of this they will be resolved at runtime. The opposite possibility is that you must hyperlink them. 😅
otool
object file displaying instrument
With otool you’ll be able to look at the contents of Mach-O information or libraries.
otool -L myLibrary.a
otool -tV myLibrary.a
For instance you’ll be able to listing the linked libraries, or see the disassembled textual content contents of the file. It is a actually useful instrument if you happen to’re acquainted with the Mach-O file format, additionally good one to make use of for reverse-engineer an present software.
lipo
create or function on common information
With the assistance of the lipo instrument you’ll be able to create common (multi-architecture) information. Often this instrument 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 gadget you’d have to ship the arm7 model, however for the iOS simulator you may want the i386 one. With the assistance of lipo you’ll be able to mix these architectures into one, and ship that framework, so the tip consumer do not have to fret about this concern anymore.
Learn on the article to see the way it’s carried out. 👇
Xcode associated instruments
These instruments might be invoked from the command line as nicely, however they are much extra 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. When you have a number of variations of Xcode in your machine this instrument can simply change 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’ll be able to principally run something which you could handle from Xcode.
xcrun simctl listing #listing of simulators
codesign
Create and manipulate code signatures
It might probably signal your software with the right signature. Often this factor failed once you had been attempting to signal your app earlier than computerized 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 is it. It will parse the Xcode undertaking or workspace file and executes the suitable buid instructions primarily based on it.
xcodebuild -project Instance.xcodeproj -target Instance
xcodebuild -list
xcodebuild -showsdks
FAT frameworks
Easy methods to 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.
To begin with, I do not need to reinvent the wheel, as a result of there’s a fantastically written article that you need to learn. Nonetheless, I would like to provide you some extra detailed clarification and a little bit modification for the scripts.
Skinny vs. FAT frameworks
Skinny frameworks incorporates compiled code for just one structure. FAT frameworks then again 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 can work solely on the simulator and horribly fail on actual gadgets. So if you wish to construct a very common framework, you must 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 to be able 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 possibly can at all times look at the created framework with the lipo instrument.
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 undertaking that you just’d like to make use of and set some paths. That is it. Virtually…
Transport to the App Retailer
There is just one concern with fats architectures. They include slices for the simulator as nicely. If you wish to submit your app to the app retailer, you must lower off the simulator associated codebase from the framework. The rationale behind that is that no precise actual gadget 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")
carried out
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"
carried out
This little script will take away all of the pointless slices from the framework, so you can submit your app by way of iTunesConnect, with none points. (ha-ha-ha. 😅)
It’s a must to add this final script to your software’s construct phases.
If you wish to get acquainted with the instruments behind the scenes, this text will provide help to with the fundamentals. I could not discover one thing like this however I wished to dig deeper into the subject, so I made one. I hope you loved the article. 😉