[null,null,["最后更新时间 (UTC):2025-08-17。"],[],[],null,["\u003cbr /\u003e\n\nBeginning with CocoaPods 1.9.0 and Firebase 7, you can choose whether your\nFirebase dependencies are built as static or dynamic frameworks. We recommend\nusing static frameworks unless you require certain dynamic library behaviors.\n\nNote that libraries developed outside of GitHub can only be linked statically\neven with CocoaPods 1.9.0 and later. Currently, this library list includes\nAdMob, Analytics, Firebase ML, and Performance Monitoring. All other distribution\nchannels, including the zip file, Swift Package Manager, and Carthage provide\nstatically linked libraries only.\n\nThis document assumes a working knowledge of dynamic and static linking on\nApple platforms. If you're unfamiliar with these concepts, take a look at the\nfollowing documentation:\n\n- [Mach-O Programming Topics](//developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/MachOTopics/0-Introduction/introduction.html#//apple_ref/doc/uid/TP40001827-SW1)\n- [Dynamic Library Programming Topics](//developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/000-Introduction/Introduction.html)\n- [Using Firebase in libraries](//github.com/firebase/firebase-ios-sdk/blob/master/docs/firebase_in_libraries.md)\n\nSince this document is concerned with the types of library linkage and not the\nloading of non-executable resource bundles, the terms *library* and *framework*\nare used interchangeably.\n\nStatic linking\n\nStatically linked libraries are bundled into your application executable at\nbuild time. As a result, the object files in the static library will be present\nin your app when it launches and do not need to be resolved at app-launch time\nby the dynamic linker. Consequently, apps using static linking will launch\nfaster. This comes at the expense of a slightly larger binary / app executable,\nalthough it should be noted that the larger executable size will be offset by\nthe lack of bundled dynamic libraries.\n\nYou can force static linking of Firebase dependencies by explicitly specifying\nthe linkage in your Podfile: \n\n # cocoapods \u003e= 1.9.0\n use_frameworks! :linkage =\u003e :static\n\n| **Note:** Swift Package Manager, Carthage, and the zip file provide statically linked libraries only.\n\nDynamic linking\n\nDynamically linked libraries are stored in your app bundle separately from your\napp's main executable, and they must be loaded at app-launch time by the dynamic\nlinker. Apple's frameworks are all linked dynamically to enable code-sharing\nbetween processes; similarly, you can use dynamic frameworks to share code\nbetween your app and extension targets. You cannot share dynamic frameworks\nbetween separate applications, even if they are both signed by the same\ndeveloper.\n\nIf you want to use Firebase as a dependency of a dynamic framework target, you\nalso need to link Firebase dynamically; otherwise you'll run into\n[duplicate class definitions](//github.com/firebase/firebase-ios-sdk/blob/master/docs/firebase_in_libraries.md)\nin your app's runtime. Dynamic linking is the default behavior with\n`use_frameworks!`, but you can still explicitly specify dynamic linkage in your\nPodfile: \n\n # cocoapods \u003e= 1.9.0\n use_frameworks! :linkage =\u003e :dynamic\n\nNote that dynamic linking may increase your app's launch time, especially if\nyour app has a lot of dependencies.\n| **Note:** Swift Package Manager, Carthage, and the zip file provide statically linked libraries only."]]