On Ios React Native Firebase AppCheck uses 'exchangeDebugToken' url in release build. Android is working fine.

[AmitDigga]

Refernece on stackoverflow

Running Release Build

On xcode I am using Build Configuration of Release to run app on a physical device.

Error shown in console when app starts

[javascript] [Error: [appCheck/token-error] The operation couldn’t be completed. The server responded with an error: 
 - URL: https://firebaseappcheck.googleapis.com/v1/projects/##########/apps/##########:exchangeDebugToken 
 - HTTP status code: 403 
 - Response body: {
  "error": {
    "code": 403,
    "message": "App attestation failed.",
    "status": "PERMISSION_DENIED"
  }
}
]

Look the above has exchangeDebugToken in the url

Javascript Initialization

async function initAppCheck() {
  const appcheck = firebase.appCheck();
  const rnfbProvider = appcheck
    .newReactNativeFirebaseAppCheckProvider();
  await rnfbProvider.configure({
    android: {
      provider: __DEV__ ? 'debug' : 'playIntegrity',
      debugToken: 'fba7bbac-8440-4965-b5f2-8c020bd042c3',
    },
    apple: {
      provider: 'appAttestWithDeviceCheckFallback',
    },
    web: {
      provider: 'reCaptchaV3',
      siteKey: 'unknown',
    },
  });

  await appcheck.initializeAppCheck({
    provider: rnfbProvider,
    isTokenAutoRefreshEnabled: true,
  });
  const token = await appcheck.getToken(true);
}

__DEV__ is false when logged.

Pod File:

require_relative '../node_modules/react-native/scripts/react_native_pods'
require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'

platform :ios, min_ios_version_supported
prepare_react_native_project!
flipper_config = FlipperConfiguration.disabled 
# flipper_config = ENV['NO_FLIPPER'] == "1" ? FlipperConfiguration.disabled : FlipperConfiguration.enabled
linkage = ENV['USE_FRAMEWORKS']
if linkage != nil
  Pod::UI.puts "Configuring Pod with #{linkage}ally linked Frameworks".green
  use_frameworks! :linkage => linkage.to_sym
end

target 'BusinessClientApp' do
  config = use_native_modules!
  use_frameworks! :linkage => :static
  
  # pod 'Firebase', :modular_headers => true
  # pod 'FirebaseCore', :modular_headers => true
  # pod 'GoogleUtilities', :modular_headers => true
  # pod 'FirebaseCoreExtension', :modular_headers => true
  # pod 'FirebaseAppCheckInterop', :modular_headers => true
  # pod 'FirebaseAuthInterop', :modular_headers => true
  # pod 'FirebaseMessagingInterop', :modular_headers => true
  # pod 'GTMSessionFetcher', :modular_headers => true
  # pod 'FirebaseStorageInternal', :modular_headers => true
  # pod 'FirebaseCoreExtension', :modular_headers => true
  
  # Flags change depending on the env values.
  flags = get_default_flags()

  use_react_native!(
    :path => config[:reactNativePath],
    # Hermes is now enabled by default. Disable by setting this flag to false.
    # Upcoming versions of React Native may rely on get_default_flags(), but
    # we make it explicit here to aid in the React Native upgrade process.
    :hermes_enabled => flags[:hermes_enabled],
    :fabric_enabled => flags[:fabric_enabled],
    # Enables Flipper.
    #
    # Note that if you have use_frameworks! enabled, Flipper will not work and
    # you should disable the next line.
    :flipper_configuration => flipper_config,
    # An absolute path to your application root.
    :app_path => "#{Pod::Config.instance.installation_root}/.."
  )

  target 'BusinessClientAppTests' do
    inherit! :complete
    # Pods for testing
  end

  post_install do |installer|
    react_native_post_install(
      installer,
      # Set `mac_catalyst_enabled` to `true` in order to apply patches
      # necessary for Mac Catalyst builds
      :mac_catalyst_enabled => false
    )
    __apply_Xcode_12_5_M1_post_install_workaround(installer)
  end
end

App Delegate.mm

#import "AppDelegate.h"
#import "RNFBAppCheckModule.h" // https://rnfirebase.io/app-check/usage
#import <Firebase.h>

#import <React/RCTBundleURLProvider.h>

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  // Firebase config
  [RNFBAppCheckModule sharedInstance]; // ⬅️ ADD THIS LINE BEFORE [FIRApp configure] https://rnfirebase.io/app-check/usage

  [FIRApp configure];
  
   self.moduleName = @"BusinessClientApp";
  return [super application:application didFinishLaunchingWithOptions:launchOptions];
}

- (NSURL *)sourceURLForBridge:(RCTBridge *)bridge
{
#if DEBUG
  return [[RCTBundleURLProvider sharedSettings] jsBundleURLForBundleRoot:@"index"];
#else
  return [[NSBundle mainBundle] URLForResource:@"main" withExtension:@"jsbundle"];
#endif
}


/// This method controls whether the `concurrentRoot`feature of React18 is turned on or off.
///
/// @see: https://reactjs.org/blog/2022/03/29/react-v18.html
/// @note: This requires to be rendering on Fabric (i.e. on the New Architecture).
/// @return: `true` if the `concurrentRoot` feature is enabled. Otherwise, it returns `false`.
- (BOOL)concurrentRootEnabled
{
  return true;
}

@end

Running this on simulator also get the same error, but it opens a recaptcha page for which leads to successful sign-in. But on physical device recapcha do not open and auth/error is thrown.

[mikehardy]

(deleted comment after I realized the modular headers stuff was commented out, looking more closely now)

[mikehardy]

You may observe in the code that the iOS RNFBAppCheckProviderFactory initially configures itself for debug by default:

https://github.com/invertase/react-native-firebase/blob/main/packages/app-check/ios/RNFBAppCheck/RNFBAppCheckProviderFactory.m

However, when you call configure, in the same file you can see that it obliterates the startup/default/debug configuration with whatever you configure it with afterwards.

So, if I understand correctly - that you are seeing debug token exchange attempts even after configuring AppCheck for appAttestWithDeviceCheckFallback - I can only imagine that you have a race condition between someone using the AppCheck system and attempting to get a token before it is fully configured for appAttestWithDeviceCheckFallback vs the initial startup debug configuration

There is not enough code posted to say whether this is happening or not, as it is not a complete example (https://stackoverflow.com/help/minimal-reproducible-example) but perhaps your startup sequence is not properly awaiting on initAppCheck...

[AmitDigga]

Thank you @mikehardy. I will check this and revert if I found something.

[tarkcelk]

@AmitDigga i have encountered the same case, did you solve it ?

[tarkcelk]

@mikehardy when i look the analytic events some of the users are able to get the token but almost 95% are failing, my setup is almost same as @AmitDigga ,

app-check version: 18.4.0

[mikehardy]

@tarkcelk I'm not sure how your comment about some users getting a token and some users not getting a token relates to the discussion opened by the original poster on the topic of "I see debug configuration in release builds". They seem unrelated.

[tarkcelk]

@mikehardy because of the debug configuration in release build suppose, i tried to reproduce it in release build, it happens on first install but when i killed the app and open again, it fetches the success token