Adding a New Firebase CocoaPod

Introduction

The Firebase build is driven by the contents of a podspec. It is helpful to use an existing podspec as a template when starting a new pod.

See the Podspec Syntax Reference for detailed instructions. Some Firebase specific guidance below:

s.deployment_target - Ideally should include ios, osx, and tvos. See FirebaseCore.podspec for the current Firebase minimum version settings.
s.dependency - Dependencies on other Firebase pods and pods in this repo should specify a version and allow minor version updates - like s.dependency 'FirebaseCore', '~> 6.6'. When initially defined, choose the most recently released minor version of the dependency.
s.pod_target_xcconfig - Add any specific build settings.
- For portability, any Firebase pod with other Firebase dependencies should build for c99 - 'GCC_C_LANGUAGE_STANDARD' => 'c99'.
- The pod's version should be passed in as a #define for FIRComponent registration. See examples of setting GCC_PREPROCESSOR_DEFINITIONS.
- All imports (outside of Public headers) should be repo relative - 'HEADER_SEARCH_PATHS' => '"${PODS_TARGET_SRCROOT}"'.
s.test_spec should be used for defining all unit and integration test suites.

The Firebase library Foo should be defined in FirebaseFoo.podspec. All of its contents should be in the FirebaseFoo directory.

FirebaseFoo/Sources - All source. Directory structure is up to the library owner. Any code from a non-Google open source project should be nested under a third_party directory.
FirebaseFoo/Sources/Public - Public Headers.
FirebaseFoo/Sources/Private - Private Headers (headers not part of public API, but available for explicit import by other Firebase pods)
FirebaseFoo/Tests/Unit - Required (If the library only has unit tests, Unit can be omitted.)
FirebaseFoo/Tests/Integration - Encouraged
FirebaseFoo/Tests/Sample - Optional
FirebaseFoo/Tests/{Other} - Optional

See Headers and Imports for details on managing headers and imports.

Set up a GitHub Action workflow for the pod. A good example template is storage.yml.

All code should comply with Objective-C and Swift style requirements and successfully pass the GitHub Action check phase. Run scripts/style.sh.

For GitHub tag management and public header change detection, add a GitHub api tag and update Dangerfile.

For top-level Firebase pods that map to documented products:

Make sure the public umbrella header is imported via Firebase.h wrapped in __has_include. Follow the existing examples for details.
Update Firebase.podspec.
Register library via registerInternalLibrary API like this Storage example.
When ready to release with Firebase, add to the Firebase manifest.
Add a quickstart.

Contact icore-eng@ at least a month in advance of desired release date to coordinate the initial launch plan.