CocoaPods 1.9.0 및 Firebase 7부터 Firebase 종속 항목을 정적 프레임워크 또는 동적 프레임워크로 빌드할지 여부를 선택할 수 있습니다. 특정한 동적 라이브러리 동작이 필요하지 않다면 정적 프레임워크를 사용하는 것이 좋습니다.
GitHub 외부에서 개발된 라이브러리는 CocoaPods 1.9.0 이상을 사용하는 경우에도 정적으로만 연결할 수 있습니다. 현재 이 라이브러리 목록에는 AdMob, Analytics, Firebase ML, Performance Monitoring이 포함되어 있습니다. ZIP 파일, Swift Package Manager, Carthage를 포함한 다른 모든 배포 채널은 정적으로 연결된 라이브러리만 제공합니다.
이 문서에서는 Apple 플랫폼의 동적 및 정적 연결에 대한 실무 지식이 있다고 가정합니다. 이 개념에 익숙하지 않다면 다음 문서를 참조하세요.
이 문서에서는 라이브러리 연결 유형에 대한 내용을 설명할 뿐 실행 불가능한 리소스 번들의 로드에 대해서는 다루지 않으므로 라이브러리와 프레임워크라는 용어를 같은 의미로 사용합니다.
정적 연결
정적으로 연결된 라이브러리는 빌드 시 애플리케이션 실행 파일에 번들로 포함됩니다. 따라서 앱이 시작될 때 앱에 정적 라이브러리의 객체 파일이 있으므로 앱 시작 시 동적 링커가 라이브러리를 확인할 필요가 없습니다. 결과적으로 정적 연결을 사용하는 앱이 더 빠르게 시작됩니다. 다만 바이너리/앱 실행 파일의 크기가 약간 더 큰 편인데 번들로 포함된 동적 라이브러리가 없기 때문에 그 부분은 큰 실행 파일 크기에서 상쇄됩니다.
Podfile에서 연결을 명시적으로 지정하여 Firebase 종속 항목의 정적 연결을 강제 적용할 수 있습니다.
동적으로 연결된 라이브러리는 앱의 기본 실행 파일과는 별도로 App Bundle에 저장되며 앱 시작 시에 동적 링커가 로드해야 합니다. Apple 프레임워크는 모두 동적으로 연결되어 프로세스 간 코드 공유를 지원합니다. 마찬가지로 동적 프레임워크를 사용하여 앱과 확장 대상 간에 코드를 공유할 수 있습니다. 동일한 개발자가 두 애플리케이션을 모두 서명하더라도 각 애플리케이션 간에 동적 프레임워크를 공유할 수 없습니다.
Firebase를 동적 프레임워크 대상의 종속 항목으로 사용하려면 Firebase를 동적으로 연결해야 합니다. 그렇지 않으면 앱의 런타임에 중복 클래스 정의가 발생합니다. 동적 연결은 use_frameworks!의 기본 동작이지만 Podfile에서 동적 연결을 명시적으로도 지정할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],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."]]
