If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/firebase/quickstart-ios shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

GO — Healthy across the board

• Last commit 2w ago
• 6 active contributors
• Distributed ownership (top contributor 42% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live firebase/quickstart-ios repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/firebase/quickstart-ios.

What it runs against: a local clone of firebase/quickstart-ios — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in firebase/quickstart-ios | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 41 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of firebase/quickstart-ios. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/firebase/quickstart-ios.git
#   cd quickstart-ios
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of firebase/quickstart-ios and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "firebase/quickstart-ios(\\.git)?\\b" \\
  && ok "origin remote is firebase/quickstart-ios" \\
  || miss "origin remote is not firebase/quickstart-ios (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f ".github/workflows/check.yml" \\
  && ok ".github/workflows/check.yml" \\
  || miss "missing critical file: .github/workflows/check.yml"
test -f "scripts/style.sh" \\
  && ok "scripts/style.sh" \\
  || miss "missing critical file: scripts/style.sh"
test -f "abtesting/ABTestingExample.xcodeproj/project.pbxproj" \\
  && ok "abtesting/ABTestingExample.xcodeproj/project.pbxproj" \\
  || miss "missing critical file: abtesting/ABTestingExample.xcodeproj/project.pbxproj"
test -f "TestUtils/FIREGHelper.h" \\
  && ok "TestUtils/FIREGHelper.h" \\
  || miss "missing critical file: TestUtils/FIREGHelper.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 41 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~11d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/firebase/quickstart-ios"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Firebase Quickstart Samples for iOS is a collection of ~15 runnable example projects demonstrating Firebase APIs (Firestore, Authentication, Storage, Cloud Messaging, Analytics, Crashlytics, Remote Config, etc.) on iOS. Each sample includes both Swift and Objective-C implementations and runs as a standalone Xcode project after adding a GoogleService-Info.plist file from Firebase Console. Monorepo structure: 15 top-level directories (abtesting/, analytics/, authentication/, config/, crashlytics/, database/, firestore/, functions/, messaging/, performance/, storage/, firebaseai/, etc.), each containing a .xcodeproj with multi-target schemes (iOS, macOS, watchOS, tvOS). TestUtils/ provides shared Auth and Sign-In helpers (FIREGHelper, FIREGSignInHelper). CI/CD via .github/workflows/ (one yml per service).

iOS developers learning Firebase integrations—engineers building their first Firebase app who need concrete, working code examples rather than documentation alone. Also used by Firebase SDK maintainers as reference implementations and CI test vectors.

Actively maintained and production-ready. The repo has 15+ samples with multi-platform support (iOS, macOS, watchOS, tvOS, Catalyst), CI workflows for each service (GitHub Actions in .github/workflows/), and heavy Swift content (617K lines). Latest activity visible in GitHub workflows suggests ongoing updates.

Low risk for a sample repo. No external package manager dependencies visible (no Podfile/Cartfile listed, likely uses CocoaPods or SPM managed via .xcodeproj). Main risks: GoogleService-Info.plist files must be manually configured per Firebase project (easy to forget), samples may lag behind Firebase SDK changes, and some older Objective-C code (40K lines) may receive less maintenance attention than Swift equivalents.

Active multi-service CI/CD with per-sample GitHub Actions workflows. Design documentation and media assets in abtesting/Design/ suggest recent UI updates. Code formatting enforcement via ./scripts/style.sh with mint + swiftformat integration indicates ongoing code quality maintenance.

Clone the repo, select a sample directory (e.g., cd firestore/), download GoogleService-Info.plist from Firebase Console for your project, replace the placeholder plist in that sample's root, open the .xcodeproj in Xcode, select a target (Swift or Objective-C), and run on a simulator or device.

Daily commands:

1. git clone https://github.com/firebase/quickstart-ios.git && cd quickstart-ios
2. brew install mint && mint bootstrap (for code formatting tools)
3. Navigate to sample: cd firestore/ (or any other sample)
4. Open project: open ABTestingExample.xcodeproj (adjust for your sample)
5. In Xcode: Product → Run (or Cmd+R) on desired target/scheme

• README.md — Entry point for all contributors; explains the repo structure, sample organization, and mandatory GoogleService-Info.plist setup process.
• .github/workflows/check.yml — CI/CD validation gate; enforces code style compliance via style.sh script for all PRs before merge.
• scripts/style.sh — Mandatory code formatting enforcement script; all contributors must run this before creating PRs to pass GitHub Actions checks.
• abtesting/ABTestingExample.xcodeproj/project.pbxproj — Xcode project configuration template; demonstrates multi-platform build structure (iOS, macOS, tvOS, watchOS, Catalyst) used across all samples.
• TestUtils/FIREGHelper.h — Shared test utilities header; provides common Firebase authentication and sign-in helpers used across multiple sample projects.
• analytics/AnalyticsExample/AppDelegate.swift — Primary entry point for iOS sample apps; shows Firebase SDK initialization pattern replicated across all quickstart samples.
• .google/packaging.yaml — Project metadata and packaging configuration; defines how samples are distributed and cataloged.

Add a New Firebase Sample Quickstart

1. Create new sample directory mirroring existing structure (e.g., newservice/NewServiceExample.xcodeproj) (abtesting/ABTestingExample.xcodeproj/project.pbxproj)
2. Copy and adapt AppDelegate.swift or SwiftUI app entry point, initialize Firebase SDK in application(_:didFinishLaunchingWithOptions:) (analytics/AnalyticsExample/AppDelegate.swift)
3. Create feature configuration class following AppConfig.swift pattern to manage service-specific settings (abtesting/Shared/AppConfig.swift)
4. Implement UI views (SwiftUI or UIKit) that demonstrate feature usage, following ContentView.swift or AnalyticsViewController.swift patterns (abtesting/Shared/ContentView.swift)
5. Download GoogleService-Info.plist from Firebase Console and place in sample root directory (abtesting/GoogleService-Info.plist)
6. Create GitHub Actions workflow file (e.g., .github/workflows/newservice.yml) following existing workflow pattern (.github/workflows/abtesting.yml)
7. Add sample entry to root README.md with description and bundle ID reference (README.md)

Add a New Platform Target (macOS/tvOS/watchOS/Catalyst)

1. Open .xcodeproj in Xcode and duplicate existing iOS target (abtesting/ABTestingExample.xcodeproj/project.pbxproj)
2. Create platform-specific Info.plist (e.g., 'ABTestingExample (macOS) Info.plist') with appropriate deployment target (abtesting/ABTestingExample (iOS) Info.plist)
3. Create or adapt Entitlements file for the platform (macOS requires .entitlements file) (abtesting/ABTestingExample (macOS).entitlements)
4. Update AppDelegate or create platform-specific scene delegate following SceneDelegate.swift pattern (analytics/AnalyticsExample/SceneDelegate.swift)
5. Create .xcscheme file in xcshareddata/xcschemes for the new platform target (abtesting/ABTestingExample.xcodeproj/xcshareddata/xcschemes/ABTestingExample (macOS).xcscheme)

Enforce Code Style Compliance

1. Review and understand code style requirements by examining the style.sh script referenced in README (README.md)
2. Run style.sh script locally before committing to auto-format code (.github/workflows/check.yml)
3. GitHub Actions will automatically validate style compliance on all PRs using check.yml workflow (.github/workflows/check.yml)
4. If style validation fails in CI, fix formatting issues and push again (CONTRIBUTING.md)

• SwiftUI & UIKit (dual support) — Demonstrates both modern SwiftUI patterns and legacy UIKit; enables developers targeting various iOS deployment targets and team preferences
• Multi-platform Xcode projects (iOS/macOS/tvOS/watchOS/Catalyst) — Shows Firebase SDK capabilities across all Apple platforms; increases sample reach and demonstrates platform-agnostic SDK design
• GitHub Actions CI/CD workflows — Automates testing, building, and style validation for each Firebase service sample; ensures sample code quality and compatibility
• Objective-C & Swift support — Targets both legacy Objective-C codebases and modern Swift projects; maximizes applicability to diverse production environments

• Multiple samples per Firebase service (e.g., Analytics has iOS UIKit, SwiftUI, macOS, tvOS variants)

  • Why: Comprehensively demonstrates all major platform and framework combinations for Firebase usage
  • Consequence: Increased maintenance burden; each sample variant must be kept in sync with SDK updates and best practices

• GoogleService-Info.plist stored per-sample, not in shared config

  • Why: Each sample can be tested independently with its own Firebase project without affecting others
  • Consequence: Developers must configure each sample separately; no cross-sample configuration reuse

• Shared TestUtils (Objective-C headers) vs. no centralized SwiftUI test helpers

  • Why: Legacy pattern supporting Objective-C codebases; modern SwiftUI samples add their own test logic (UITests.swift)
  • Consequence: Testing patterns are inconsistent; SwiftUI samples cannot easily share test infrastructure

• This repo does NOT implement production-ready Firebase applications; samples prioritize clarity and feature demonstration over error handling robustness
• Does NOT provide backend/Cloud Functions source code; Firebase Backend is assumed to be configured in Firebase Console
• Does NOT support Android or web platforms; iOS-specific only
• Does NOT implement complex state management libraries; samples use basic @State or property observers to keep examples accessible
• Does NOT provide comprehensive offline-first sync patterns; focused on connected happy-path scenarios

1. GoogleService-Info.plist is mandatory and per-Firebase-project—if missing or wrong bundleID, the app will fail at runtime. 2. Each sample is separate; no shared Podfile—CocoaPods pods are locked per .xcodeproj, so updating Firebase SDK in one sample doesn't affect others. 3. Swift and Objective-C targets in same project can have version drift; test both if modifying shared code. 4. Xcode scheme selection matters: ABTestingExample.xcscheme (iOS) vs ABTestingExample (macOS).xcscheme have different target memberships. 5. Code formatting (swiftformat) is enforced in CI; PRs will fail if style.sh hasn't been run.

• GoogleService-Info.plist Configuration — Every Firebase sample requires a valid plist matching your Firebase project's bundleID; without it, all Firebase SDK calls fail—this is the non-obvious bootstrap step before any code runs
• Xcode Multi-Target Schemes — Each sample uses separate .xcscheme files for iOS, macOS, watchOS, tvOS targets in one project; selecting the wrong scheme compiles against wrong platform SDKs and deployment targets
• Real-time Database vs Firestore Trade-offs — Samples for both database/ (Realtime Database) and firestore/ exist because they serve different use cases—understanding when to use each is crucial for Firebase app design
• A/B Testing Configuration — abtesting/ sample demonstrates Remote Config variants and analytics event tracking for A/B tests; the pattern is non-obvious (requires integrating Firebase Config + Analytics)
• Cloud Functions Integration — functions/ and messaging/ samples require backend Cloud Functions deployed separately; the iOS app calls them via HTTP—this client-backend coordination is a key Firebase architecture pattern
• Crashlytics Initialization — crashlytics/ sample shows that Crashlytics must be initialized before throwing test exceptions; improper setup causes silent failures with no error feedback
• Code Style Enforcement via CI — GitHub Actions runs ./scripts/style.sh (swiftformat via mint) on every PR; contributors must run locally first or CI blocks merge—non-compliance is a hidden blocker

• firebase/firebase-ios-sdk — The official Firebase SDK for iOS—the underlying libraries all quickstart samples depend on and demonstrate
• firebase/quickstart-android — Parallel repository with identical Firebase sample patterns for Android; useful for cross-platform consistency and API comparison
• firebase/quickstart-js — Web/Node.js equivalents of the same Firebase samples; helps developers learning Firebase across multiple platforms
• firebase/functions-samples — Companion repo with Cloud Functions examples; many quickstart-ios samples (functions/, messaging/) integrate with backend functions here
• google/swift-format — Upstream formatter dependency (integrated via mint in Mintfile); defines the code style rules enforced on PRs

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add missing GitHub Actions workflows for incomplete Firebase services

The .github/workflows directory has CI workflows for most Firebase services (abtesting, analytics, authentication, etc.), but based on the README's mention of 'Samples' section being incomplete, there are likely Firebase services with quickstart samples but no corresponding CI/CD validation. This ensures all samples stay buildable and up-to-date with Firebase SDK changes.

• [ ] Audit all sample directories (abtesting/, authentication/, firestore/, etc.) against existing workflows in .github/workflows/
• [ ] Identify samples without corresponding .yml workflow files
• [ ] Create new workflow files following the pattern of existing ones (e.g., abtesting.yml) that run build and unit tests
• [ ] Reference TestUtils/FIREGHelper.h and TestUtils/FIREGSignInHelper.h for authentication-dependent workflows
• [ ] Test workflows locally with act or similar tool before submitting

Complete the truncated code formatting documentation in README.md

The README.md ends abruptly mid-sentence at 'To ensure that the code is formatted consistently, run the script [./script' - this leaves contributors without clear guidance on code style expectations. Completing this section improves contributor onboarding and consistency across the repo.

• [ ] Check if a code formatting script exists in the repo root (e.g., scripts/format.sh or similar)
• [ ] Review Mintfile (Swift package manager) to identify linting/formatting tools in use
• [ ] Complete the README section with the actual script name, usage instructions, and any pre-commit hooks setup
• [ ] Add a 'Code Style' subsection explaining any SwiftLint rules or clang-format configuration if present
• [ ] Verify the formatting script works with both Objective-C and Swift samples

Add integration test suite for cross-platform Firebase samples

The file structure shows multiple platforms for each sample (iOS, macOS, tvOS, watchOS, catalyst) but no unified integration testing approach. Adding a shared test harness in TestUtils/ with platform-specific CI validation ensures all platform variants work correctly and don't diverge.

• [ ] Extend TestUtils/FIREGHelper.m and FIREGHelper.h with baseline integration test utilities (Firebase initialization, SDK version checks)
• [ ] Create a new test file TestUtils/FIREGIntegrationTests.swift for Swift sample validation
• [ ] Add a new GitHub Actions workflow (.github/workflows/integration-tests.yml) that runs XCTest against TestUtils for each platform
• [ ] Document test utilities in CONTRIBUTING.md with examples of how to add tests to new samples
• [ ] Validate the approach works with at least one existing sample (e.g., abtesting) before generalizing

• Add Firestore iOS sample tests: TestUtils/ has sign-in helpers but firestore/ sample lacks XCTest coverage—add unit tests for read/write operations in firestore/FirestoreExampleTests/
• Document multi-platform scheme setup: Design/ folder has media assets but lacks written guide on running samples on watchOS/tvOS—add PLATFORMS.md with per-scheme instructions
• Sync Authentication sample with latest SDK: authentication/ sample may lag behind Firebase Auth SDK changes—audit FIREGSignInHelper.m against current SDK API and file an issue or PR with updates

This Firebase iOS quickstart repository has a generally acceptable security posture for sample code. The main concerns are: (1) potential exposure of GoogleService-Info.plist configuration files containing Firebase credentials, (2) possible hardcoded test credentials in sample code that could mislead developers, (3) incomplete .gitignore configuration, and (4) need for proper secret handling in CI/CD workflows. As a quickstart/sample repository, the code is not intended for production use, but it should still model security best practices to guide developers toward secure implementations. No critical vulnerabilities were identified, but medium-priority improvements are recommended to prevent accidental credential exposure and to ensure the samples promote secure coding patterns.

• Medium · GoogleService-Info.plist Configuration File Exposure — abtesting/GoogleService-Info.plist and similar files in other sample directories. The GoogleService-Info.plist file is a Firebase configuration file that contains sensitive project identifiers and API keys. While this is a quickstart repository, having this file in version control (even if the actual sensitive values are placeholder/test values) could lead to accidental exposure of real credentials if developers copy this structure without proper sanitization. Fix: Ensure GoogleService-Info.plist files are added to .gitignore and provide a template file (GoogleService-Info.plist.example) instead. Document that developers must download their own credentials from the Firebase Console.
• Medium · Potential Hardcoded Test Credentials in Sample Code — TestUtils directory (FIREGHelper.m, FIREGSignInHelper.m) and sample app source files. As a quickstart/sample repository, there may be hardcoded test credentials, API keys, or authentication tokens in the source code (particularly in TestUtils and sample app files). While these may be test credentials, this pattern could mislead developers into hardcoding real credentials in their own applications. Fix: Review all TestUtils and sample code to ensure no real credentials are present. Add clear documentation showing the secure way to handle credentials (using environment variables, secure storage, or external configuration). Include comments flagging any test-only credentials as such.
• Medium · Missing .gitignore Entries for Sensitive Build Artifacts — .gitignore. The .gitignore file should explicitly exclude build artifacts, derived data, and configuration files that may contain sensitive information. Without proper .gitignore configuration, developers might accidentally commit build outputs containing temporary credentials or sensitive data. Fix: Verify and enhance .gitignore to include: *.xcarchive, build/, DerivedData/, .build/, *.xcworkspace/xcuserdata/, xcuserdata/, *.resolved (if using SPM), and other Xcode-generated files that may contain sensitive data.
• Low · GitHub Actions Workflows May Expose Secrets in Logs — .github/workflows/ (all .yml files). The CI/CD workflows in .github/workflows/ directories could potentially expose Firebase credentials or API keys if not properly configured. If these workflows use environment variables or secrets, they must be properly masked in logs. Fix: Audit all GitHub Actions workflows to ensure: 1) Secrets are defined in GitHub repository settings, not hardcoded in YAML, 2) Use of 'add-mask' command for sensitive output, 3) Debug logs are disabled in production workflows, 4) Only necessary permissions are granted to actions.
• Low · No Evidence of Dependency Lock File — Root directory and sample subdirectories. While Gemfile.lock and Mintfile are present (for Ruby and Swift package management), there's no visible CocoaPods lock file (Podfile.lock) or explicit dependency pinning for all samples. This could lead to inconsistent builds if dependencies are updated without verification. Fix: Ensure all samples use locked dependency versions: 1) Commit Podfile.lock files if using CocoaPods, 2) Use Package.resolved for SPM dependencies, 3) Document the expected Xcode and Firebase SDK versions, 4) Consider using a dependency scanning tool to detect known vulnerabilities.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.