Library? Static? Dynamic? Or Framework? Project inside another project

I have an existing iOS app and want to add a large chunk of code that I've been developing as another project just for ease of testing. The new chunk basically deals with saving an image to various sharing services, etc.. Because that sharing code needs a lot of testing and future updating, I was wondering what the best way to incorporate that code chunk into my existing app.

I don't know if it should be a static library, dynamic library or a framework, and honestly, I'm not really sure what the difference is, or how I should go about it and get it set up in Xcode.

All I know is that I need/want to keep a separate testing and updating app for the sharing code and have the main app use it.

You can also create .podspec file for CocoaPods(

[To see links please register here]

) and use it like any other pod with the only difference that it's your private pod and is not visible to outside world(I'm not sure what will happen if your pod should create CoreData model, but that's not the case, as I understand).

**Mach-O file format(Mach Object - `.o`)**

In iOS world every source file is converted into object files - ABI[<sup>\[About\]</sup>][1] Mach-O file[<sup>\[About\]</sup>][2] which will be packaged into a final executable **bundle**(application, framework), **file** (library) and it's behavior is determined by `Mach-O type`[<sup>\[About\]</sup>][3]

`Package` is a directory which behavious itself as a file - `opaque file`. It is created for **user experience** to complicate making some changes into internal structure that can cause unpredictable program behaviour. Package is used in `Document Package` or with a `Bundle`. You can use `Show Package Contents` in a Finder

`Bundle` is a directory with a specific structure to organize a binary(executable code) and resources for that code(e.g. images, nibs... Assets.car file[<sup>\[About\]</sup>][4]).
Bundle contains `Info.plist`[<sup>\[About\]</sup>][5] file. Bundle was created for **developer experience**. Also it can be packaged. There are several types of bundle:

- `application bundle` - `Application target`
- `framework bundle` and `versioned bundle` as a subtype - `Framework Target`
- `loadable bundle`(aka `plug-in bundle`) - '... Bundle' (UI Testing Bundle, Unit Testing Bundle) - can be loaded at runtime. `.bundle` extension for Mac OS
- [Mac OS] `XPC Service` - Cross Process Communication is a kind of Inter Process Communication (IPC). It can be used as a module on a **different process**(managed by `launchd` root process)[<sup>\[About\]</sup>][6]
- others(`dSYM`[<sup>\[About\]</sup>][7] bundle)

`Application` - `.ipa`, `.app`[<sup>\[About\]</sup>][8] - `packaged` `application bundle` - launchable program.

[`Application extension`][9][<sup>\[About\]</sup>][10] - from iOS v8 - extends functionality of Application which are available when user interacts with other application. `App extension` as a bundle is a part of `Containing app` but it is run on their own sandbox(processor, memory...), app which try to use `app extension` is called `Host App`. Types of extension app:

- Action
- Share
- Photo Editing
- Today aka widget
- ...

to share common code and resources. It's available when Deployment target is iOS 8+.

`Tests` - `packaged` `loadable bundle` which is used to test a binary. Plug-in architecture allows us to add a new functionality(test cases) as a separate module into existing binary

**Libraries and Frameworks**

[\[Library vs Framework\]][11]

[Martin Fowler on InversionOfControl][12]

>A Library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
>
>A Framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points. The main control of the program is inverted, moved away from you to the framework. This phenomenon is Inversion of Control (also known as the Hollywood Principle - "Don't call us, we'll call you"

**Libraries and Frameworks on iOS**

They can help you to solve: modularity, reusing, encapsulation, improve build time

`Library` is a collection of Mach-O object files[<sup>\[check static or dynamic\]</sup>][13] compiled for one or more architectures.

`Static library` - `.a`(aka static archive library, static linked shared library[<sup>\[doc\]</sup>][14]) - When you add it into your application the **static linker** during **compilation time** will merge the object files from the library and package them along with the application object files into one single executable file. The disadvantage is a big output file

From Xcode 9.0, Swift static library is supported.

`Dynamic library` - `.dylib`(aka dynamic shared library, shared object, dynamically linked library[<sup>\[doc\]</sup>][14]) is **dynamically linked** with the app's executable at **load or runtime**, but not copied into it. On practice app's package will contain Frameworks folder with `.dylib` file. All iOS and macOS **system** libraries are `dynamic`. The disadvantage is a slow launch time since all dynamic libraries should be copied and linked.

[\[iOS static vs dynamic library\]][15]<br/>
[\[Static vs dynamic linking\]][16]

`Text-based stub library` - `.tbd`[<sup>\[About\]</sup>][17], it is a text stub of `dynamic library` which is located on a target device. As a result you should not package a dynamic library into your bundle. It has a size effect.

`Framework` aka `binary framework` - `.framework` is a `not packaged framework bundle`(to allow developers to easily take a look at headers and resources) which contains a compiled `static or dynamic` library, header files and resources.

`Static framework` contain a `static library` packaged with its resources.

`Dynamic framework` aka [`Embedded framework`][18] - from iOS v8 - contains the `dynamic library` and resources. In addition to that, dynamic framework can include different versions of the same dynamic library in a single bundle (`versioned bundle`). Also `Embedded framework` is used in `App Extension`

[[Static vs dynamic framework]][19]

[`Umbrella framework`][20] [<sup>\[Aggregate target\]</sup>][21] is a framework that contains other frameworks. It is not officially supported on iOS and that is why it **is not recommended** for developers to create them[<sup>\[Official doc\]</sup>][22]. In actuality it's a set of sub-frameworks(or Nested Frameworks). When you create a framework which has a dependency, a consumer (such as an app) is responsible for adding this dependency along with your framework into the project. As a developer, it's natural to try to find a way to transfer this duty from consumer to your's. As a result you think that `Umbrella framework` is the rescue but usually it leads to a serious issues with managing versions and complexity of creating and supporting it.

`Fake Framework` - is a result of specific operations under a `static library` to create a bundle with `.framework` extension that will behave yourself as a `dynamic framework`. This technic was used when Xcode did not support creating a framework since did not have a framework template. One of realisation of a [fake framework][23]. With Xcode 6, Apple has added iOS framework support.

`Modular Framework`[<sup>\[About\]</sup>][24] - `@import` it is a framework which contains a `.modulemap` file inside. Module can contains submodules. The main advantage is that you save a build time with `Modular Framework`.

`Universal Library or Framework` (aka Fat) [<sup>\[lipo\]</sup>][25] [<sup>\[Aggregate target\]</sup>][21] contains multiple architectures. For example your release build should support a some arch which you can regulate via `Build Active Architecture Only` [<sup>\[ONLY_ACTIVE_ARCH\]</sup>][26]

`XCFramework`[<sup>\[About\]</sup>][27] was introduced by Xcode 11 and it is a `bundle` which includes multiple architectures(arm, x86_64...) and platforms(iOS, MacOS...). It should replace a `Universal Framework`

`Dependency`[<sup>\[About\]</sup>][28] You are able to use third party code as a part of your target. It allows you to reuse a code from a lot of sources like - another project, project in the same workspace, another target, library, framework etc.

**How to build and use a Static Library:**

- [\[Swift consumer -> Swift static library\]][29]
- [\[Swift consumer -> Objective-C static library\]][30]
- [\[Objective-C consumer -> Swift static library\]][31]
- [\[Objective-C consumer -> Objective-C static library\]][32]

**How to build and use a Dynamic Framework[<sup>\[change to static\]</sup>][19]**

- [\[Swift consumer -> Swift dynamic framework\]][33]
- [\[Swift consumer -> Objective-C dynamic framework\]][34]
- [\[Objective-C consumer -> Swift dynamic framework\]][35]
- [\[Objective-C consumer -> Objective-C dynamic framework\]][36]

[\[Xcode Build System\]][37]<br/>
[\[Xcode components\]][28]<br/>
[\[Dynamic linker\]][38]


[1]:

[To see links please register here]

[2]:

[To see links please register here]

[3]:

[To see links please register here]

[4]:

[To see links please register here]

[5]:

[To see links please register here]

[6]:

[To see links please register here]

[7]:

[To see links please register here]

[8]:

[To see links please register here]

[9]:

[To see links please register here]

[10]:

[To see links please register here]

[11]:

[To see links please register here]

[12]:

[To see links please register here]

[13]:

[To see links please register here]

[14]:

[To see links please register here]

[15]:

[To see links please register here]

[16]:

[To see links please register here]

[17]:

[To see links please register here]

[18]:

[To see links please register here]

[19]:

[To see links please register here]

[20]:

[To see links please register here]

[21]:

[To see links please register here]

[22]:

[To see links please register here]

[23]:

[To see links please register here]

[24]:

[To see links please register here]

[25]:

[To see links please register here]

[26]:

[To see links please register here]

[27]:

[To see links please register here]

[28]:

[To see links please register here]

[29]:

[To see links please register here]

[30]:

[To see links please register here]

[31]:

[To see links please register here]

[32]:

[To see links please register here]

[33]:

[To see links please register here]

[34]:

[To see links please register here]

[35]:

[To see links please register here]

[36]:

[To see links please register here]

[37]:

[To see links please register here]

[38]:

[To see links please register here]

First, some general definitions (specific to iOS):

**Static library**, formally *Static Shared Library* - a unit of code linked at compile time, which does not change.

However, iOS static libraries are **not** allowed to contain images/assets (only code). You can get around this challenge by using a **media bundle** though.

A better, more formal definition can be found on Wikipedia <a href="http://en.wikipedia.org/wiki/Static_library"> here</a>.

**Dynamic library**, formally *Dynamic Shared Library* - binds symbols at runtime. When symbol is resolved, the corresponding module that includes that symbol is linked.

It's recommended to use Dynamic Shared libraries due to a lot of advantages. However, the app launch was slightly slower in earlier version of Mach-O than the app with static libraries. Latest versions are much quicker than the app with static libraries.

Apple does not recommend to use **Standalone** Dynamic Shared libraries - this kind of Dynamic Shared libraries makes sense for macOS platform only (the library is stored at /use/lib and only Apple can formally do that), but non-standalone Dynamic Shared libraries are parts of any framework today (.framework bundle).

**Framework** (aka .framework file) - is just a bundle (same as app bundle with minor differences). It's a folder with a group of resources:
- dynamic/static shared library;
- nib files;
- localised strings;
- header files;
- documentation;
- asset files, etc.

Hence, you can actually have a **static framework** or a **dynamic framework**, which are just containers with either static shared library or dynamic shared library.

See the <a href="http://en.wikipedia.org/wiki/Software_framework">Wiki on Software Framework</a> for more details.

Hence on iOS, your only option is basically to use a static shared library (`.a` file) or framework (with static or dynamic shared library inside).

**EDIT**

Regarding a *subproject* within a project, as far as I know, to get this to work/compile correctly, you essentially have to set up a compile chain where the subproject is compiled first, which creates a static framework `.a` file that is used as a dependency by the project.

Here's another useful tutorial which talks about this:

[To see links please register here]