“How many installs did we get?” sounds like a simple questionright up until you try to answer it on iOS. Suddenly you’re staring at three dashboards, two definitions of “install,” one privacy prompt, and a teammate asking if “first_open” is a Pokemon evolution.

This guide shows you how to track iOS app installs with Firebase in a way that’s accurate, explainable, and actually useful for growth decisions. You’ll set up Firebase Analytics, understand what “install” means in Firebase-land (spoiler: it’s really “first launch after install”), build an activation funnel, and learn how to handle modern attribution realities like SKAdNetwork and Apple Adswithout turning your analytics into a haunted house of mismatched numbers.

What “Install Tracking” Really Means on iOS (and Why It’s Confusing)

On iOS, “install tracking” typically breaks into three layers. If you don’t separate these, you’ll spend the next quarter arguing in Slack with screenshots.

1) App Store activity (store-side)

App Store Connect can tell you about product page views, first-time downloads, redownloads, and conversion rates. This is store-side data: what happened in the App Store ecosystem.

2) App activation (device-side)

Your app can only measure what happens after the app runs on a device. Firebase calls the first app launch after install (or reinstall) the first_open event. This is usually the closest thing to “an install that mattered,” because the user actually opened the app.

3) Attribution (marketing-side)

“Which campaign drove the install?” is the hardest layer on iOS. Privacy changes mean you often get aggregated, delayed, or limited data (hello, SKAdNetwork). Firebase can help with conversion measurement and behavior tracking, but full-fidelity multi-network attribution often requires additional tooling (or at least realistic expectations).

The good news: you can still build reliable install and activation tracking with Firebaseespecially if you define what you mean by “install” and stick to it consistently.

How Firebase Counts iOS “Installs”: The Key Events You Actually Need

Once Firebase Analytics is integrated, it automatically collects certain baseline events (no extra code required). For install tracking, the headline is first_open: it fires the first time the app is launched after being installed or reinstalled. In other words, Firebase is measuring “first run,” not “download completed.”

Firebase also uses the Firebase Installations service, which creates a per-install app instance identifier (commonly discussed as an installation ID / FID concept). You generally don’t use this as a marketing ID (please don’t), but it helps Firebase services recognize an installed instance and power features across the platform.

Practical takeaway: for most teams, your baseline “installs” KPI in Firebase is: Unique users (or devices) with first_open over a period of time. Then you layer activation events on top to separate “curious downloads” from “real users.”

Step-by-Step: Track iOS App Installs with Firebase Analytics

Step 1: Create a Firebase project and register your iOS app

1. Create a project in the Firebase console.
2. Register your iOS app using the Bundle ID from Xcode (case-sensitive).
3. Download GoogleService-Info.plist and add it to your Xcode project.

Step 2: Install the Firebase SDK (Swift Package Manager recommended)

Firebase supports multiple installation methods, but Swift Package Manager (SPM) is commonly recommended for new Apple projects. Add the packages you needat minimum: FirebaseAnalytics (and FirebaseCore will come along for the ride).

Step 3: Initialize Firebase in your app

Initialization differs depending on whether you use UIKit or SwiftUI. Here are the two common patterns.

UIKit (AppDelegate)

SwiftUI (@main App)

Step 4: Verify data is flowing (DebugView is your best friend)

Don’t wait a day and “hope it worked.” Use DebugView to confirm events arrive from your device during development. When debugging is enabled, you can watch events appear almost immediately, including first_open (if it’s truly a fresh install on that test device).

Pro tip: to test first_open repeatedly, you’ll need to uninstall the app, reinstall, and open it again. If you keep rebuilding over the same install, you won’t always see first_open because… well… it’s not the first open. Firebase is literal like that.

Install Tracking “Done Right”: Build an Activation Funnel (Not Just a Vanity Counter)

Counting first_open is a start. But install tracking becomes powerful when you can answer: “How many new users became active users?”

Define your activation moment

Activation depends on your product. Examples:

• Marketplace app: completes registration + views a listing
• Subscription app: starts trial or completes paywall view
• Utility app: completes onboarding + uses the core feature once

Log recommended events (and keep them consistent)

Firebase/Google Analytics has a list of recommended event names and parameters. Using them makes reporting and integrations smoother (and it keeps your analytics from turning into a junk drawer).

Example: log a sign_up completion event

Example: log onboarding completion

Create an “Install → Activation” funnel

Your simplest funnel can be: first_open → onboarding_complete → sign_up → purchase. Once that exists, you’ll stop obsessing over raw installs and start optimizing the steps that move revenue.

Attribution on iOS: What Firebase Can (and Can’t) Tell You

Firebase is excellent for measuring behavior after users arrive. Attributionfiguring out which ad campaign drove the installis more limited on iOS because there’s no universal install referrer and privacy frameworks restrict user-level tracking across apps.

SKAdNetwork (SKAN): Apple’s privacy-first attribution framework

SKAdNetwork is Apple’s framework for attributing installs to ad networks in a privacy-preserving way. Instead of giving you user-level data, it provides structured postbacks that help advertisers understand campaign performanceoften with delays and aggregation. If you run paid acquisition at scale, you’ll hear “SKAN” enough that it starts showing up in your dreams.

Where Firebase fits: you can still use Firebase Analytics to understand what new users do after first_openretention, purchases, engagementwhile SKAN handles the ad-side measurement in aggregate.

Apple Ads (Search Ads) attribution: AdServices tokens

Apple provides an AdServices attribution token mechanism for Apple Ads attribution workflows on supported iOS versions. Many teams use an MMP (mobile measurement partner) to handle the server-side calls and edge cases, but the concept is the same: you retrieve a token and exchange it (directly or via a partner) for attribution data.

Conceptual example (token retrieval pattern)

Google Ads + Firebase: conversion measurement basics

If you advertise with Google, linking Firebase and Google Ads can help with conversion measurement for events like first_open and in-app actions (depending on configuration). The important nuance is that “conversion measurement” is not the same thing as “perfect user-level attribution across every network.” On iOS, you usually aim for dependable directional measurement and then validate results with multiple sources (including App Store Connect).

When you need a full attribution view: consider an MMP

If you’re running multi-network campaigns (Meta, TikTok, Google, Apple Ads, affiliates, influencers, etc.), an MMP like AppsFlyer, Adjust, Branch, or Singular can unify attribution logic and then pass meaningful data downstream. Many teams keep Firebase as the behavioral source of truth (events, funnels, retention) and use the MMP for campaign attribution and cost stitching.

Where to See Install Metrics in Firebase (and How to Make Them Actionable)

Use Firebase/GA4 reporting for first_open trends and cohorts

You can analyze new user volume using first_open and compare it over time to releases, marketing pushes, or App Store changes. The real win is cohorting: compare behavior for users who first opened in Week A vs Week B, or users acquired during a campaign vs a quiet period.

Export to BigQuery when you outgrow dashboards

Dashboards are greatuntil you need to answer questions like: “How many first_open users reached activation within 24 hours, by app version, excluding reinstalls?” That’s where exporting event data to BigQuery becomes valuable. It lets you build durable queries, join to backend systems, and standardize definitions across teams.

Example BigQuery-style query idea (conceptual)

Common Gotchas (AKA: Why Your “Install Numbers” Don’t Match)

• Downloads ≠ first_open. App Store Connect counts downloads; Firebase counts first app launches after install. Users can download and never open. Users can also redownload.
• Reinstalls inflate first_open. If someone deletes and reinstalls, first_open can fire again. That’s not “fraud,” it’s just how the event works.
• Testing can fool you. Installing via Xcode, reinstalling without uninstalling, and switching between debug/release can produce different-looking results.
• Privacy prompts change attribution, not basic in-app analytics. ATT impacts cross-app tracking and advertising identifiers; your first-party in-app event logging still needs to be designed responsibly and with privacy in mind.
• Deferred deep linking is not “set-and-forget.” If you relied on Firebase Dynamic Links in older setups, note that the service has been shut down (sunset) and you’ll need a replacement strategy for link flows.

A Copy-Paste Install Tracking Checklist for Your Next Sprint

1. Define “install” as first_open (activation starts on first run).
2. Track activation (onboarding_complete, sign_up, first_value_action).
3. Use recommended event names when possible for cleaner reports.
4. Validate with DebugView before shipping (save future-you a headache).
5. Compare sources: App Store Connect (downloads) vs Firebase (first_open).
6. Plan attribution realistically: SKAN for paid, Firebase for behavior, MMP if needed.
7. Document your KPI definitions so “install” doesn’t mean three things in three meetings.

Conclusion: The Most Useful Way to Track iOS App Installs with Firebase

If you only remember one thing, make it this: on iOS, “installs” are less meaningful than “first opens that turn into activated users.” Firebase gives you a strong foundationfirst_open for baseline acquisition, event tracking for activation, cohorts for retention, and scalable analysis via export when you’re ready.

Pair that with Apple’s privacy-first attribution reality (SKAdNetwork, Apple Ads tokens, aggregated reporting), and you’ll have a measurement setup that’s honest, actionable, and far less likely to spark a weekly numbers war.

500-Word Field Notes: Real-World iOS Install Tracking Experiences

Here’s what install tracking with Firebase looks like in the real worldwhere “best practices” meet “we launched at 6 p.m. and the CEO is refreshing the dashboard every 30 seconds.”

The first surprise is usually the gap between App Store downloads and Firebase first_open. Teams celebrate “10,000 downloads!” and then panic when first_open shows 7,200. That’s not Firebase missing datait’s reality. Plenty of people download an app and never open it (or open it days later). Once we started treating first_open as “activated install attempts,” our conversations got calmer and our goals got smarter.

The second surprise: reinstalls happen more than you think. In one project, first_open spiked on weekends. We assumed a campaign was crushing it. Turns out, a subset of users kept deleting the app to free space, then reinstalling before going out. first_open counted those as new first opens. The fix wasn’t “stop using first_open,” it was adding an activation metric and (when possible) linking behavior to an account-level user ID after login. Then we could separate “fresh new users” from “same person, new install.”

Third: QA and release testing can accidentally poison your confidence. If your team installs via Xcode, uses TestFlight, or tests on devices that already had the app, you can spend hours hunting for a missing first_open that never should have fired. We eventually created a simple test script: uninstall → reinstall → open → verify in DebugView → log a custom “qa_ping” event. It turned “analytics seems broken” into a 90-second checklist.

Fourth: attribution expectations need a reset on iOS. Stakeholders sometimes want “exactly which TikTok ad drove this exact user who bought a subscription 42 days later.” On iOS, you may not get that level of user-level clarity everywhere. What you can get is: (a) reliable store-side trends, (b) aggregated campaign performance via privacy frameworks like SKAN, and (c) extremely rich post-install behavior via Firebase. When we shifted reporting to “campaign cohorts and downstream revenue behavior,” decision-making improved and finger-pointing decreased.

Finally: the biggest win comes from tracking the “moment of value”, not the install itself. In a budgeting app, installs didn’t predict successconnecting a bank account did. In a photo editor, it was exporting the first image. In a meditation app, it was completing the first session. We used first_open as the entry point, then treated the first value action as the real KPI. Installs became a leading indicator, not the finish line.

In short: Firebase install tracking is most powerful when you treat it as a behavior system. Count first_open, yesbut optimize what happens next.