expo: [Expo 50] Unable to load dev client bundle on Android device (expo-dev-client@3.3.8)

Minimal reproducible example

https://github.com/vivek-pai/expo-reproducible-example

Summary

This is a continuation of issue #26364. I am still seeing the same error on the Android dev client build with expo-dev-client 3.3.8:

There was a problem loading the project.

This development build encountered the following error.

Unable to load script. Make sure you're either running Metro (run 'npx react-native start') or that your bundle 'index.android.bundle' is packaged correctly for release.

The linked reproducible example is just from running npx create-expo-app and installing the dev client.

I use WSL and build the dev client eas build --profile development --platform android and then run expo start --dev-client --tunnel

Upon running, I’ll see the following warning

**Tunnel URL not found (it might not be ready yet), falling back to LAN URL.**
Starting Metro Bundler
Tunnel connected.
Tunnel ready.

But, it still provides a usable url: › Metro waiting on exp+expo-test://expo-development-client/?url=https%3A%2F%2Fxxxxxx-y-8081.exp.direct

Connecting to that URL from my dev client (on my Android device), I get the “Unable to load script” error

To rule out the tunnel warning being an issue, I started without the expo tunnel expo start --dev-client › Metro waiting on exp+expo-test://expo-development-client/?url=http%3A%2F%2F172.20.72.246%3A8081 and used localtunnel to create a public accessible tunnel npx localtunnel --port 8081

Connected to that public address from my Android dev client=> Same “Unable to load script” error

In all attempts, I don’t see any “BUNDLE” or any other entries in the console.

The iOS dev client works fine, however. The non-dev client Android/iOS builds also work. This error only occurs on the Android dev client.

Environment

expo-env-info 1.2.0 environment info:
    System:
      OS: Linux 5.10 Ubuntu 20.04.6 LTS (Focal Fossa)
      Shell: 5.0.17 - /bin/bash
    Binaries:
      Node: 18.16.0 - ~/.nvm/versions/node/v18.16.0/bin/node
      npm: 9.5.1 - ~/.nvm/versions/node/v18.16.0/bin/npm
    npmPackages:
      expo: ~50.0.6 => 50.0.6 
      react: 18.2.0 => 18.2.0 
      react-native: 0.73.4 => 0.73.4 
    npmGlobalPackages:
      eas-cli: 7.1.3
    Expo Workflow: managed

WSL 2

Samsung Galaxy S22
Android 14

About this issue

Original URL
State: open
Created 5 months ago
Reactions: 16
Comments: 30 (9 by maintainers)

Most upvoted comments

Same, but seems to work if i load it with http://<tunnelurl>

+13

MrCox007 on Feb 16, 2024

^^ Thanks @wodin for referring me to this ticket. I had a team member hit this issue and was struggling to get past it. When I heard they got it to work if they changed the URL to HTTP, I thought it might be a cert issue.

This is what I shared over on discord:

A team member was struggling today to get Expo Direct to work. They ended up figuring out if they downgraded to http:// in the url, things worked. I took a look and found out that when expo direct generated the URL it is using their Expo username like so:

{random-hash}-{expousername}-8081.exp.direct

the Lets Encrypt cert is a *.exp.direct cert. Certificates, including wildcard certs, only cover the same subdomain they are issued for. They cannot cover n-deep subdomains. So what was happening was his expo username had a period in it, lets pretend his username was myuser.name this resulted in the following URL being generated for Expo Direct: pgtnlz1-myuser.name-8081.exp.direct While Expo infrastructure can route him correctly, the cert from Lets encrypt only covered name-8081.exp.direct subdomain. When accessing pgtnlz1-myuser.name-8081.exp.direct under HTTPs you get a certificate exception as pgtnlz1-myuser is a subdomain and can’t be covered by the cert.

I advised my co-worker to change his username on expo and remove the . from his username so that when Expo creates the random URL under the *.exp.direct it would all be on the same DNS zone. Once he did this, everything worked correctly.

Until expo changes the algorithm they use to create expo direct URLs, you must change your username if it has a period . in the username.

rmmeans on Apr 28, 2024

Update: I have managed to solve this by updating my node to the LTS version. Make sure to clean node cache as well to set up the correct version. I am running 20.12.0 and then there is no need for any tunnel or url manipulation.

I think you might be misunderstanding the larger issue. Most people here (as I interpret it) need to run tunnel, for network reasons. When doing so, we run into the issue that the default https URL does not work, and needs to be manipulated.

So, could you confirm that you mean that you don’t need the tunnel, and therefore overall it works (for you)?

I can confirm I do not have a need for tunnel. I used it because the regular connection was not working which I solved by updating node.

If there is still a need for tunnel regardless then I think the manipulation from ‘https’ to ‘http’ is still required.

Monkhai on Apr 8, 2024

Update: I have managed to solve this by updating my node to the LTS version. Make sure to clean node cache as well to set up the correct version. I am running 20.12.0 and then there is no need for any tunnel or url manipulation.

Monkhai on Apr 6, 2024

@wodin was able to shed some more detail on the background of this issue:

There was an issue with earlier versions of Expo Go after the Expo SDK 50 release, or around the time of the release. If I remember correctly it was preventing clear text connections except to localhost and maybe private IP addresses. Not sure. But it did not allow connections to ngrok tunnels on port 8081. So they changed --tunnel to use https instead. I’m not sure why https might not be working for you

So these appear to be the combined insights:

--tunnel used to use http but now uses https instead (as per @wodin)
This is consistently causing issues for at least ~5 users who have made comments in this issue. Probably many more out there.
Reverting to manually entering the corresponding http URL appears to be a workaround for everyone who has this issue

All things considered, it would be great to have an acknowledgement from the Expo team, in particular for someone who was involved in making the move from http to https, who in turn may be able to shed some light on whether that is still a good idea even with the issue reported here.

jgarplind on Feb 18, 2024