# CocoaPods: “The following Swift pods cannot yet be integrated as static libraries” (FirebaseCoreInternal)

> pod install fails: Swift pods cannot yet be integrated as static libraries, FirebaseCoreInternal. Add use_frameworks! or move the app to Swift Package Manager.

Canonical: https://app369.com/fix/flutter-swift-pods-cannot-be-integrated-as-static-libraries/
Last updated: 2026-11-08

pod install stops with The following Swift pods cannot yet be integrated as static libraries, naming FirebaseCoreInternal and GoogleUtilities, which does not define modules. Firebase’s Swift pods need modules, and a Podfile without use_frameworks! builds every pod as a plain static library. It shows up in Flutter, React Native and native iOS apps after adding or upgrading Firebase.

**Short answer**

In ios/Podfile, put use_frameworks! (or use_frameworks! :linkage => :static) inside the app target, then run pod install again. In a Flutter app on 3.44 or later, the better fix is Swift Package Manager: upgrade the firebase_ packages to versions that support it (firebase_core 4.x), run flutter clean and flutter run, and Flutter builds Firebase as a Swift package instead of a pod.

## **Why the pods can’t be static libraries, and the fix**

1. 01 ### **The Podfile has no use_frameworks!**
  > “Podfiles must include use_frameworks! (dynamic linking) or use_frameworks! :linkage => :static” [**Firebase, Firebase installation methods**](https://firebase.google.com/docs/ios/installation-methods) Firebase requires frameworks. Current Flutter templates already have this line, so in a Flutter app it was deleted or the Podfile is old. Add it inside the app target, above the pods (in Flutter, above flutter_install_all_ios_pods). If another pod breaks with dynamic frameworks, use the static linkage form.```
target 'Runner' do
  use_frameworks! :linkage => :static   # or plain use_frameworks!
  flutter_install_all_ios_pods File.dirname(File.realpath(__FILE__))
end
```
2. 02 ### **A Flutter app still on CocoaPods**
  > “As of the 3.44 release, Flutter's Swift Package Manager (SwiftPM) support is on by default.” [**Flutter, Swift Package Manager for app developers**](https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-app-developers) Recent Flutter builds plugins as Swift packages by default, and current FlutterFire plugins support it, so Firebase stops coming in as pods. Upgrade Flutter and the firebase_ packages, then rebuild. If any other plugin lacks Swift Package Manager support, CocoaPods still runs for it and use_frameworks! must stay; each plugin’s pub.dev page shows whether it supports it.```
flutter upgrade
flutter pub outdated   # raise the firebase_ packages to their latest versions in pubspec.yaml
flutter clean
flutter run
```
3. 03 ### **Swift Package Manager was turned off**
  > “Flutter falls back to CocoaPods for dependencies that don't yet support Swift Package Manager.” [**Flutter, Swift Package Manager for app developers**](https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-app-developers) If someone disabled it to work around an older issue, Flutter keeps using CocoaPods for everything. Turn it back on and rebuild.```
flutter config --enable-swift-package-manager
flutter clean
flutter run
```
4. 04 ### **A native iOS app that can leave CocoaPods**
  > “If migrating from a CocoaPods-based project, run pod deintegrate to remove CocoaPods from your Xcode project.” [**Firebase, Firebase installation methods**](https://firebase.google.com/docs/ios/installation-methods) Without Flutter, move Firebase to Swift Package Manager in Xcode: remove CocoaPods, then add the firebase-ios-sdk package under File, Add Package Dependencies.```
pod deintegrate
# then in Xcode: File > Add Package Dependencies > https://github.com/firebase/firebase-ios-sdk.git
```

Checked against the vendor’s docs on November 8, 2026: [Firebase: Installation methods for Apple platforms](https://firebase.google.com/docs/ios/installation-methods); [CocoaPods: Podfile syntax (use_frameworks!)](https://guides.cocoapods.org/syntax/podfile.html); [Flutter: Swift Package Manager for app developers](https://docs.flutter.dev/packages-and-plugins/swift-package-manager/for-app-developers).

## **Rather hand it over?**

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

- [from $450**App Fix Ticket**One reproducible bug in an existing mobile or web app, diagnosed and fixed.**See scope and start**](https://app369.com/fixed-price/flutter-firebase-bug-fix/)
- [from $450**AI-Built App Rescue**A Lovable, Bolt or Cursor app checked end to end in 3 days, then its worst problems fixed at a fixed price.****No issues worth fixing, no charge.**** If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.**See scope and start**](https://app369.com/fixed-price/ai-app-rescue/)

Related: [**Flutter pod install failed**](https://app369.com/fix/flutter-pod-install-failed/) · [**Flutter “Flutter/Flutter.h file not found”**](https://app369.com/fix/flutter-flutter-h-file-not-found/) · [**Xcode “No such module”**](https://app369.com/fix/xcode-no-such-module/) · [**Expo native module cannot be null**](https://app369.com/fix/expo-native-module-cannot-be-null/)

Questions

## **More on this error**

<details>

<summary>**The error suggests use_modular_headers!. Should I use that instead? **+</summary>

It can get pod install through, but Firebase documents use_frameworks!, so that is the setting its pods are tested with. Use modular headers only when a pod you can’t replace breaks under frameworks.

</details>

<details>

<summary>**Is CocoaPods going away? **+</summary>

Flutter keeps CocoaPods in maintenance mode, and its docs say the CocoaPods registry becomes read-only on December 2, 2026. Moving to Swift Package Manager now avoids the next round of pod errors.

</details>

<details>

<summary>**Can you fix it for me? **+</summary>

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

</details>

A different error?

## **Describe it and get a written quote**

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.

[**Describe your problem **→](https://app369.com/contact/) [**All fixes**](https://app369.com/fix/)