120

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
Iulian Onofrei
  • 7,489
  • 8
  • 59
  • 96
harikrista
  • 1,201
  • 2
  • 8
  • 8

5 Answers5

141

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

Iulian Onofrei
  • 7,489
  • 8
  • 59
  • 96
FelixSFD
  • 5,456
  • 10
  • 40
  • 106
  • 3
    Long story on the release notes https://blog.cocoapods.org/CocoaPods-0.36/ – Jaime Agudo Jun 15 '17 at 10:12
  • 8
    static libraries now support swift as of Xcode 9 beta 4 - CocoaPods is being updated to support this, see https://github.com/CocoaPods/CocoaPods/issues/6899 – JosephH Jul 25 '17 at 19:09
  • Sort and sweet description.it's really helpful – Piyush Apr 04 '18 at 09:21
  • 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? – Honey Jan 18 '21 at 02:53
81

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.

JosephH
  • 36,107
  • 19
  • 126
  • 149
  • 2
    I did that and then I ran into same `No such module` errors. Is that a problem in those cocoapods? – Alper Jun 22 '18 at 07:39
  • 3
    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. – Adrian Aug 23 '18 at 13:15
  • 4
    @JosephH "The main advantage is faster app startup times". This seems to run in contradiction to [Apple's Dynamic Library documentation](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/OverviewOfDynamicLibraries.html) -- 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? – TolkienWASP Sep 10 '18 at 16:18
  • 3
    @TolkienWASP 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. – JosephH Sep 11 '18 at 20:51
  • 1
    I think this is the video referenced above: https://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. – iMacHumphries Apr 19 '20 at 20:19
4

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

Iulian Onofrei
  • 7,489
  • 8
  • 59
  • 96
mistdon
  • 1,413
  • 9
  • 13
2

Cocoapod's[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]

yoAlex5
  • 13,571
  • 5
  • 105
  • 98
0

Adding

use_frameworks!

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

Chiara
  • 368
  • 4
  • 10