react-native: Xcode 14.3 - Error: Unable to resolve module ./Libraries/Components/DatePicker/DatePickerIOS

Update

Impact

Runtime errors encountered during development cannot be symbolicated (=stack traces made readable)

Affected users and versions

• All versions of React Native supporting iOS 16.4
• Simulators and devices on iOS 16.4 and above (the change could be backported to older versions)
• JavaScriptCore (JSC) only - not Hermes

Root cause

A recent change to JavaScriptCore strips query strings from source URLs in stack traces. Thanks again @AndreasLS for the pointer. CC @rreno, @JonWBedard from WebKit for awareness - would love to chat about this!

Symptoms

When any (unrelated) error or warning (redbox/yellowbox) originates in anywhere your app’s JS code during development, the client sends a /symbolicate request to Metro with the stack trace. Normally, frames of that stack trace include the bundle URL with all relevant build parameters, alongside line and column numbers. Metro’s job is to map that back to your source code to show you where the error originated in a readable format. However, with query strings stripped from the stack trace, Metro fails to reconstruct your bundle because ?platform=ios is missing, and therefore it can’t resolve platform-specific code. By chance, DatePickerIOS is usually the first platform-specific component it encounters, so you see the error in the issue title.

Workarounds

• The symbolication error hides a separate, underlying error - if you switch to an older iOS version you should see the real error (or warning) that triggered symbolication in the first place. Address that, and it should go away on 16.4 too.
• Develop on an older version of iOS (new Xcode is fine). This issue only affects the development process (and any production error reporting) - production users on 16.4 shouldn’t experience any issue.
• Switch to Hermes - I appreciate that isn’t a trivial change.
• Use Metro’s server.rewriteRequestUrl to “guess” the query string if it seems to be missing. Note that there are other parameters besides platform that affect the bundle output, you’ll need to make sure these are right for your setup - details below have the defaults for a react-native init project.

Using server.rewriteRequestUrl in metro.config.js

// metro.config.js
module.exports = {
  server: {
    rewriteRequestUrl: (url) => {
      if (!url.endsWith('.bundle')) {
        return url;
      }
      // https://github.com/facebook/react-native/issues/36794
      // JavaScriptCore strips query strings, so try to re-add them with a best guess.
      return url + '?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true';
    }, // ...
  }, // ...
}

Next steps

We’re still working on what the solution should be - it will likely involve a native-side change which we’ll backport to maintained RN versions as new patch releases - and will update again here next week.

Same issue

same issue

Adding more context:

That was the change: https://github.com/WebKit/WebKit/blob/e214b2a322c49e1ff3aa7991b6f9478d8cbd80e5/Source/JavaScriptCore/runtime/StackFrame.cpp#L137

That was the reason: WebKit/WebKit@71985aa

Huge thanks @AndreasLS for nailing the root cause.

Just a quick ack - we don’t know exactly what the solution is going to be here (native workaround, major Metro change) but we’re treating it as a priority.

To reiterate, this affects JSC users and prevents Metro from correctly symbolicating error stacks. In other words it’s an error-reporting-error, and there are varying underlying errors that may cause it to appear.

hey folks - quick update; we’ve raised this to the Meta team and the Metro folks are now looking at it, expect an update from them here at some point in the near future.

A few quick observations:

• @AndreasLS thank you for your investigation, it seems to be spot-on and you pointing us in that direction has been super helpful
• this seems to be JSC-only. While we know that it’s not viable to just say “fix is move to Hermes lul”, can anyone try if they are still hit by this when on Hermes?
• it sounds like this problem is RN-version-independent which… sucks 😅 once we know more from the Metro team we’ll try to figure out how to address this across the board.
• Easter weekend is coming up so a lot of folks in EU offices will be on bank holidays both tomorrow (Friday) and Monday. Please keep this in mind, we’re doing what we can with the time we have.

Adding more context:

That was the change: https://github.com/WebKit/WebKit/blob/e214b2a322c49e1ff3aa7991b6f9478d8cbd80e5/Source/JavaScriptCore/runtime/StackFrame.cpp#L137

That was the reason: https://github.com/WebKit/WebKit/commit/71985aa1520560154a329e5b54159fff3173cf22

For the build problem you can upgrade to either 0.70.8 or 0.71.6 which contains a fix for that.

For the very odd Metro compilation error with DatePickerIOS I found the problem is using iOS simulators with iOS 16.4. If you use a iOS 15 or 16.0 simulator it doesn’t happen. You can download older simulator versions in Xcode > Window > Device and Simulators > Simulators tab

Still trying to figure out why iOS 16.4 is an issue here though. So hold tight for that.

Xcode -> Pods -> Build Settings -> Ios Deployment Target change to 12.4 and will work! 🔥

Same here, I’m on React Native 0.70.5 and XCode 14.3.

This error appears whenever there is any other type of error on the app, and eventually crashes with a memory leak.

update: we just released 0.71.11 that contains the same fix we’ve put in 72 RC5, please check it out. Patches for 0.70 and 0.69 will come out in the next few weeks.

I’m in the process of preparing backports to RN 0.71 (Metro 0.73), RN 0.70 (Metro 0.72) and RN 0.69 (Metro 0.70), which I think covers the supported release range? Again, we’ll need bumps of Metro + CLI + RN, but other than the churn I don’t see any problem with picking this back.

@bennettfrazier the first release to get it will be RC4 of 72, we’re about to start testing today (found some last minute hiccups detected via CI) and given how Monday is bank holiday mostly everywhere, we’re aiming at Tues/Wed next week.

Once RC4 is out and people report that the problem is indeed addressed, we’ll evaluate if it’s viable to backport to the rest of the release window (71,70,69).

reopening until a release with the fix is out. It’s likely that we might explore also backporting this, if viable.

@Imtayaz

From what I could find, the source of the issue is that the DatePickerIOS files have the extension .android.js and .ios.js. by default, the metro resolver is looking for files with the extension of .native|.native.ts|.ts|.native.tsx|.tsx|.native.js|.js|.native.jsx|.jsx|.native.json|.json (per the error message)

So all we need to do is tell metro to look for some extra stuff via the metro.config.js. This is my metro.config.js file after modifying it and eliminating my errors:

const { getDefaultConfig } = require('expo/metro-config');

const config = getDefaultConfig(__dirname);

config.resolver.sourceExts.push("ios.js", "android.js");

module.exports = config;

I hope it helps!

More information on this can be found in the expo documentation

Any update about the issue ?

We’re working on rolling out supporting query-string free URLs for Metro, and altering the bundling request URL on iOS at least for JSC. It’s not a trivial fix, unfortunately, and will need point releases of Metro and RNCLI and a patch in RN backported as far as we need - it’ll likely be ~2 weeks to see this in an RN release.

My app was rejected from the app store due to crashes on 16.4.

The issue in iOS store seems to make the fix not enough to get an application out for production which is more than critical. (we have a prod launch next week, which makes me kind of inconfortable.

This issue does not affect production builds. It purely affects error stack traces, so it’s triggered by other errors - you might try one of the workarounds above (easiest: use an older iOS version in your device/simulator) to try to find the underlying error. App store rejections could be for various other reasons, of course.

is there another way?

I’m having the same issue, I’m on version 0.69.9 and XCode 14.3

~Closing this issue as~ both RN (PR https://github.com/facebook/react-native/pull/37501) and Metro (PR https://github.com/facebook/metro/pull/989) fixes have been Merged. 🎉

P.S.: Picked into 0.72-stable

Thanks, @mjmasn 🙏 for reporting this.

If this issue still persists or if there are any other concerns, then please let us know.

I had the same issue with RN 0.67.2 + iOS 16.4 combination. Enabling Hermes solved the issue.

Safari 16.4 (aka WebKit) have changed the way it logs the errors. We don’t have the complete url anymore, and the platform is on the query params. That way, the symbolication gets broken and will cause an infinity loop of reloading bundle.

Workarounds:

• disable /symbolicate calls for metro server
• add the plataform to the index.js file name. (index.ios.js)
• fix the parameters manually for symbolication process
• run older iOS simulator version

BEFORE 16.4:
asyncGeneratorStep@http://localhost:8081/index.bundle?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true&app=my.app.test:20986:26

AFTER 16.4:
asyncGeneratorStep@http://localhost:8081/index.bundle:20986:26

To emphasize, this happens on any iOS 16.4 device, simulator or physical device.

If this helps any, I’ve also run into the same Metro compilation error on my physical device on 16.4.

Same issue, React native 0.70.5 and XCode 14.3.

Got the same issue, also version 0.71.6 Xcode 14.3

The same issue is happening for me on version 0.71.6 of react-native and version 14.3 of Xcode.

@Neelshah768 @Santosl2 have you tested 0.72 RC5? As mentioned above, that’s the only version currently that has the fix, backports are in the work.

@kelset is there a target date for the release of this fix?

Thanks @robhogan 🎉

config.resolver.sourceExts.push(“ios.js”, “android.js”);

@ChristopherAChase thanks for looking to help, but I would not recommend this. Metro already prepends the target platform to the extensions it tries (with platform-specific files taking priority), the issue here is that the platform query string is missing, stripped by the JS engine before it reaches Metro, so Metro doesn’t know which platform to try.

The problem with adding platform-style extensions to sourceExts is that Metro will try them regardless of the target platform - so may resolve to an .ios.js file on Android, or .android.js on iOS, or it may resolve to a generic implementation even where there’s a platform-specific one available. While the bundle may build, that’s likely to result in unexpected behaviour including runtime crashes if any of those components are used.

See https://github.com/facebook/react-native/issues/36794#issuecomment-1500880284 for the workarounds we recommend until we get this fixed. (In the works with https://github.com/facebook/react-native/pull/37501 and https://github.com/facebook/metro/pull/989)

Same issue with react-native: 0.71.7, expo: 48.0.16, expo-cli: 6.3.7, eas-cli: 3.12.1

I also confirm that the workaround suggested here works for me

I’m facing the same issue with 0.70.9. Any updates?

I am using expo managed workflow I got this issue after upgrading to expo sdk 47. Please help, currently using react native: 0.70.8

try updating RN to 0.71.7 and expo to 48.0.15 I’m using a managed workflow too and my error is gone in these versions using hermes (wich is faster and lower app size)

also don’t forget to update your expo and eas CLIs

My app was rejected from the app store due to crashes on 16.4. Testing myself, this error is being reproduced. Is there a solution for this yet?

To note, I’ve tried switching to hermes and using the rewriteRequestUrl in metro.config.js as described above, but continue to get the DatePickerIOS errors.

I have same error with Expo.

i"m also having the same issue

For the build problem you can upgrade to either 0.70.8 or 0.71.6 which contains a fix for that.

For the very odd Metro compilation error with DatePickerIOS I found the problem is using iOS simulators with iOS 16.4. If you use a iOS 15 or 16.0 simulator it doesn’t happen. You can download older simulator versions in Xcode > Window > Device and Simulators > Simulators tab

Still trying to figure out why iOS 16.4 is an issue here though. So hold tight for that.

Thanks really helpful

I have facing same issues on iOS, My Xcode version is Version 14.3.1 , and react-native-cli: 2.0.1 react-native: 0.69.1 this is i have in react native, i had changed the platform version in /Users/mcl-0048/Desktop/Conexus/node_modules/react-native/scripts/react_native_pods.rb on line number 401 ‘platforms’ => { ‘ios’ => ‘12.0’, }, like this then getting this issues ERROR TypeError: undefined is not an object (evaluating ‘mediaDevices.enumerateDevices’) Error: Unable to resolve module ./Libraries/Components/DatePicker/DatePickerIOS from /Users/mcl-0048/Desktop/Conexus/node_modules/react-native/index.js:

please some let me know how to resolve this issues i have tried multiple solutions but none of them are working and my client is waiting for the project delivery asap

I had this same erro… What’s the solution?

Hey folks! Can anyone check if with the latest RC, RC5, the issue is addressed?

Which metro.config.js file should I edit? If I search on my project directory I see several file for some of the packages I installed.

Update

Impact

Runtime errors encountered during development cannot be symbolicated (=stack traces made readable)

Affected users and versions

• All versions of React Native supporting iOS 16.4
• Simulators and devices on iOS 16.4 and above (the change could be backported to older versions)
• JavaScriptCore (JSC) only - not Hermes

Root cause

A recent change to JavaScriptCore strips query strings from source URLs in stack traces. Thanks again @AndreasLS for the pointer. CC @rreno, @JonWBedard from WebKit for awareness - would love to chat about this!

Symptoms

When any (unrelated) error or warning (redbox/yellowbox) originates in anywhere your app’s JS code during development, the client sends a /symbolicate request to Metro with the stack trace. Normally, frames of that stack trace include the bundle URL with all relevant build parameters, alongside line and column numbers. Metro’s job is to map that back to your source code to show you where the error originated in a readable format. However, with query strings stripped from the stack trace, Metro fails to reconstruct your bundle because ?platform=ios is missing, and therefore it can’t resolve platform-specific code. By chance, DatePickerIOS is usually the first platform-specific component it encounters, so you see the error in the issue title.

Workarounds

• The symbolication error hides a separate, underlying error - if you switch to an older iOS version you should see the real error (or warning) that triggered symbolication in the first place. Address that, and it should go away on 16.4 too.
• Develop on an older version of iOS (new Xcode is fine). This issue only affects the development process (and any production error reporting) - production users on 16.4 shouldn’t experience any issue.
• Switch to Hermes - I appreciate that isn’t a trivial change.
• Use Metro’s server.rewriteRequestUrl to “guess” the query string if it seems to be missing. Note that there are other parameters besides platform that affect the bundle output, you’ll need to make sure these are right for your setup - details below have the defaults for a react-native init project.

Using server.rewriteRequestUrl in metro.config.js

// metro.config.js
module.exports = {
  server: {
    rewriteRequestUrl: (url) => {
      if (!url.endsWith('.bundle')) {
        return url;
      }
      // https://github.com/facebook/react-native/issues/36794
      // JavaScriptCore strips query strings, so try to re-add them with a best guess.
      return url + '?platform=ios&dev=true&minify=false&modulesOnly=false&runModule=true';
    }, // ...
  }, // ...
}

Next steps

We’re still working on what the solution should be - it will likely involve a native-side change which we’ll backport to maintained RN versions as new patch releases - and will update again here next week.

My app was rejected from the app store due to crashes on 16.4. Testing myself, this error is being reproduced. Is there a solution for this yet?

To note, I’ve tried switching to hermes and using the rewriteRequestUrl in metro.config.js as described above, but continue to get the DatePickerIOS errors.

Hi 😃

I think you may have something else in your application causing it to crash.

The warning produced above, as annoying as it is for polluting the console, doesn’t cause an app to crash from my understanding and experience so far.

We haven’t had issues with App Store review rejections to do with this error causing any crashes whatsoever.

this error happens to me on my local machine, but… happens on a real device when I make the release to the App Store?

For the build problem you can upgrade to either 0.70.8 or 0.71.6 which contains a fix for that.

For the very odd Metro compilation error with DatePickerIOS I found the problem is using iOS simulators with iOS 16.4. If you use a iOS 15 or 16.0 simulator it doesn’t happen. You can download older simulator versions in Xcode > Window > Device and Simulators > Simulators tab

Still trying to figure out why iOS 16.4 is an issue here though. So hold tight for that.

Worked perfectly with iOS 16.0

@AndreasLS excellent detective work, that makes a lot more sense that Xcode itself being the culprit.

Same issue Here with Xcode 14.3

Same issue with Xcode 14.3

Same issue here Xcode 14.3

same issue React Native: 0.70.5 Xcode: 14.3

I downgraded xcode version to 14.2 it helped.

1. Go to apple developer and download version 14.2
2. Set 14.2 version Enjoy.