react-native-reanimated: Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication)

Description

When I upgrade the v2.0.0-alpha.8 app stuck white screen on iOS simulator debug mode. I got this error in console; Invariant Violation: Module AppRegistry is not a registered callable module (calling runApplication). Normal mode works as expected. Also v1.x has not this issue.

Package versions

  • React: 16.13.1
  • React Native: 63.3
  • React Native Reanimated: 2.0.0-alpha.8
  • NodeJS: 10.21.0

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 42
  • Comments: 39 (9 by maintainers)

Most upvoted comments

Kill the terminal/command prompt running your node JS and run your app again.

So I’ve managed to work out what was causing my issue above ^^. I was trying to use reanimated2 in a brownfield app where the RCTBridge gets initialized outside of the AppDelete (so AppDelegate does not implement the RCTBridgeDelegate protocol). In this circumstance the jsExecutorFactoryForBridge function from UIResponder+Reanimated.mm is never called, and therefore global.__reanimatedModuleProxy is never setup for the JS layer to use.

I’ve repro’d the issue by forking the Reanimated2Playground repro and changing the AppDelegate to use a RCTBridge that’s initialized from a separate class here.

This works…

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate, RCTBridgeDelegate {
  
  var window: UIWindow?
  
  func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {

    let bridge = RCTBridge(delegate: self, launchOptions: nil)
    let rootView = RCTRootView(bridge: bridge!,
                               moduleName: "Reanimated2Playground",
                               initialProperties: nil)

    self.window = UIWindow(frame: UIScreen.main.bounds);
   
    let rootViewController = UIViewController();
    rootViewController.view = rootView;
    
    self.window!.rootViewController = rootViewController;
    self.window?.makeKeyAndVisible();
                                
    return true
  }
  
  func sourceURL(for bridge: RCTBridge!) -> URL! {
    return RCTBundleURLProvider.sharedSettings()?.jsBundleURL(forBundleRoot: "index", fallbackResource: nil)
  }
}

But this doesn’t work…

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
  
  var window: UIWindow?
  
  func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {

    let rootView = RCTRootView(bridge: BridgeManager.sharedInstance.bridge,
                               moduleName: "Reanimated2Playground",
                               initialProperties: nil)

    self.window = UIWindow(frame: UIScreen.main.bounds);
   
    let rootViewController = UIViewController();
    rootViewController.view = rootView;
    
    self.window!.rootViewController = rootViewController;
    self.window?.makeKeyAndVisible();
                                
    return true
  }
}

// Bridge is initialized in a class that doesn't extend from UIResponder so some of 
// the Reanimated init code from UIResponder+Reanimated.mm doesn't fire. 
class BridgeManager: NSObject, RCTBridgeDelegate {
  lazy var bridge: RCTBridge = {
      return RCTBridge(delegate: self, launchOptions: nil)
  }()
  
  static let sharedInstance = BridgeManager()

  private override init() {
      super.init()
  }
  
  func sourceURL(for bridge: RCTBridge!) -> URL! {
    return RCTBundleURLProvider.sharedSettings()?.jsBundleURL(forBundleRoot: "index", fallbackResource: nil)
  }
}

So it appears there is an issue with Reanimated2 and brownfield React Native apps (or apps that don’t follow the traditional template from React Native hello world). Should I raise a separate issue for this? (Feels quite important for Reanimated2 to work in Brownfield scenarios)

I also run into this when using reanimated rc1 with react-native-navigation (It used to work in beta 8)

FWIW I had the same issue (while upgrading to v2.9). As Ishmaell suggested, just kill the bundler and rebuild/rerun from xcode/react-native run-ios and it started working again.

Please take a look at any errors that appear just prior to the AppRegistry complaint. In my case, I’d installed a new module/plugin using NPM, yet didn’t link the module or run “pod install” to get it registered. After doing so, I was able to run the app.

example: react-native link @react-native-community/geolocation

cd to ios and run: pod install

Just updated to reanimated v2.x and RN 0.64, running into this issue as well. Any suggestions or fixes so far?

Just ran into this issue this evening. Similar issue using react-native-navigation.

@mrbrentkelly, BridgeManager in your example should be a subclass of UIResponder, because reanimated relies on the class that is used as a bridge delegate to be a subclass of UIResponder. See #1323, UIResponder+Reanimated.

I guess alternatively you can patch UIResponder+Reanimated. I had the same issue

@dov11 Yep exactly, that’s what I was alluding to in my original message 👍 i.e. requiring your class to extend from UIResponder or else Reanimated won’t be initialised correctly felt like it could be a bug that needed addressed for projects that don’t setup their bridge as part of the AppDelegate.

i face the same problem, then i delete App.js in the src folder, the file duplicate with App.tsx

The problem here is not that you can’t use debugger with turbo modules (e.g. you can’t debug Reanimated v2 code), the problem is that you can’t use the debugger at all in your app, otherwise, if it’s turned on, the app will crash as soon as it hits a screen where Reanimated v2 is used

Edit: Flipper and Hermes Debugger work as expected, so I guess we wait for RN 0.64 to have Hermes for iOS as well

I meant exactly that. When you use any turbo module in your app, it’ll crash after you try debugging the code that makes calls to it. That’s why you can debug screens without Rea2 - Rea2 code hasn’t yet run so it didn’t call C++ code and didn’t crash.

You can’t really use the debugger with turbo modules such as Reanimated v2. See this comment for more information.

je viens de rencontré ce probeme egalement en executant https://reactnative.dev/docs/navigation de le documentation react-native

According to the https://typeorm.io/changelog#deprecations, CreateConnection is deprecated. If you are using it, upgrade typeorm

For anyone facing this issue with Android, here are some things which we added which fixes it for us.

  • In the build.gradle file at this line, it ceases to recognise other flavours. We fixed it by making the following change:
    -    Pattern pattern = Pattern.compile("(assemble|bundle|install|generate)(\\w*)(Release|Debug)")
    +    Pattern pattern = Pattern.compile("(assemble|bundle|install|generate)(\\w+)(Release|Debug)")
    
  • The we realised the other issue was that with Reanimated, there were two projects in our code. Reanimated’s build.gradle does not exclude the designsample project. So we changed this line to:
    - if(project.getProperties().get("android") && Integer.parseInt(minor) < 65)
    + if(project.getProperties().get("android") && Integer.parseInt(minor) < 65 && !project.name.equalsIgnoreCase("designsample"))
    

And things started working for us!

Update: I manage to get it to work with all reanimated versions until 2.3.0 ;

there is definitely a bug on newer versions for this exact scenario in the way the jsExecutorFactoryForBridge is being called.

I found this solution in the react-native-notification issues, which solved the problem for me: https://github.com/wix/react-native-notifications/issues/455#issuecomment-726094429 Essentially updating the hermes-engine to a patch version that solves a proxy issue 🧞

I also run into this when using reanimated rc3 with react-native-navigation

Also get this when using v2…no Expo and nothing special in my setup and v1 works fine. Quite a big blocker for upgrading to v2.

Still getting the issue with rc.2.