Sorry @wgodin I'm not in the habit of giving timelines for open source work, historically it doesn't work out when I do. All I can say is that it is a high priority for me, and the work is already partially complete.

Totally understandable ; glad it is high priority. Let me know if you need a tester or if I can help anyhow.

You can see my branch here but the iOS chunk is completely broken for unknown reasons (it's some sort of fundamental issue with how xcodebuild is seeing project paths etc) so I would not spend any time on it, only posting since you asked. Haven't had time to come back around to it last couple weeks but it's literally my next react-native-firebase priority so it won't be too much longer https://github.com/invertase/react-native-firebase/tree/%40mikehardy/appcheck

Please verify everything I write here as AppCheck itself is new, and I am not using it in production personally yet, so this is "book learning" as opposed to practical experience. However, I watched the Google I/O presentation on AppCheck and I have read all the documents as I attempted to work on it here, and I believe that so long as you use AppCheck in non-enforcing mode there should be no problem.

If you attempt to enforce AppCheck tokens then you will have a problem because react-native-firebase doesn't handle AppCheck yet (apologies everyone for the time taken - there have been a steady stream of bugs and PRs here and I've been giving them priority, only so many hours in the day...).

I believe your error message there is unrelated to AppCheck but may be related to "DeviceCheck API" not being enabled. Either way the stack trace looks bad but probably has a message right above it saying it's going to generate a new keyset because of the stack, like: firebase/flutterfire#4651 ?

Thanks Mike, I won’t touch it until we got a clear picture of it.

As for DeviceCheck API, it’s enabled, I’ve also disable/enable it just in case so I guess that’s not the case. I ll check my SHA- again, maybe there’s something wrong in there. I have a feeling that BrowserStack devices are rooted and that might be the issue (they open recaptcha page).

/offtopic

@mikehardy I’m reading now that this might be because of my test numbers being in the format +1111111115. Will test with real numbers to see.

you might like https://rnfirebase.io/reference/auth/authsettings#appVerificationDisabledForTesting

Oh, and worth noting if you are using the database emulator you may have a bad interaction until upstream issue firebase/firebase-tools#3663 is handled

Very cool to hear it is working! You never know on the first release.
I had some thoughts on extending the capabilities a little to be more ergonomic for the react-native use case (where developers really do not want to mess around with the native code like is required right now for the debug / CI case or for setting up AppAttest

Specific thoughts:

• add ability to configure automatic data collection in general on app and automatic token refresh for app check via firebase.json for more ergonomic handling of GDPR / privacy / opt-in case
• add ability to configure provider in firebase.json and make a debug provider that may accept a shared debug token for the CI case so people may inject their shared token into firebase.json in test environments and not worry about the AppDelegate / androidTest native changes I had to do in our e2e setup. This would open the door for AppAttest ios implementation in future as well

Not sure if anyone cares though :-) ? But you're actually using it, so I'm curious for feedback

@mikehardy Your 2 suggestions would indeed be nice to have, especially regarding the debug provider configuration that had to be configured in native code using some good old #if DEBUG
And of course, the CI case would need it somehow :)

Okay - thanks again for the feedback. It was my hunch that probably everyone would need to do something native for the debug provider (otherwise could you ever really turn on "enforcing?") and this confirms it, which means some aid to devs for that config setup is probably warranted. Cheers

@mikehardy Hi again
One thing I forgot to mention : for the Android release build, I manually added this :
implementation 'com.google.firebase:firebase-appcheck-debug:16.0.0-beta02'

in the package build.gradle, because of this import in the ReactNativeFirebaseAppCheckModule class :
import com.google.firebase.appcheck.debug.DebugAppCheckProviderFactory;

Did I miss something ? Thanks for your help

@wgodin thanks again for the feedback!
Once #5606 is merged release builds will no longer need your workaround, you're not missing something, that was an error in my initial implementation. I suppose you know you are the first android release using the code since you are the first report and it's a fundamental issue, how exciting? 😅 - let me know if anything else turns up!

I have also implemented firebase.setLogLevel which works on iOS and should help with getting the debug token you'll need, I think it will work such that you can get the App Check token without adding -FIRDebugEnabled to your launch arguments, if you add the new app_log_level key as debug in firebase.json so it's present during startup. Seemed to work well for me in testing?

I will have to leave programmatic control of providers for another day and move on to other APIs for a little while but this should be enough to get people moving I hope.

I'll be listening though - you all are my early adopters here so your feedback is great! Thanks

I can't really document it, sorry. The best documentation is the changes in our tests e2e app during the implementation, you may see those here in the files in the 'tests' directory 99cd4e5

The reason I can't document is because there is no best way to use it in debug other than the native changes docuented in the upstream / official documentation for each platform. You may follow this discussion for progress on making it easier: firebase/firebase-ios-sdk#8584