Link Binary with libraries VS Embed Frameworks

Question

What's the difference in the build phases between putting a framework in "Link binary with libraries" or in "Embed frameworks"?

Answer 1

Link binary with libraries Link frameworks and libraries with your project’s object files to produce a binary file. You can link a target’s source files against libraries in the target’s active SDK or against external libraries.

Embed Frameworks You can create an embedded framework to share code between your app extension and its containing app.

-

Timeline (Look at this sentence) - "If your containing app target links to an embedded framework, it must include the arm64 architecture or it will be rejected by the App Store."

Answer 2

I have been looking at some answers here and there and would like to amend this learning if somebody comes across this question again.

In any case, if we want to use any of a frameworks resources (i.e. the API), we need to link to it. In that case we need to add it in the "Linked Frameworks and Libraries" section in the bottom of the General Target Settings.

If we embed a library we are shipping the library – as it is – with our app bundle. This could be handy e.g. on machines running macOS who certainly do not have a specific 3rd party library.

So, what about iOS? There is no possibility to install 3rd party libraries on an iOS device per se – plus Apple is very strict regarding fat frameworks (libraries built for multiple platforms). So there has to be a way for the libraries to be delivered anyway? Since just linking them is not enough for the user of our application what other possibilities do we have?

That's where a peculiar build phase comes into play. In the project settings under Build Phases there's the link binary with libraries section. This steps strips the unnecessary parts from the fat frameworks and leaves the necessary parts with the bundle so that it is able to run on a device that is agnostic about the app's dependencies.