Request for Firestore support is #4559

+1 here. I opened #269 a few years back with this intention. This ticket is specifically for the real-time database

Please note that this is likely not something that we will officially support in the Realtime Database SDK. We do welcome community contributions though and can release this as an "unofficial" feature (similar to how we rolled out MacOS support).

Please note that this is likely not something that we will officially support in the Realtime Database SDK. We do welcome community contributions though and can release this as an "unofficial" feature (similar to how we rolled out MacOS support).

Thanks for letting us know. Could you please clarify the reason? Are you going to stop supporting Realtime Database at all and we should migrate to Firestore ASAP or it's something else?

@n3at18 To clarify, RTDB is the same as the rest of Firebase. Only iOS is officially supported. All other Apple platforms are community supported.

And to expand a bit further... even though it's not "official", investigations and work are being done to support watchOS as the requests roll in. We prioritize the requests against other features and issues and make decisions based on that (things like thumbs up reactions on issues like this are a strong indicator for us that a feature is highly requested).

Work is definitely being done to support multiple Apple platforms (the vast majority of products do work on tvOS, macOS, and Catalyst already) but we can't give word on if/when individual platforms would become "officially" supported.

We love the RTDB as much as our customers and will continue to support it on all currently supported platforms.

One camp is saying it's not a great idea to try and communicate with Firebase directly from watchOS and it's better to prepare data in the iPhone app and pass it on to the watch using updateApplicationContext i.e. WatchConnectivity.

However the other camp is saying the use of WatchConnectivity places a lot of restrictions on the watch app (it can only get data from the phone when the phone app is running) so we should use the Firebase REST API directly from your watch app. If you choose to use the REST API, you don't need the watch app to communicate with the iPhone counterpart, the watch app can directly get the Firebase data using network requests. However, in this scenario, the network usage will be bigger.

Totally agree with this statement. Since Apple is likely to try and sell the watch beyond the iPhone users. Having independence makes sense. Please support WatchOS officially.

I have a proof of concept working (read: definitely not release-ready, or tested in any way outside of the very straightforward case) on a branch: https://github.com/firebase/firebase-ios-sdk/tree/rw-database-watchos. I'm hoping before the end of the year to flesh it out further, test it, and add it experimentally to the CocoaPod and Swift Package.

If websockets through NSURLConnection works for the watch could it perhaps replace the third party web socket implementation for all targets in the future?

If websockets through NSURLConnection works for the watch could it perhaps replace the third party web socket implementation for all targets in the future?

Yes, that's the plan! Unfortunately the minimum iOS version for the NSURLSession APIs is iOS 13.0, so up until we drop support for 10, 11, and 12 we'll need to keep the old third party web socket implementation for those OSes. Good news is that the new implementation would also unblock using Database in App Clips.

Later than I hoped but I have a PR open (#7656) for adding support to the RTDB SDK. Note: this was pretty lightly tested from a lifecycle standpoint in a very simple app and if you do plan on shipping this in your product, please do test it and file issues if you run into anything! I'll close this issue once the PR is merged.

This has landed and will be included in the next release. Please give it a shot and file issues as you see them, and let us know on this thread if it works for you!

Great news, thank you Ryan!