4
votes

I have a react-native app running on iOS. On iOS 9.2, the app runs perfectly fine, both when using the Chrome debugger and not using it. However, in iOS 8.1, the app will load, and lists can be swiped, data is loaded from the server, etc. This is tested and works in both the simulator and on physical devices, for both OS's.

The tricky part is, when running with the Chrome debugger, iOS 8.1. works as expected. When it is NOT running with the Chrome debugger, the app crashes whenever navigating to a new view. I have a custom swipe view, so I can swipe to another view, and I can see all the content properly loaded right before it 'settles' and crashes. If I simply try to click to a new page, it will crash almost instantly.

My guess (educated from this stackoverflow question), is that it is a timing issue, provided that my hypothesis that iOS 8.1 runs faster than iOS 9.2 is correct. I am guessing that the debugger slows down the app enough that the timing issue doesn't present itself. That being said, I tried the 'slow animation' mode in the simulator, and it still crashed when not using the debugger.

With that in mind, I recognize it could very well be a configuration issue. I'm running XCode 7.2, and am using react-native 0.21.0-rc.

The error that I get when trying to click anywhere/change views is:

null is not an object (evaluating 'inst.componentWillReceiveProps')

1
I have a very similar issue on a react-native app, everything runs perfect except on my iphone 6 plus (and only the release version), maybe because it runs faster than other devices I've tested... Did you find a solution to your problem? ā€“ Dagobert Renouf
Unfortunately not yet. I've backlogged the issue for the time being. Will update if anything new is discovered. ā€“ Josh Baker

1 Answers

0
votes

Had this same issue on release of our app - it wouldn't show up in the simulator, only in release.

In our case, it turned out we had an error in a section of code that was only hit if the browser had gained support for the js function

Date().toLocaleTimeString

Mozilla stated you could check for the browser support for this function by doing the following:

function toLocaleTimeStringSupportsLocales() {
  try {
    new Date().toLocaleTimeString('i');
  } catch (e) {
    return eā€‹.name === 'RangeError';
  }
  return false;
}

I had not updated to the latest Xcode yet, but it was crashing on my iPhone running iOS 10. Once I upgraded Xcode to the latest version, the error began showing up in the Simulator as well, as Safari presumably gained the support for toLocaleTimeString in the sim as well. The error reported running debug was far more specific and pointed me to the fix.

I doubt this is the same issue, but this is how I fixed this error in my application, and how it only showed up in release versus the sim -- strictly because of differing execution paths due to different versions of Safari. Hope this helps someone else with this issue.