[ios] RCTBundleURLProvider isPackagerRunning stalls for wifi-disabled device

[aleclarson]

Specifically this line is blocking the thread when using a device (with WIFI unknowingly disabled).

Might want to use a semaphore and RCTLogError.

Otherwise, the user is left confused about the stalled thread.

[lacker]

What's the problematic result here - when you run on a device with no internet connection it silently fails and the ideal would be to log a message saying "there's no internet"? If you have a specific fix in mind with the semaphore then it would be really cool to submit a PR fixing it....

[v-ahuja]

Both https://stackoverflow.com/questions/44102199/react-native-dev-mode-app-doesnt-fallback-to-offline-bundle-on-physical-device and https://stackoverflow.com/questions/43616804/react-native-ios-app-crashes-when-run-outside-of-xcode-with-failed-to-scene-crea are caused by this.

My expectation is that it should fall back to the offline bundle. Really, with a dev build, I can't use the app in offline mode because of this issue.

[v-ahuja]

I have a temporary workaround and am putting it here for documentation purposes in case someone with a better knowledge of objective-c (i have none), url resolution and xip.io can put in the proper change (more on that later). Please note that this is a very fragile solution. However, I'm still posting this here because as I said earlier, if you'd like to load the offline bundle when you aren't connected to your app, the current state of affairs makes it almost impossible; apple will kill your app during loading time if the synchronous http call to resolve whether a packager is running takes longer than 19 seconds (and this is often the case for me).

Disclaimers:
(a) Try this at your own risk.
(b) You have to make sure you turn off 'Debug JS Remotely' in the inspector, when you're not on wifi, otherwise, react tries to fallback to hitting localhost.

In RCTBundleURLProvider.m (isPackagerRunning) replace the commented section with what's below:

// NSURLRequest *request = [NSURLRequest requestWithURL:url];
  // NSURLResponse *response;
  // NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:NULL];
  // NSString *status = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
  // return [status isEqualToString:@"packager-status:running"];

  NSURLRequest *request = [NSMutableURLRequest requestWithURL:url cachePolicy:NSURLRequestReloadIgnoringCacheData timeoutInterval:5];
  NSHTTPURLResponse *response = nil;
  NSData *data = [NSURLConnection sendSynchronousRequest:request returningResponse:&response error:NULL];
  if (response == nil) {
      // timed out or failed
      NSLog(@"sync request timed out.");
      return false;
  } else {
      // all good
      NSString *status = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
      return [status isEqualToString:@"packager-status:running"];
  }
  return false;

This will cause URL resolution to time-out in 5 seconds and therefore fallback to the offline bundle.
HOWEVER, if this doesn't work with xip.io (in my case, it seemingly didn't), modify the script react-native-xcode.sh by replacing $IP.xip.io with $IP

[v-ahuja]

Proper fix discussion:

I'm not sure if this possible, but this synchronous call to figure out if the packager is running -
(a) shouldn't be made on the main thread, since ios will crash you if the main thread takes longer than 19s (approx) to end.
(b) shouldn't be synchronous at all, but instead should be async.

Also, I'd like to add that I've noticed that switching back and forth between WiFI and cellular doesn't work well and is quite fragile. React falls back to localhost often, even when the packager is running. The fact that it's inconsistent is worrisome.

[v-ahuja]

ping

[MarkRich]

ping as well. also having this problem.

[v-ahuja]

Can we get a 'needs help' label on this? would be cool if someone with objective-c knowledge can help out on this.

[hramos]

Hi there! This issue is being closed because it has been inactive for a while. Maybe the issue has been fixed in a recent release, or perhaps it is not affecting a lot of people. Either way, we're automatically closing issues after a period of inactivity. Please do not take it personally!

If you think this issue should definitely remain open, please let us know. The following information is helpful when it comes to determining if the issue should be re-opened:

• Does the issue still reproduce on the latest release candidate? Post a comment with the version you tested.
• If so, is there any information missing from the bug report? Post a comment with all the information required by the issue template.
• Is there a pull request that addresses this issue? Post a comment with the PR number so we can follow up.

If you would like to work on a patch to fix the issue, contributions are very welcome! Read through the contribution guide, and feel free to hop into #react-native if you need help planning your contribution.