firebase SDK

What this skill does

 ---
    name: "Firebase Swift & TypeScript SDK Best Practices"
    description: "Guidelines and best practices for integrating and using the Google Firebase SDK in Swift (for Apple platforms) and TypeScript (for web/Node), covering setup, architecture, data handling, security, and usage across supported services and platforms."
    version: "1.0"
    dependencies:
      - "Firebase Apple SDK (Swift) – installed via Swift Package Manager (iOS 15+/macOS 10.15+)"
      - "Firebase Web SDK (TypeScript) – v9+ installed via npm (with module bundler)"
    ---
    # Instructions

    **Overview:** This guide outlines best practices for using Firebase on Apple platforms with Swift and on web/Node platforms with TypeScript. It covers how to set up the SDKs, organize code, handle data efficiently, and ensure security across all supported Firebase services and platforms.

    ## Setup and Initialization  
    - **Use official SDK integration methods:** Integrate Firebase using the recommended tools for each platform. On iOS (and other Apple platforms), use **Swift Package Manager** (or CocoaPods) to add the Firebase Apple SDK to your Xcode project. On web/Node, install the **Firebase JS SDK** via **npm** (e.g. `npm install firebase`) to use the modular API. Using these official methods ensures you get the correct libraries and easier updates.  
    - **Initialize Firebase only once:** Properly initialize Firebase early in your app’s lifecycle. In a Swift app, call `FirebaseApp.configure()` in your application’s startup (e.g. in `AppDelegate.application(_:didFinishLaunchingWithOptions:)` or the SwiftUI App struct initializer) to initialize the default Firebase app instance. In a TypeScript web app, call `initializeApp(firebaseConfig)` with your configuration object exactly once (typically at the entry point of your application). Avoid initializing multiple times or in library code – reuse the initialized app instance by passing it to Firebase services (e.g. `getFirestore(app)`, `getAuth(app)`) rather than calling a new initialize each time. This prevents duplicate app instances and errors.  
    - **Target supported platforms:** Ensure your development environment meets Firebase’s platform requirements. For Apple apps, use supported OS versions (e.g. iOS 15+ for recent Firebase SDKs, with official support for iOS, macOS, Mac Catalyst, and beta support for tvOS; watchOS has community support only). For web/TypeScript, modern browsers are supported, and Node.js can be used for server-side or Cloud Functions. Understanding supported platforms will help avoid using features not available on a given system (for example, Crashlytics is available on mobile but not on web, and certain Apple-specific features like Push Notifications require iOS devices).  
    - **Keep config files and keys safe:** Add the Firebase config files to your app correctly. In iOS/Swift, include the `GoogleService-Info.plist` file in the Xcode project (this contains your app’s Firebase project IDs and API keys). In web/TypeScript, use the Firebase project config object (apiKey, authDomain, etc.) to initialize – do not expose any truly sensitive credentials in client code. Firebase API keys are not secret, but restrict their usage to your app’s domains and bundle IDs in the Firebase console. Treat service account keys (used on servers) as sensitive and never embed those in client apps.  
    - **Separate environments and projects:** A best practice is to use separate Firebase projects for different app environments (development, staging, production). For example, have your app configured to use a “dev” Firebase project when debugging, and a “prod” project for the App Store or live site. This isolation prevents test data or changes from affecting production. In your Swift app, you can include multiple GoogleService-Info.plist files (one per environment) and select the appropriate one at build time (using Xcode schemes or build configurations). In TypeScript/web, use environment variables or config files to switch the Firebase config object based on environment. Keeping environments separate also means you can tailor security rules and database content appropriately for testing vs. production.

    ## Code Organization and Architecture  
    - **Separate Firebase logic from UI:** Organize your code so that Firebase calls (database reads/writes, auth requests, etc.) are not deeply intertwined with view/UI code. In Swift, consider using an architecture pattern like **MVVM (Model-View-ViewModel)** or similar. For example, create service classes or view models that handle Firebase interactions (such as fetching data from Firestore or updating user authentication) and then provide that data to your `UIViewController` or SwiftUI `View`. This separation makes your code more maintainable and testable. In a SwiftUI app, you might use an `ObservableObject` ViewModel that uses Firebase APIs and publishes model updates to the views. In TypeScript (e.g. a React or Node app), similarly abstract Firebase calls into utility modules or context providers. For instance, you can have a `firebaseService.ts` that exports functions for common operations (like `fetchPosts()` or `subscribeToOrders()`) instead of peppering `firebase.firestore()` calls throughout UI components. This improves readability and allows easier changes (or even swapping out the backend) down the line.  
    - **Use the Firebase modular SDK (web):** When using Firebase with TypeScript on the web, prefer the **v9+ modular API**. Instead of importing the entire Firebase namespace, import only the functions you need (e.g. `import { getAuth, signInWithEmailAndPassword } from "firebase/auth";`). The modular SDK is tree-shakeable, meaning your bundler can remove unused code and reduce your app’s bundle size. This leads to better performance for users. Avoid using older namespaced imports like `firebase.auth()` or `firebase.database()` in new projects, as they pull in the whole SDK.  
    - **Avoid tight coupling and singletons where possible:** While using Firebase, you often will use singletons (like the default `Auth.auth()` or Firestore instance). This is fine, but for complex apps consider wrapping these in your own classes or protocols. For example, define an interface (protocol in Swift or TypeScript interface) for your data layer (with methods like `fetchUserProfile(userId)`), and have an implementation that uses Firebase. This way, the rest of your code relies on an abstraction, making it easier to mock for unit tests or to replace Firebase if needed. Don’t scatter raw queries or `.observe()` calls in many view controllers or components; instead funnel them through a centralized layer. This approach keeps your app architecture clean and your Firebase usage consistent.  
    - **Leverage asynchronous patterns:** Firebase operations are inherently asynchronous (network calls). Embrace the async patterns of your language to keep code responsive. In Swift, use completion closures, Combine publishers, or async/await (if using Swift concurrency with Firebase API that supports it) to handle results without blocking the main thread. For example, use `Firestore.asyncAwait` APIs or wrap callback-based calls in `Task { ... }` if appropriate. In TypeScript, take advantage of **Promises** and **async/await** for readability. For instance, instead of nested `.then()` callbacks, write `const doc = await getDoc(docRef)` inside an async function, with proper try/catch for error handling. This makes the code cleaner and less error-prone, while ensuring UI updates happen on the main thread (in Swift) or main event loop (in JS) after data is fetched.

    ## Data Handling and Performance  
    - **Fetch data efficiently:** Design your data requests to minimize bandwidth and improve speed. Retrieve only the data you need from Firebase. For Firestore or Realtime Database, use queries with filters and limits rather than pulling entire collections when possible. For e