A complete walkthrough of adding Firebase to a native iOS app: create the project, download GoogleService-Info.plist, add the SDK via Swift Package Manager, and call FirebaseApp.configure().
Adding Firebase to an iOS app is straightforward, but a few prerequisites save you time. You need a Mac running a current version of Xcode, since Firebase is only a backend and you still build and sign the app with Apple's toolchain. You need a Google account to access the Firebase console at console.firebase.google.com. You should already have an Xcode project, or create a fresh SwiftUI App template, and you must know your app's bundle identifier exactly as it appears in the target's General settings, because it has to match what you register in Firebase. If you plan to use certain services later, such as Cloud Messaging for push, you will also need a paid Apple Developer Program membership and an APNs authentication key, but those are not required just to add the SDK. Finally, decide up front whether you will use Swift Package Manager, which is now the recommended integration path, or CocoaPods. This guide uses Swift Package Manager because it is built into Xcode and avoids a separate dependency manager. Have your bundle identifier, a Google account, and a working Xcode project ready, and the whole integration takes only a few minutes.
Open the Firebase console in your browser and sign in with your Google account. Click Add project, give it a name, and step through the wizard. You will be asked whether to enable Google Analytics for the project; you can turn it on or off depending on whether you want analytics data, and it does not affect the rest of the setup. After a short provisioning step, Firebase creates the project and drops you on its dashboard. A Firebase project is a container that can hold multiple apps, so a single project can serve your iOS app, an Android version, and a web app that all share the same backend data. Keep the console tab open, because the next step registers your specific iOS app inside this project. If your organization already has a Firebase or Google Cloud project, you can register the iOS app there instead of creating a new one; a Firebase project and its underlying Google Cloud project are two views of the same thing, which matters later when you set budget alerts or use Cloud Functions that bill through Google Cloud.
On the Firebase project dashboard, click the iOS+ icon to start registering an Apple app. The most important field is the Apple bundle ID: enter it exactly as it appears in Xcode under your target's General tab, for example com.yourcompany.YourApp. A mismatch here is the single most common reason configuration fails later, so copy and paste rather than retype. The App nickname and App Store ID fields are optional; the nickname is just a label in the console, and the App Store ID can be added later once your app is live. Click Register app to continue. Firebase now knows about your specific iOS target and can generate the configuration file that ties the SDK on the device back to the correct backend project. Do not skip ahead in the console wizard yet, because the next screen offers the config file you need to download. If you maintain separate bundle IDs for debug and release builds, register each as its own app in the project so each gets a config file matching its identifier.
After registering the app, the console prompts you to download GoogleService-Info.plist. This file contains the project identifiers and client API keys the SDK uses to connect to your backend; it is not a server secret in the traditional sense, but it is app-specific, so use the file for the matching bundle ID. Download it, then drag it into your Xcode project navigator, ideally near the top level next to your App entry point. Xcode shows a dialog when you add the file: make sure Copy items if needed is checked and, critically, that your app target is selected under Add to targets. If the file is present in the navigator but not a member of the target, the SDK cannot find it at runtime and FirebaseApp.configure() will crash. You can verify membership by selecting the file and checking the Target Membership section in the File Inspector on the right. Add the file for every target that runs Firebase, such as an app clip or a notification service extension, if applicable. This one step is responsible for the majority of first-run configuration crashes, so it is worth double-checking before you move on.
In Xcode, go to File, then Add Package Dependencies. In the search field, paste the Firebase iOS SDK repository URL, https://github.com/firebase/firebase-ios-sdk, and press return. Xcode fetches the package and shows the version rule; the Up to Next Major Version default is usually correct. Click Add Package. Xcode then presents the list of Firebase products contained in the package, because the SDK is modular: you only add the libraries you actually use rather than the entire suite. For a first setup, select FirebaseAnalytics or, if you prefer no analytics dependency, just FirebaseCore, and add any others you know you need, such as FirebaseAuth or FirebaseFirestore. Make sure each selected library is assigned to your app target in the dialog. Click Add Package again to finish. Xcode resolves and downloads the packages, which can take a minute or two on first fetch because the SDK pulls in transitive dependencies like GoogleUtilities. You can always return to your project's Package Dependencies and add more Firebase products later without redoing the whole process, so start minimal and grow the list as you adopt each service.
With the SDK added and the plist in place, you initialize Firebase once at launch by calling FirebaseApp.configure(). In a SwiftUI app, the clean approach is an app delegate adaptor. Create a class conforming to NSObject and UIApplicationDelegate, import FirebaseCore, and in application(_:didFinishLaunchingWithOptions:) call FirebaseApp.configure() before returning true. Then in your App struct, add @UIApplicationDelegateAdaptor(AppDelegate.self) var delegate to wire it up. Alternatively, for a minimal app you can call FirebaseApp.configure() inside an init() on your App struct, though the app delegate pattern is more robust and is what Firebase's own docs recommend, especially once you add push notifications, which need delegate callbacks anyway. Either way, configure() must run exactly once and before you use any Firebase service. Build and run on a simulator or device; if the app launches without crashing and you see Firebase initialization logs in the Xcode console, the integration is working. From here you can start calling individual services like Auth or Firestore by importing their modules and using their APIs, confident that the shared FirebaseApp instance is already configured.
To confirm everything is connected, run the app and watch the Xcode console for Firebase's startup log lines, which typically mention the configured project. If you enabled Analytics, the Firebase console's DebugView or the Analytics dashboard will begin showing events within a short window once your device is sending data, though there is normal reporting latency. A quick and reliable smoke test is to add Crashlytics and force a test crash, since Crashlytics confirms both that the SDK is wired up and that your backend project is receiving data. Once initialization is solid, add the specific products your app needs: FirebaseAuth for sign-in, FirebaseFirestore for data, FirebaseMessaging for push. Keep FirebaseApp.configure() as the single initialization point and avoid calling Firebase APIs before it runs. If you later add app extensions or a second target, remember each one needs the GoogleService-Info.plist as a target member and its own configure call. With the base integration done, the rest of Firebase is largely a matter of importing a module and calling its API, which is exactly the low-friction experience the platform is known for.
Swift Package Manager is the recommended path for most projects because it is built into Xcode and needs no separate tool. CocoaPods still works and some older projects or specific dependencies prefer it, but for a new app, SPM with the firebase-ios-sdk repository URL is the simplest and best-supported option.
No. The Firebase iOS SDK is modular. When you add the package, Xcode lets you select only the products you use, such as FirebaseAuth or FirebaseFirestore. Adding fewer libraries keeps your binary smaller and build times shorter. You can add more products later without reconfiguring anything.
It is not a private key in the way a server secret is; it contains project identifiers and client API keys that are considered safe to embed in a shipped app. That said, it is specific to your app's bundle ID, and you should protect your backend with Firebase Security Rules and App Check rather than relying on the plist being hidden.
Call it exactly once at launch, before you use any Firebase service. In SwiftUI the recommended pattern is an app delegate adaptor whose didFinishLaunchingWithOptions calls FirebaseApp.configure(). A minimal alternative is calling it in your App struct's init(), but the app delegate approach scales better once you add push notifications.
Yes. A Firebase project is a container that can hold multiple apps across platforms sharing the same backend, database, and auth users. You register each platform app separately and each gets its own config file, but they connect to the same project.
The most common cause is that GoogleService-Info.plist is in the project navigator but not a member of the app target, so the SDK cannot find it during configure(). Select the file, open the File Inspector, and confirm your app target is checked under Target Membership.