FlutterFire Roadmap

[Salakar]

Hey all 👋

Today I’m excited to announce the upcoming changes and roadmap for the FlutterFire plugins.

The overall mission of FlutterFire is to provide a set of high quality set of plugins for developers to allow them to build Flutter apps using Firebase. As Flutter grows, we want to ensure that the FlutterFire plugins grow with it, including Web support and enabling the possibility to support other platforms such as Desktop.

We’ve recently started a triage of repository issues to understand the current state of the repository, and get a feel for the biggest pain points and challenges developers are facing. The triage has enabled us to focus our efforts on bringing the library to production ready quality along with overall quality of life updates to FlutterFire.

Our top priorities are to introduce a dedicated documentation website, review each plugin in importance order (based on usage & current state) and tackle critical issues (such as slow Cloud Firestore build times).

As we review each plugin by group, we’ll be focusing efforts on the following areas:

• Testing: covering the public API (as much as possible) with dedicated unit and integration tests is incredibly important to us, so we can be confident in adding new features, squashing bugs and opening up the repository to more external contributors.

• Supporting Federated Plugins: we want to ensure that all plugins can be integrated with the platforms Flutter supports. Right now only 4 plugins are Federated (Core, Cloud Firestore, Analytics & Cloud Functions). As we move forwards, each plugin will be converted into a Federated setup to allow other platforms to integrate with FlutterFire.

• Documentation: although the reference API is a great place to understand the plugins, the goal of FlutterFire is to allow developers of all backgrounds and experience to get up and running with as little friction as possible. We’ll be providing documentation on how to setup Firebase with your Flutter apps, get started with using each plugin within your app and guides on addressing how the plugins can integrate with the wider Flutter & Firebase ecosystems, helping to reduce the barrier to entry when working with the plugins.

As explained, we’ll be tackling the plugins in importance order. As it stands, the ordering is as follows:

1. 🟢 Core
   Status: complete, merged & stable release shipped.
2. 🟢 Cloud Firestore
   Status: complete, merged & stable release shipped.
3. 🟢 Authentication
   Status: complete, merged & stable release shipped.
4. 🟢 Crashlytics
   Status: complete, merged & stable release shipped.
5. 🟢 Cloud Storage
   Status: complete, merged & stable release shipped.
6. 🟢 Cloud Functions
   Status: complete, merged & stable release shipped.
7. 🟢 Cloud Messaging (FCM)
   Status: complete, merged & stable release shipped.

We’ve yet to decide on the order of the remaining plugins, we’ll update you as we progress. Also, the Google team are heavily engaged with the AdMob plugin and will continue to maintain that as a top priority in parallel with this work.

We want to ensure that all plugins are interoperable as we work through them, allowing developers to see the benefits from the on-going work as soon as they are available. Therefore we’ll be doing some immediate changes across the board which will allow the newly updated plugins to be “backwards compatible” with plugins that have not yet been updated as part of this process.

To achieve this, we’ll be updating all FlutterFire plugins with the following top level changes:

• Dependency on Core: The most significant change is to configure every plugin to have a hard dependency on firebase_core. This will both help reduce installation steps, improve API consistency and follow conventions of the Firebase SDKs.

• Fixed Firebase SDK versioning: all plugins will be set to a fixed version of the underlying Firebase SDK (however will be overridable if desired), allowing us to be confident developers will be using the same SDK versions we’ve tested against.

• Consistent public API: developers coming from other platforms should be familiar with the public API FlutterFire offers, so we’ll work on bringing the API in-line with the Firebase APIs (where possible). See the Dart design style guide to learn more.

• Reducing installation steps: installing and getting started with FlutterFire should be as painless as possible. We’re working towards reducing the amount of manual setup steps required to integrate the plugins.

• Adding missing features: the issue triage and API review has highlighted a number of missing features which will be implemented as part of the plugin updates. In general if the underlying platform Firebase SDK supports a feature cross-platform then so should FlutterFire.

These changes will introduce a number of breaking changes, though we’ll do our best to keep these to a minimum and ensure that the documentation provides full change logs & migration guides to help make the upgrade as painless as possible.

We’ll be updating this issue as we progress through the upgrade to the plugins so please check back regularly.

---

The following GitHub users will primarily be focusing on this work going forwards:

• @dackers86
• @Ehesp
• @helenaford
• @kirstywilliams
• @russellwheatley
• @Salakar

If you have any urgent issues / pull requests that you feel you would like us to look at sooner - feel free to tag us in using the @FirebaseExtended/invertase GitHub team and we'll try our best to look at them as soon as possible.

---

Flutter blog post announcement: Flutter Package Ecosystem Update

New Flutter Favorites, Apple Sign In, and bringing prerelease Flutter plugins into production

---

If you're on Twitter, we'll be tweeting regular updates on the @FlutterFireDev account - feel free to follow along there also.

[slightfoot]

I have been working a lot recently with Flutter Web with Flutter Fire plugins and have found a few issues that I would like to raise concerns over. Just to impart the view-point/knowledge. I'll let you do what you will with the info.

1. Federated Plugin Interfaces
   I had a bug the other day because the confirmPasswordReset function of firebase_auth was not implemented on the web package. I found it weird that it even happened. Turns out that the base class for the Platform Interface implements all the functions and marks them to throw Unimplemented. I think this is unacceptable. It's the platform specific implementations job to mark a function as unimplemented and not the base class, or as functions are added to the interface we don't know which platform implementations have that feature. This is what happened with this simple use-case. I feel this design decision should be looked in to further.

2. Platform Interface Standards
   It should be clear/tested that the expectation of functionality of an platform interface is maintained. For example, I was working with cloud_firestore and in this situation the previous un-federated plugin allowed you to compare DocumentReference's. This was then federated and it broke the comparison operator. PR Here.
   Another example is google_sign_in (I know not in this repo). It's signIn function is documented and suppose to return null when the user cancels/closes the sign in popup. Currently with the web version it throws.

3. Poor Platform Interface Error Handling
   I worked very hard a long time across to standardise the reported Errors from firebase_auth I made sure that each method was correctly documented. The federated plugin has destroyed this. The web implementation is practically impossible for a developer to deal with specific errors such as "user not found". I would love to discuss this point and help on it where I can. But to me it seems practical to come up with a base exception class all FlutterFire plugins use from core and then for each plugin to extend it with specifics for each. For sure the plugin error class should be listed in the comments on every interface method with a list of code field responses so that the developer can deal with exceptional conditions and display the correct UX.

I know this might be a critical view-point, but hope the points are discussed internally.
I am happy to help where I can to further discussion over these and other issues.

[Ehesp]

Hey @slightfoot thanks for your comments, they're super useful.

1. Federated Plugin Interfaces

This library was created before Flutter Web was available, so at the time there were a lot of code decisions made which may not have considered the impact a Federated plugin setup would have when it was introduced. As it stands, FlutterFire web & native implementations are mis-aligned with each other feature wise. This is something we're working towards (starting with getting tests in place to catch these issues).

implements all the functions and marks them to throw Unimplemented. I think this is unacceptable.

The Platform Interfaces are like this by design to ensure that any platform specific code which wraps onto the plugin ensures that something happens if the underlying platform code (the delegates) don't provide functionality for the "call". If this happens, it should be a signal to flag an issue that something is indeed missing - this could also be a 3rd party platform implementation which is using the Platform Interface.

2. Platform Interface Standards

This boils down to the problem mentioned in the first section. Right now tests are lacking to help identify these sorts of problems but that's something we're working towards (as part of the "1.0" release cycle).

The plugins without a current web implementation will also be developed at some point in the future to work with the platform interfaces we'll create for each.

3. Poor Platform Interface Error Handling

We plan to provide a public FirebaseException class which all Firebase related errors should filter through for each platform. Right now, the firebase_core_web plugin wraps the firebase-dart library, which wraps the Firebase JS SDK. If an error is thrown on the web, the error message returned is JavaScript SDK related (not very handy for FlutterFire users). Luckily, Firebase errors return a code (e.g. core/no-app). If such an error is trapped on the JS side, we can throw a specific FirebaseException with the same message across all platforms. Once the Core rework PR lands, you can take a look in there - it's not ideal however it does help solve this problem.

[IchordeDionysos]

Thanks for bringing the development of Firebase for Flutter forward!

However, I am missing on the roadmap packages like Remote Config and Analytics!

Both are more popular than some other packages on the roadmap, however I do understand that the first 6 are for paid products.

Also, a proper Crashreporting for Flutter would be great, not tied to a Native implementation via Platform channels, but rather a first class Dart integration of Crashlytics, this would then work on all platforms out of the box!

[Boehrsi]

@Salakar and the team, thanks for taking over this important part of the Flutter ecosystem! I just wanted to ping you about an IMHO important issue and tried to link the mentioned GitHub team, but it seems the mentioned team is missing. A typo or something?

[workerbee22]

I think an argument can be made that this PR to implement the New Crashlytics SDK:

[firebase_crashlytics]Migrate to new Crashlytics SDK #2288

is perhaps even more urgent than some of the others. Because most/'all' flutter production apps need a crash and error reporting solution. Where as Cloud Storage or Cloud Functions ... perhaps not so much.

[mayurdhurpate]

Looking at FlutterFire Roadmap #2582, it looks like the FlutterFire plugins are going towards much more stable and consistent design. There's one point I would like to add.
As mentioned by @slightfoot, currently, it's very difficult to know what all kinds of exceptions might get thrown from a Firebase plugin on any given function (esp. Firestore (#1223) and Firebase Auth) and this leads to a poor UX feedback to the users. It's even difficult when writing tests or passing those errors as failures down the domain and UI layer. I tried finding a comprehensive doc of errors but could not get and concrete results.

I think that along with consolidating all the existing platform exceptions to a single place, if for the time being, we could get basic documentation with details of current implementation up and running[Related: #183] (esp. containing common ones such as Network/Timeout etc.), it could help take the pressure off as a workaround and can act as a base doc while working collaboratively on revamping the plugins. If there's already something in place on similar lines, please point to that too. Would love to contribute to this revamp process!

[IchordeDionysos]

For Auth, there is a well-documented list in the JS SDK reference [1]. I would appreciate if error documentation not just for Flutter, but across all Firebase products and platforms would be improved :)

[1] https://firebase.google.com/docs/reference/js/firebase.auth.Error

[Ehesp]

For Auth, there is a well-documented list in the JS SDK reference [1]. I would appreciate if error documentation not just for Flutter, but across all Firebase products and platforms would be improved :)

Yep something we're looking at. In cases where Firebase provides an actual error code we can handle. It's trickier when dealing with errors with no code since there's no real way to "check" the error and match it to a global one. In this case, we'll provide error messages which are as similar as possible.

[SaadArdati]

Any hope for a dart native firebase admin sdk?

[Ehesp]

@SwissCheese5 not on the roadmap right now, but maybe something longer term.

[Levi-Lesches]

I know it's not native, but here's something I used to keep my project mostly dart: firebase_admin_interop

[SaadArdati]

@Levi-Lesches That's web only unfortunately.
The only available package is firebase_admin which only provides firebase auth and firebase storage support, no Firestore.
firedart, on the other hand, is meant for dart native clients rather than admin

[Levi-Lesches]

That's web only unfortunately

It's not web, it's NodeJS, and doesn't run on clients, it runs on the server only.

The only available package is firebase_admin

It's a substitute for firebase_admin, but is being actively worked on and has many more features. My project uses it to do admin work on Firestore, Firebase Auth, and Firebase Messaging, so if you have any questions I'm happy to help.

[SaadArdati]

@Levi-Lesches So I can use it on a windows/Linux machine and it'll work? I legitimately thought it would crash because it depends on dart:html

[Levi-Lesches]

Yep! I have a Windows too. It takes some setting up, and you can't use dart:io (node_interop, node_io, and other packages by the same developer will come in handy as replacements for basic dart features), but once you get it running it works very well and supports most of Firebase's features.

[raveesh-me]

I would like to see "common semantic versioning".
Firebase products could follow one form of versioning, but it will be super time-saving if we don't have to mix and match between plugins to get a set working.

It has been a problem for us in the past. Just hope that this remains a priority.

[ingmferrer]

Android newbie developers like me are starting new projects in flutter with kotlin support, so take into account that the documentation (i.e FMC) should refer to both java and kotlin version.

Also, there're a lot of FMC issues out there (crashing on start).

Good luck!

[Ehesp]

@raveesh-me That won't be happening sorry, for a couple of reasons:

1. The plugins are already out-of-sync on versions, so we'd have to major jump some from 0 -> 6.
2. Version-locking can slow down release cycles and shipping quick fixes.

That being said, we're working on a "check" which prevents incompatible versions being installed.

@ingmferrer Yep any native changes will be in both Kotlin/Java + Swift/Objc on the docs. We're actually going to be reducing a good number of native steps anyway.

[sondresorbye]

When will storage be available for flutter web?

[ro0t]

Finally the slow builds will be looked at :)

[ReniDelonzek]

Since there is no sdk available for the desktop (windows, linux), wouldn't building a native dart be an evaluable option?

[orestesgaolin]

There has been some unofficial work on Firebase SDK in Dart. Firebase Auth and Firestore is already ported but it's done by single person https://github.com/fluttercommunity/firebase_dart_sdk/tree/develop

[Ehesp]

There's no plans yet, although it has been talked about. Building a new SDK is a whole different story than building on-top of existing ones.

[ctrysbita]

@Ehesp That means we have to build more than one SDK if we want to support other platforms like windows and linux. Maybe implement everything using Dart will be easier? Or use Dart to wrap a single cross-platform native library through FFI?

[Ehesp]

@ctrysbita yep but you'll be waiting for a long time. I wouldn't say it's not going to happen, but it's not on the roadmap.

[Salakar]

Hey everyone 👋 quick progress update;

• 🟢 firebase_core - our rework of this plugin (and general repository/CI cleanup) has just landed on master 🎉 we'll look at publishing some pre-releases next week. Changes can be seen on #2890.
• 🟡 firebase_firestore - our rework of this plugin is complete but is currently going through internal review. We're hoping to have it up on this repository soon. If you're curious; a preview of the upcoming changes can be seen here.
• 🔴 firebase_auth - our rework of this plugin is nearing completion, but will still need to go through an extensive review. Will post a further update next week.
• ⚪ firebase_storage - currently going through internal planning.
• ⚪ firebase_functions - currently going through internal planning.

[zmeggyesi]

@Ehesp where does Remote Config lie on this roadmap? What about the AdMob plugin?

[IchordeDionysos]

@zmeggyesi it's maintained by Google as explained in the first message:

We’ve yet to decide on the order of the remaining plugins, we’ll update you as we progress. Also, the Google team is heavily engaged with the AdMob plugin and will continue to maintain that as a top priority in parallel with this work.

And Remote Config is not in the list, so it will be done sometime after "Cloud Messaging (FCM)". They don't know which package they use next.

[zmeggyesi]

@IchordeDionysos I'm aware of that being the initial plan, I was more looking for an update on those two packages, and whether priorities have changed (mostly in response to feedback here highlighting the need for other packages to be tackled).

[Salakar]

Hey all, again 🙈 another week, another update:

• 🚢 firebase_core - prereleases packages are being published shortly via #2907.
• 🟢 firebase_firestore - our rework of this plugin has just landed on master 🎉 we'll look at publishing some pre-releases soon. Changes can be seen on #2913.

[workerbee22]

@Salakar What is the estimated time between 'prereleases shipped' and the released version appearing on pub.dev ? I noticed core merging is blocked due to some checks failing.

[ryaanwells]

Just want to note that the visibility of the roadmap is awesome 🎉 Really keen to see these changes land, thanks for your hard work here!

[larssn]

So no release today after all?

[Salakar]

So no release today after all?

https://github.com/FirebaseExtended/flutterfire/releases

[IchordeDionysos]

@Salakar Just tried to install cloud_firestore-v0.14.0-dev.1 while also trying to install firebase_storage. Did not work...
Will other Firebase libraries in their current form be compatible with the new Firebase core?

Would it require that each package will get a v1 rework?
Or can I use the Firestore v1 library, and the firebaase_ml_vision or firebase_in_app_messaging pre-v1 version together?

[Ehesp]

@IchordeDionysos yep we're working on that. The plan is to bump the versions of all other modules (without reworking them), but get them to work with the updates. You can see Functions is WIP.

[Salakar]

Hey everyone, quick update;

Pre-releases of the reworked Core & Firestore FlutterFire plugins are now available on Pub (as some of you have already been quick to notice 😅). Early adopters & feedback would be hugely appreciated. [View Releases]

Note: as discussed above by @IchordeDionysos & @Ehesp, there may be some incompatibilities with the currently published versions of Auth, Functions & Storage when using the new Firebase Core - we're in the process of publishing pre-releases for these too (only minor internals changes for compatibility, not the rework versions) so please bear with us.

---

EDIT: functions prereleases have now been published from #2951

[oranmana]

[IchordeDionysos]

@oranmana I've asked that earlier :)
#2582 (comment)
#2582 (comment)
#2582 (comment)

They are working on pre-release versions for other packages like firebase_auth which supports the new core.

[alejandroaap]

I have updated the cloud firestore version to the version ^0.14.0-dev.1 and firebase core to the version ^0.5.0-dev.2 and I have encountered problems executing this code that I have extracted from the documentation ->

// Initialize first
await FirebaseCore.instance.initializeApp ();

// Set the host as soon as possible
await FirebaseFirestore.instance
.settings (Settings (host: "localhost: 8080", sslEnabled: false));

When initializing FirebaseCore it does not exist, however, Firebase.initializeApp () does exist.

Also, when making the settings, the error it gives is the following: 'The expression doesn't evaluate to a function, so it can't be invoked.' The example should look like this FirebaseFirestore.instance.settings = Settings (host: 'localhost: 8080', sslEnabled: false, persistenceEnabled: false); Also await is not necessary since it is not a Future.

[greghesp]

@alejandroaap - Thanks for highlighting the error in the docs, we'll update it soon. The correct code should be:

// Initialize first
await Firebase.initializeApp();

// Set the host as soon as possible
FirebaseFirestore.instance.settings = Settings(host: "10.0.2.2", sslEnabled: false);

With that in mind, please be aware that at the time of writing, cloud_firestore >=0.14.0-dev.1 depends on firebase_core ^0.5.0-dev.1, and firebase_auth 0.16.1 depends on firebase_core ^0.4.4 as per this issue

[alejandroaap]

Hello @greghesp , today I have found new versions available. I am specifically using

firebase_core: ^ 0.5.0-dev.2
firebase_database: ^ 4.0.0-dev.1
cloud_firestore: ^ 0.14.0-dev.1
firebase_storage: ^ 4.0.0-dev.1
firebase_auth: ^ 0.17.0-dev.1

With these versions, the problem you are talking about no longer exists or at least I have not had it.

On the other hand, I have seen how FirebaseDatabase cannot be initialized with the firebase database emulator url. I have tried to initialize an instance with the url of the database emulator but nothing more than trying to get data, from that instance, the application closes and no error is displayed in the log. I understand that this error is still normal because the firebase database library has not been checked. Is that so?

[Ehesp]

@alejandroaap We've not touched Database yet, so nothing has changed other than upgrading internal dependencies. I'd suggest raising a new issue for this, so we don't clutter this issue. Thanks.

[Salakar]

Hey everyone; another quick update;

The following pre-release versions are now live - these have all been updated to work with new Core:

• Core (rework version)
• Firestore (rework version)
• Auth (pre-rework version)
• Analytics (pre-rework version)
• Database (pre-rework version)
• Functions (pre-rework version)
• Storage (pre-rework version)
• Performance Monitoring (pre-rework version)

Lots of work has gone into each of these plugins to improve testing & CI stability, these are now all using the latest Firebase SDKs and are also using the shared Firebase SDK versioning setup meaning all these plugins now depend on the same version of the Firebase SDKs - no longer mixing & matching versions.

If you can; please give these a try - overview pages for each of these are now showing on the docs site including a quick installation guide which shows what the latest pre-release version for each is, e.g. Analytics: https://firebase.flutter.dev/docs/analytics/overview.

---

Remote Config, Links, In App Messaging and Messaging pre-releases that use the new Core will be available soon.

[workerbee22]

@Salakar Great work ... but you neglected to mention Crashlytics ?

[Salakar]

@Salakar Great work ... but you neglected to mention Crashlytics ?

For Crashlytics see #2288 (comment)

[Salakar]

Remote Config with new firebase_core (pre-rework) pre-release is up, also added in MacOS support whilst I was at it. 🙃

https://firebase.flutter.dev/docs/remote-config/overview

[Bilonik]

Amazing work!!!, just waiting for Messaging to Upgrade 😁

[Salakar]

@Bilonik Amazing work!!!, just waiting for Messaging to Upgrade 😁

Just for you 😅 a Messaging pre-release has just been published that uses new Core 🙃

https://firebase.flutter.dev/docs/messaging/overview

[alejandroaap]

@Salakar As part of that cloud messaging rewrite, do you plan to implement the option to handle notifications with data once the application ends?

[Ehesp]

@alejandroaap Could you explain a bit more about your use-case? We still need to really dig into Messaging but it'll be getting a full overhaul.

[alejandroaap]

@Ehesp In the Readme file of cloud_messaging plugin, which can be found at https://github.com/FirebaseExtended/flutterfire/tree/master/packages/firebase_messaging#receiving-messages , it is referenced that when app is terminated the data message on Android device is lost because the plugin not supported. In the case of ios the message is stored by FCM and delivered to app via onMessage when the app is brought back to foreground.

My question is, Are you going to implement the option to handle notifications with data when the application is finished?

[MTRNord]

As a use case (cc @Ehesp ): We (I myself and other people) are implementing a chat application that is supposed to do notifications like telegram, Element (previously Riot), or Whatsapp. This obviously means to always get them. We cannot use the normal messages from firebase as the messenger is fully e2e encrypted and therefore we don't actually know the content of the notification before we actually use that data message and decrypt it on the specific phone. The notification is being sent by the server which for obvious reasons does not have any of the keys to decrypt.

TL;DR: Chat apps and especially those fully encrypted cannot use normal messages as they either can't provide the content when doing the notification or don't want to share the information because of privacy issues. (In the end, even when google is not shady it still is a third party service. This is not meant as an offense in any way.)

[walidbagh]

Any planned improvement for admob plugin ?

[Ehesp]

@MTRNord Thanks, however I still don't fully follow. Are you still using FCM to send the data payload to the devices? We cannot use the normal messages from firebase - what are you using?

@walidbagh Yes, however that is currently being worked on internally since it requires changes to Flutter itself (I believe).

[MTRNord]

@Ehesp exactly we send a pure data payload using fcm, recieve it in the App, convert the message id we have sent in the data content to the actual decrypted content and Display it using flutter_local_notifications.

[Izzur]

Current firebase auth provider only support email, facebook, github, google, oauth, phone, twitter
Is other provider like custom token, apple, yahoo, microsoft will be implemented on this roadmap?

[alejandroaap]

@MTRNord How do you get data object from notification with firebase_messaging plugin? In the documentation it says the following 'not supported by plugin, message is lost' Does the onBackgroundMessage method work even if the application is terminated?

[MTRNord]

@alejandroaap no it does not work when terminated. Thats where the problem is at for us. :/

We get data with this: final Map<dynamic, dynamic> data = message['data'] ?? message;

And from that we get our room id and event id using this:

data['unread'] ??= jsonDecode(data['counts'])['unread'];
final String roomId = data['room_id'];
final String eventId = data['event_id'];

[alejandroaap]

@MTRNord Sorry, I misunderstood you. So confirmed, we have the same problem, surely we are not the only ones. Thanks for your answer

[Ehesp]

@MTRNord @alejandroaap Assuming the issue here is on iOS? We still need to properly investigate, will keep you updated. cc @kroikie

[LasseRosenow]

@MTRNord @alejandroaap Assuming the issue here is on iOS? We still need to properly investigate, will keep you updated. cc @kroikie

Yes android works even when the app is terminated as far as I know.

[alejandroaap]

@MTRNord @alejandroaap Assuming the issue here is on iOS? We still need to properly investigate, will keep you updated. cc @kroikie

Yes android works even when the app is terminated as far as I know.

@lazylazyllama @Ehesp I have tried it on android and iOS and it does not work on any of them. How have you managed to make it work on android? In the event that it works on Android, they should update the Readme file since it is specified that in Android the messages are lost.

[ryaanwells]

Hi folks. As a suggestion to keep this issue conversation contained to Roadmap updates/notifications, could we move other conversations into a specific issue for each request (or into a chat room etc)? Some of the above are feature requests that could better be discussed in isolation so they don't get lost here.

I'm following this issue to stay up to date on the roadmap items listed, as I imagine most watchers will be, and this is getting quite noisy :)

[Salakar]

Hi folks. As a suggestion to keep this issue conversation contained to Roadmap updates/notifications, could we move other conversations into a specific issue for each request (or into a chat room etc)? Some of the above are feature requests that could better be discussed in isolation so they don't get lost here.

I'm following this issue to stay up to date on the roadmap items listed, as I imagine most watchers will be, and this is getting quite noisy :)

Agreed, locking this issue until the next update.

[workerbee22]

Has the new documentation site changed or is down? Can't seem to be reachable atm or is it just me ? For example: https://firebase.flutter.dev/docs/remote-config/overview

[Salakar]

Look like the DNS switch over to Firebase Hosting has had issues, in the meantime you can access the docs here: https://flutter-firebase-docs.web.app/docs/overview

[Salakar]

Hey all, progress update 📢

• 📚 We've added a migration guide to help with updating existing projects (and we'll keep adding to it as the roadmap progresses), please check it out:
  • [Migration Guide]
• 🟢 Re-work of Authentication has landed on master and a pre-release is now available on Pub. For information on changes please see the auth changes listed on the migration guide mentioned above.
  • New Documentation:
    • [Overview]
    • [Usage]
    • [Social Auth]
    • [Phone Auth]
    • [Error Handling]

---

⚠️ Note: There's an ongoing DNS issue with the new website so firebase.flutter.dev may not load for you, in the meantime, you can temporarily access the docs here: https://flutter-firebase-docs.web.app/docs/overview

[zmeggyesi]

Super excited for the Crashlytics and the Storage upgrades! Any timeline on those two, how close are they to landing on Pub?

Also, will we see AdMob being upgraded to work with the new Core?

[HofmannZ]

@zmeggyesi The Crashlytics and Storage upgrades are in progress internally. Been following those actively. A rough timeline would be great indeed.

[Ehesp]

A rough timeline would be great indeed.

We're hoping in the next couple of weeks there will be a release. Both have been broken out into federated setups so a lot has changed.

[eturk1]

why are we still needing to manually add to settings.gradle after adding Firebase plugins?
as in #2599

[talent-apps]

Please make sure the new crashlytics plugin works properly with obfuscated dart code.
As of now, no stack traces are seen on crash reports making the plugin useless and developers practically blind for crashes in production.
See: #2644

[tillchen]

@Salakar Thank you for making the documentation! Sorry if this is not the correct to place to ask.

But one question:

According to https://flutter-firebase-docs.web.app/docs/auth/social/#facebook, it recommends: flutter_facebook_auth: "^0.2.3" instead of flutter_facebook_login: ^3.0.0. Is it because of the deprecation of UIWebView: https://medium.com/@karlwhiteprivate/flutter-facebook-sign-in-with-firebase-in-2020-66556a8c3586 ?

Thanks!

[MaikuB]

Does tagging the team work? I tried to do so in #114 (comment) but can see that the tag shows up in plain text

[helenaford]

@tillchen good question! Yes, that's why flutter_facebook_auth is used in the docs ☺️

[Salakar]

Hey all, just in case you missed today's official Flutter blog post on FlutterFire: https://medium.com/flutter/updates-on-flutter-and-firebase-8076f70bc90e

TLDR; Core, Auth & Firestore have graduated to stable releases. See blog post for more detail.

Thanks to everyone that helped test the prereleases and submitted bug reports. 💙

[Ehesp]

Hey all,

The Crashlytics rework has been shipped as a dev release 🥳 This upgrade introduces loads of new features, fixes and SDK updates.

Please help test if possible!

• 📖. Documentation
• ⏫. Migration guide

[Salakar]

Hey everyone 👋 it's been a while since the last update but we have lots to update you on.

Since the the last update:

Reworks completed and shipped to stable channel:

1. 🟢 Crashlytics - [Changelog]
2. 🟢 Cloud Storage - [Changelog]
3. 🟢 Cloud Functions - [Changelog]

Reworks completed and shipped to dev channel:

1. 🟡 Messaging - [Changelog]
   • Notable changes:
     • Removed all manual native code changes that were originally required for integration - FlutterFire messaging now works out of the box once configured.
     • Support for MacOS. 💻
     • iOS background handler support 🥳
     • Android background handler debugging and logging support.
     • Reworked API for message handling (Streams + explicit handlers).
     • Fully typed Message & Notification classes (vs raw Maps).
     • New Apple notification permissions & support.
     • Lots of new documentation.
   • We'd love for as many people as possible to test out this rework version of the Firebase Messaging plugin. For feedback and discussions on the update please see this discussion thread: #4023

---

What's next?

Our focus has now shifted slightly, and we're looping back to the first 7 plugins to focus on web and ensure it is a) supported on these plugins and b) is up to the same standard and feature set as the native reworks we've been doing.

We want these plugins to be the best they can be on Android, iOS, macOS & Web by the end of the year.

Web progress:

1. 🟢 Core Web
   Status: complete, pending additional testing & merging.
2. 🟢 Cloud Firestore Web
   Status: complete, pending additional testing & merging.
3. 🟢 Authentication Web
   Status: complete, pending additional testing & merging.
4. ❎ Crashlytics Web
   Status: not supported by Firebase Web SDK.
5. 🟡 Cloud Storage Web
   Status: complete, pending review & additional testing. (#3917)
6. ⚪ Cloud Functions Web
   Status: not started.
7. 🔴 Cloud Messaging (FCM) Web
   Status: in progress.

What about the other plugins?

They've not been forgotten, for now they are lower in priority and most likely won't be reworked until the new year. We'll do our best to keep critical bug fixes/blockers shipping still on these plugins in the meantime.

[Salakar]

Hey all, update time;

Web progress:

1. 🟢 Core Web
   Status: complete, shipped 🚢 .
2. 🟢 Cloud Firestore Web
   Status: complete, shipped 🚢 .
   • This added in the follow new feature changes;
     • FirebaseFirestore.enablePersistence now accepts PersistenceSettings
     • support for PersistenceSettings
     • support for FirebaseFirestore.clearPersistence
     • support for FirebaseFirestore.terminate
     • support for FirebaseFirestore.waitForPendingWrites
     • support for SetOptions.mergeFields
     • GetOptions support for querying against server/cache
     • support for Query.limitToLast
     • support for FirebaseFirestore.snapshotsInSync
3. 🟢 Authentication Web
   Status: complete, shipped 🚢 .
   • This added in the follow new feature changes;
     • support for EmailAuthProvider.credentialWithLink
     • support for FirebaseAuth.setSettings
     • support for User.tenantId
     • FirebaseAuthException now supports email & credential properties
     • ActionCodeInfo now supports previousEmail field
4. 🟢 Cloud Storage Web
   Status: complete, shipped 🚢 .
   • Cloud Storage did not support Web previously, so this is a new platform being supported.
5. 🟢 Cloud Functions Web
   Status: complete, shipped 🚢 .
6. 🟢 Cloud Messaging (FCM) Web
   Status: complete, shipped 🚢 .

---

What's next?

Null safety support for all the above packages. More on this soon.

[mehmetf]

@Salakar is there a specific issue filed for supporting null-safety?

[Ehesp]

@mehmetf #4182

[Ehesp]

Hi All,

For those interested, all plugins have now been migrated to Null Safety, you can find more information here: #4182 (reply in thread)

Note; this does not mean they've been reworked yet, that work will be carried out in due course.

[Salakar]

Hey all, please take a look at #6979 - the remaining plugins are now in progress along with something new 👀 - continuing this issue over there.