fix: firebase auth issues on ios

[jfmcquade]

PR Checklist

• PR title descriptive (can be used in release notes)

Description

Fixes an issue where the Auth service with Firebase as the provider would not initialise correctly on ios. This manifested as the issues logged in this mattermost thread.

Testing

@esmeetewinkel to confirm login flows are working:

• iOS appetize
• Google Play Internal App Sharing link (building locally and uploading to appetize is not currently working for me)

Dev notes

These issues proved difficult to debug, in part because initially I could only replicate them in appetize and not via my local emulator. This is explained by the fact that the issue is related specifically to serving the app from a capacitor://localhost domain, and I was testing locally by serving from my own IP address via yarn ng serve --configuration=external. See error log below.

Cross-origin redirection to http://developers.google.com/ denied by Cross-Origin Resource Sharing policy: Origin capacitor://localhost is not allowed by Access-Control-Allow-Origin. Status code: 301

Also, as the login functionality was still working via the dedicated google sign in button component, it wasn't immediately obvious that the auth service wasn't successfully initialising. The issue was with the FirebaseAuthentication.getCurrentUser() method specifically, run as part of the service init, which wasn't resolving and so blocked the full init whilst signInWithGoogle() could still be called successfully. The issue seems to be in how Firebase Auth stores its persisting data. This PR configures it to use indexedDB when on native platforms, in accordance with this answer and these docs. Using this configuration on web does not seem to work, so the platform check is required.

Git Issues

Closes #

Screenshots/Videos

[github-actions]

Visit the preview URL for this PR (updated for commit 1dbc478):

https://plh-teens-app1--pr2835-fix-ios-auth-8zasq53u.web.app

_{(expires Thu, 20 Mar 2025 15:32:00 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: e4c0bab6b08dd290fbf002fd6e07987fa4b5fce1}

[esmeetewinkel]

Functional test passed on iOS Appetize, Android native device and web preview

For future reference, I pasted the two screen videos of the issues this addresses in the mattermost chat referenced in the issue (the two screen videos that sit in the chat so far were addressed by authoring changes, I believe)

[chrismclarke]

Super interesting issue, thanks for the deep-dive on it @jfmcquade

Looking at the links you've shared and a quick google leads me to agree with your assessment - the getAuth() method assumes it is in a browser environment uses methods incompatible with capacitor.

I don't actually think it's an issue with indexeddb vs localstorage, but more how getAuth includes the browserPopupRedirectResolver which will not work when called. Setting the indexedDB persistence also enforces the cordovaPopupRedirectResolver instead
firebase/firebase-js-sdk#5019
https://firebase.google.com/docs/reference/js/auth.dependencies.md

There is part of me wondering whether all of this has been fixed in more recent updates for firebase and/or capacitor-firebase, as essentially the automatic behaviour used to check for URLs starting ionic:// which broke when capacitor updated to capacitor:// URLs way back in Capacitor 3 (discussed a bit in this thread

https://github.com/firebase/firebase-js-sdk/issues/5019

However I still think the fix you have provided makes a lot of sense and also reflects the guidance in the current capacitor-firebase docs

https://github.com/capawesome-team/capacitor-firebase/blob/main/packages/authentication/docs/firebase-js-sdk.md

I'm assuming post-merge any existing android users will be forced to log back in (could be worth checking), although I don't think that should have any real impact except perhaps if being prompted to restore profile which would depend a bit on deployment. It might still be good to quickly test following merge though @esmeetewinkel @jfmcquade