Headless installation & configuration along with Firebase SDK

[ciekawy]

Hello all,

I'd like to share my experience with this plugin suite and propose an improvement that could benefit developers who aim to automate their build processes. Specifically, I think headless installation and configuration of the Firebase SDK alongside the Capacitor Firebase plugin could make the installation process clearer and more accessible.I did start with a question here and was correctly suggested to create a discussion topic.

While trying to use the plugin, I encountered an issue that many developers might face: it's unclear to me which project I have to add the Firebase SDK to. I understand that this isn't a fault of the plugin itself, but I still think it's worth discussing how to make this process more clear. DevOps principles emphasize the importance of automation, repeatability, and consistency. In my experience, this plugins require manual intervention during the installation process, which can make automation more challenging.

To illustrate the potential benefits of headless installation, while building my mobile app, I only used Xcode to log in to my dev account, and sometimes to inspect low-level build issues. I didn't want to spend more time than necessary in Xcode, and I'm sure other developers often feel the same way.

As it turns out, Firebase SDK offers a CocoaPods approach to integrate with Xcode iOS projects. From a developer experience standpoint, this leads to the expectation that a single installation command could do everything, including installing dependencies, and leaving just the necessary configuration to be put in place.

As I actually only tried to use this plugin, and I ended up using another which I managed to install headlessly with a few scripting tweaks. I'm sure other developers would appreciate the option to install Capacitor Firebase in a similar fashion. I believe that incorporating headless installation and configuration into the Capacitor Firebase plugin would be a great step towards making it more accessible and easier to use for developers who want to automate their build processes. What do you think?

[robingenz]

Thank you for starting this discussion!

it's unclear to me which project I have to add the Firebase SDK to

I'm not sure I understand your issue correctly.
The documentation for adding the Firebase SDK is pretty accurate: https://github.com/capawesome-team/capacitor-firebase/blob/main/docs/firebase-setup.md
This documentation has just recently been expanded. However, I am open to further improvements.

In my experience, this plugins require manual intervention during the installation process, which can make automation more challenging.

That is correct. Installing the plugins is currently a manual process. This process could be partially automated with Trapeze, but creating such scripts is not a high priority so far, as Firebase is usually added to the project only once. But PRs are welcome!

As it turns out, Firebase SDK offers a CocoaPods approach to integrate with Xcode iOS projects. From a developer experience standpoint, this leads to the expectation that a single installation command could do everything, including installing dependencies, and leaving just the necessary configuration to be put in place.

This is how it is currently done. When running npx cap sync after installing the npm package, the CocoaPods are automatically installed by the plugin and you only have to do the configuration manually.

Edit: A few CocoaPods (e.g. CapacitorFirebaseAuthentication/Google) have to be added manually. The reason for this is that not all SDKs should be installed in the app, but only those that are needed. This reduces the size of the app and is important for the privacy of the user, as no third-party SDKs are active/installed that are not needed. This process is individual and therefore difficult to automate.

As I actually only tried to use this plugin, and I ended up using another which I managed to install headlessly with a few scripting tweaks.

Do you have a link to the project so I can see how they solved this?

[ciekawy]

I'm answering quickly on mobile (will share more later), we ended up using @capacitor-community/firebase-analytics with following extra steps:

• copy GoogleService-Info.plist to ios/App/App
• add xcode dependency
• update .pbxproj file using xcode package with script based on https://stackoverflow.com/a/63904718

// proper imports above
const project = xcode.project(path)

 project.parse(_error => {
   const targetKey = project.findTargetKey('App')
   const appGroupKey = project.findPBXGroupKey({path: 'App'})
   project.removeFile('GoogleService-Info.plist', appGroupKey)
   const f = project.addFile('GoogleService-Info.plist', appGroupKey, {target: targetKey})
   f.uuid = project.generateUuid()
   project.addToPbxBuildFileSection(f)
   project.addToPbxResourcesBuildPhase(f)
   fs.writeFileSync(path, project.writeSync())
 })

Firebase SDK pods seems to be added by capacitor plugin and with just those changes I am able to see analytics events from app built by our pipeline on cicd server.

Also as mentioned before, ios project is not in the repo but generated with ionic capacitor build ios

[ciekawy]

As for pods to be installed manually I don't think it is a big deal, the only cumbersome step is to update the Podfile (which again lives in the gitignored ios)- not sure if I know an automated way other than how npm plugins are doing (wrapping to npm plugin? Maybe universal plugin allowing to list pods outside?) this or with some patch file which may be unreliable

[ciekawy]

I'd imagine leveraging the xcode package to edit even more properties in ios project and possibly mapping all those setting to some json file.

[robingenz]

Firebase SDK pods seems to be added by capacitor plugin and with just those changes I am able to see analytics events from app built by our pipeline on cicd server.

That is correct. This works because @capacitor-community/firebase-analytics does not support installation without any IDFA collection capability. @capacitor-firebase/analytics supports this, but the developer has to decide during setup and therefore add the pod manually.

Also as mentioned before, ios project is not in the repo but generated with ionic capacitor build ios

Okay, now I understand what you mean. The ios and android folder should not be in the .gitignore. This is exactly one of the core differences between Capacitor and Cordova and should prevent exactly this kind of problems by configuring the native projects directly and treating them as standalone projects. This saves you from having to do all those scripts by configuring it once in XCode or Android Studio.

If you really don't want to do that, then from my point of view the best way is to use Trapeze.
As I said before, there are currently no scripts for this repository but it is planned. I have created a feature request for this: #339

[ciekawy]

Thank you for the clarification. It all makes much more sense now. And glad to see the feature request!

Indeed I am aware that capacitor suggest committing ios/android to the repo however I understand this as a build process not being capacitor concern rather than "you should not .gitignore" or "to avoid problems of configuring native project directly" - I see this exactly opposite as an opportunity to have real conscious declarative control over cryptic configuration hidden otherwise in unpredictable way in generated project. Fortunately the android/ios projects are correctly generated and most of the stuff can be expressed as configuration. In compare changing setting in Xcode sometimes (or often) randomly looking for working effect can be very hard to track in the git history.

I fully respect and understand the convenience of committing projects to the repo, just would be glad to see the opposite being also valid approach :)

Also thanks again for sharing Trapeze as it seems indeed to be important point between capacitor and Xcode/Android IDE

[ciekawy]

Also I didn't know about trapeze, it looks great and probably suits even better to fully automate and fill the gaps including configuration stuff. Still would be great to have all this bundled in one place eg as a config template if it helps keeping generated project off the repo.