Why do we use use_frameworks! in CocoaPods?

Question

I have used use_frameworks! in CocoaPods Podfile many times. I just wonder why do we use it? I couldn't get the straight forward answer of it.

Example:

platform :ios, '8.0'
use_frameworks!

target "CityWhether" do
    pod 'Alamofire'
    pod 'SwiftyJSON'
end

Professoriate

Do you mean use_frameworks! WITH the exclamation point? I've always been confused about that since ! means NOT. – Squall

! on the end often means that the action has side effects. Where does ! at the end mean not? – Harvester

Answer 1

use_frameworks! tells CocoaPods that you want to use Frameworks instead of Static Libraries. Since Swift does not support Static Libraries you have to use frameworks.

---

In another answer, I explained the differences between Static Libraries and Frameworks:

Cocoa Touch Frameworks

They are always open-source and will be built just like your app. (So Xcode will sometimes compile it, when you run your app and always after you cleaned the project.) Frameworks only support iOS 8 and newer, but you can use Swift and Objective-C in the framework.

Cocoa Touch Static Libraries

As the name says, they are static. So they are already compiled, when you import them to your project. You can share them with others without showing them your code. Note that Static Libraries currently don't support Swift. You will have to use Objective-C within the library. The app itself can still be written in Swift.

Sources: My other answer | AddThis.com Blog

Imitate

Long story on the release notes blog.cocoapods.org/CocoaPods-0.36 – Olodort

static libraries now support swift as of Xcode 9 beta 4 - CocoaPods is being updated to support this, see github.com/CocoaPods/CocoaPods/issues/6899 – Zymolysis

Sort and sweet description.it's really helpful – Friulian

I'm confused. Given that you can't change the signed binary, is downloading a dynamic framework allowed? If not then what's the usage of use_frameworks or in general dynamic frameworks. And if they are allowed, then how do you bypass the restriction set not changing the signed binary? – Cai

The official CocoaPods doc confirms that this option makes sure that Frameworks are used instead of Static Libraries. Meanwhile, please don't think that it means that those Frameworks are always dynamic (linked dynamically). Since CocoaPods 1.9.0 you can specify linkage style (e.g. use_frameworks! :linkage => :static): guides.cocoapods.org/syntax/podfile.html#use_frameworks_bang – Grewitz

Answer 2

use_frameworks! tells cocoa pods to use dynamic libraries, and was very prevalent at one point due in particular to swift not supporting static libraries, meaning there was no choice - however you often don't need use_frameworks! anymore.

As of Xcode 9 beta 4, and CocoaPods 1.5.0, swift static libraries are now supported. The main advantage is faster app startup times, particularly if you have a lot of pods - iOS 10 and 11 are not the fastest when you have many dylibs.

CocoaPods 1.5.0 was released in early April 2018, so you may need to upgrade to get it: sudo gem install cocoapods.

I've found several pods that don't work correctly with static libraries yet though, so your mileage may vary.

Zymolysis

I did that and then I ran into same No such module errors. Is that a problem in those cocoapods? – Feeney

I had to add use_modular_headers! to my Podfile in order to make it work with pods that presumably require it but don't enable it by themselves yet. – Andaman

@Zymolysis "The main advantage is faster app startup times". This seems to run in contradiction to Apple's Dynamic Library documentation -- which makes the same claim of dlls: "minimizing its use of memory once it’s launched make the app launch faster". Is the implication here that dll's will result in faster launch times if the library being used is not required at launch time, or it is a popular library and therefore is already loaded into memory? – Glassblowing

@Glassblowing That page seems to be about macOS rather than iOS. But, yes, if the DLL isn't loaded till after start up then the dll would be a win. Sadly in the iOS case in the situations I've seen all the DLLs are loaded before the app finishes launching, so that makes things slower. There's at least one WWDC talk on the subject of optimising iOS app startup times and it explicitly mentioned something along the lines of making sure you didn't have more than 3 or 4 dlls. – Zymolysis

I think this is the video referenced above: developer.apple.com/videos/play/wwdc2016/406 I would encourage you to use the DYLD_PRINT_STATISTICS environment variable to measure your app launch speed and see what's best for you. – Backside

Answer 3

use_frameworks! declares that you want to use dynamic frameworks, instead of static libraries.

With Xcode 9.0 and CocoaPods 1.5.0 released, you could use static libraries with swift if you do not use use_frameworks!.

One problem with use_frameworks! is that all your framework in Pods/Products are frameworks.

Here is a related article: Basic overview of static and dynamic frameworks on ios

Nianiabi

> One performance with use_frameworks is that all your framework in Pods/Products is frameworks. One performance what? – Abirritant

The article you linked is awesome. I recommend everyone to go and see it – Cai

The provided link is no more working. – Variolous

Answer 4

Cocoapods use_frameworks

Cocoapods^[About] use_frameworks! is responsible for the type of binary:

• if use_frameworks! is present - dynamic framework
• if use_frameworks! is not present - static library

use_frameworks! has a reflection in Mach-O Type^[About] in a corresponding target of Pods project.

Timeline:

1. CocoaPods 0.36 introduced use_frameworks! which you had to use for Swift pod
2. CocoaPods 1.5.0 and Xcode 9 allowed you to have a choice

[Vocabulary]

Gallego

Answer 5

Adding

use_frameworks!

in the Podfile means that we want the listed frameworks to be dynamically installed instead as static frameworks.

Slog

Thank you but please give more details about dynamically install vs static install. – Jarret