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

[vivek-pai]

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

[JoshuaSkootsky]

I am having the same issue.

[jgarplind]

Same issue here, and I would also add that the suggested workaround in the initial issue (adb reverse) appears to have no effect for me.

In fact, prefixing the command with EXPO_DEBUG=1 makes it evident that the reversing is done automatically as it should be: adb -s xxxxx reverse tcp:8081 tcp:8081)

[MrCox007]

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

[vivek-pai]

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

You are correct, connecting to http:// works for me. The default https:// url does not.

[certtus-pedro]

Same issue here, works fine in SDK 49 tho, after upgrade to SDK50 i'm facing this issue, Have anyone figure this out yet?.
Indeed it works with http://;

[jgarplind]

http:// works fine here too!

That is a decent workaround, but still no back to ideal user experience.

I guess we can assume that the main difference between those of us who still have the issue, and those who had i solved (previous issue) is the fact that we are using the --tunnel option.

[jgarplind]

@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.

[KYZNCODE-Sebastian-Roese]

Same issue here. Works when manually using http instead of https.

[iatanasov37]

Same issue for me as well.

Edit: Works with ‘http’

[evgens83]

I have the same issue

[expo-bot]

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[boxedition]

Well even with the --tunnel i do have a problem with connection to the dev client. After some tests it appears that my issue is ESET Firewall (AV)

[davidcarboni]

I'm having the same issue. I thought I'd add my experience, looks like this tallies with others:

• The same emulator with the same development build works fine when not tunnelled but gives the error if I switch to --tunnel.
• I also noticed the same development build works fine on iOS with --tunnel

[akravecas8]

I have the same issue that --tunnel doesn't work unless I enter it manually and use 'http' rather than 'https'

I'm using:
"expo": "^50.0.13"
"expo-dev-client": "~3.3.10"
"react": "18.2.0"
"react-native": "0.73.5"

[Monkhai]

Same issue here. Cannot connect any device (ios, android, emulator/simulator/real-device) if not connected via tunnel. On android also have to change the address from https to http (exp+someprojectname://expo-development-client/?url=http%3A%2F%2Ffptzbbq-randomname-8081.exp.direct)

[aindong]

this issue still happens until today

[cgitech-demo]

We are still having this issue on 50.0.14. Starting with --tunnel provides an https url that does not work. Changing manually to http works.

[Monkhai]

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.

[jgarplind]

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)?

[Monkhai]

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.

[AhmedMannai10]

I encountered the same issue and found that using yarn android or expo run:android instead of eas build resolved the problem for me.

[brentvatne]

@AhmedMannai10 - please share a minimal reproducible example

[wodin]

@brentvatne I think this thread on Discord explains it:
https://discord.com/channels/695411232856997968/1233149734286266460/1233149734286266460

It seems a dot in the username causes the SSL certificate not to validate

[rmmeans]

^^ 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.

[RohovDmytro]

Same. Not working with a tunnel, works with http. Also, I do not have periods in my user name.

The biggest hint from me is it stops working only in a coworking space and does work on a home network.

[brentvatne]

@RohovDmytro - can you try using ngrok on its own for a simple webserver? something like:

echo "Hello World" > index.html
npx http-server -a localhost

 # note: requires you create a free ngrok account, you can sign in with github
npx ngrok http 8080

you should then see something like this:

Session Status                online
Account                       Brent Vatne (Plan: Free)
Version                       3.9.0
Region                        United States (California) (us-cal-1)
Latency                       31ms
Web Interface                 http://127.0.0.1:4040
Forwarding                    https://d375-50-92-221-25.ngrok-free.app -> http://localhost:8080

try opening the https hrl from your device that is unable to connect over tunnel

[vivek-pai]

Same. Not working with a tunnel, works with http. Also, I do not have periods in my user name.

Yeah, my username has hyphens, no periods.

[brentvatne]

@vivek-pai - please try #27027 (comment) and report back

[kyelewis]

This is interesting, can confirm my username also has a dash (but no period).

What would cause this issue to differ on android vs ios though, are they handling the cert validation differently?

[wodin]

@kyelewis can you try Brent's test?

[ristewar]

I see similar behavior as others. Using npx expo start --tunnel works with HTTP but not HTTPS.

There are no periods in my username, and if I use the HTTPS URL in Chrome it says the *.exp.direct cert is valid, so I don't think the problem I'm facing is just a TLS cert wildcard issue.

I tried Brent's test, I'm able to connect to the http-server just fine via ngrok.

Just for kicks I tried putting the same ngrok in front of npx expo start --localhost and my Expo dev app fails with the same "Unable to load script" I get when trying to connect to npx expo start --tunnel via HTTPS. You can see the GET and HEAD requests received by ngrok below. You can also see below that Expo does output some debug info when the connection is received, but then seems to stall.

$ npx ngrok http 8081
...
Connections                   ttl     opn     rt1     rt5     p50     p90                                                                                                                                                                                       
                              1       0       0.01    0.00    5.41    5.41                                                                                                                                                                                      
                                                                                                                                                                                                                                                                
HTTP Requests                                                                                                                                                                                                                                                   
-------------                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                
GET  /                         200 OK                                                                                                                                                                                                                           
HEAD /                         200 OK   


<< In another window start Expo. I replaced PII with 'X' >>


$ EXPO_DEBUG=1 npx expo start --localhost

...

› Metro waiting on exp+XXXX://expo-development-client/?url=http%3A%2F%2F127.0.0.1%3A8081
› Scan the QR code above to open the project in a development build. Learn more

› Web is waiting on http://localhost:8081

› Using development build
› Press s │ switch to Expo Go

› Press a │ open Android
› Press w │ open web

› Press j │ open debugger
› Press r │ reload app
› Press m │ toggle menu
› Press o │ open project code in your editor

› Press ? │ show all commands

...

  expo:start:project:devices Saving devices: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX +0ms
  expo:start:server:middleware:manifest Resolved entry point: node_modules/expo-router/entry.js (project root: /workspaces/XXXXX/XXXXX) +0ms
  expo:start:server:urlCreator URL: XXXX-XXX-XXX-XX-XXX.ngrok-free.app:8081 +1m
  expo:start:server:urlCreator URL: XXXX-XXX-XXX-XX-XXX.ngrok-free.app:8081 +0ms
  expo:start:server:metro:router Using app as the root directory for Expo Router. +1m
  expo:start:server:urlCreator URL: https://XXXX-XXX-XXX-XX-XXX.ngrok-free.app:8081 +1ms
  expo:start:project:devices Saving devices: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX +247ms
  expo:start:server:middleware:manifest Resolved entry point: node_modules/expo-router/entry.js (project root: /workspaces/XXXXX/XXXXXX) +271ms
  expo:start:server:urlCreator URL: XXXX-XXX-XXX-XX-XXX.ngrok-free.app:8081 +277ms
  expo:start:server:urlCreator URL: XXXX-XXX-XXX-XX-XXX.ngrok-free.app:8081 +0ms
  expo:start:server:metro:router Using app as the root directory for Expo Router. +277ms
  expo:start:server:urlCreator URL: https://XXXX-XXX-XXX-XX-XXX.ngrok-free.app:8081 +1ms

If I start Expo with --tunnel and connect via HTTP the only significant difference I see in debug output is the last line from expo:metro:inspector-proxy:proxy, which is missing in the output above but present below.

$ EXPO_DEBUG=1 npx expo start --tunnel

...

Logs for your project will appear below. Press Ctrl+C to exit.
  expo:start:server:metro:router Using app as the root directory for Expo Router. +1s
  expo:start:server:metro:metroWatchTypeScriptFiles Waiting for TypeScript files to be added to the project... +0ms
  expo:start:project:devices Saving devices: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX +0ms
 +0mso:start:interface:keyPressHandler Key pressed: 
 +280msstart:interface:keyPressHandler Key pressed: 
 +144msstart:interface:keyPressHandler Key pressed: 
  expo:start:server:middleware:manifest Resolved entry point: node_modules/expo-router/entry.js (project root: /workspaces/XXXXX/XXXXX) +0ms
  expo:start:server:urlCreator URL: XXXXXXX-XXXXXXXX-8081.exp.direct +12s
  expo:start:server:urlCreator URL: XXXXXXX-XXXXXXXX-8081.exp.direct +0ms
  expo:start:server:metro:router Using app as the root directory for Expo Router. +11s
  expo:start:server:urlCreator URL: http://XXXXXXX-XXXXXXXX-8081.exp.direct +1ms
  expo:start:project:devices Saving devices: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX +9s
  expo:start:server:middleware:manifest Resolved entry point: node_modules/expo-router/entry.js (project root: /workspaces/XXXXX/XXXXX) +380ms
  expo:start:server:urlCreator URL: XXXXXXX-XXXXXXXX-8081.exp.direct +380ms
  expo:start:server:urlCreator URL: XXXXXXX-XXXXXXXX-8081.exp.direct +0ms
  expo:start:server:metro:router Using app as the root directory for Expo Router. +381ms
  expo:start:server:urlCreator URL: http://XXXXXXX-XXXXXXXX-8081.exp.direct +0ms
  expo:metro:inspector-proxy:proxy Got new connection: name=Pixel 7 - 14 - API 34, app=com.XXXXX.XXXXX, device=XXXXXXXXXXXXXXXXXX +0ms

[CheeseAdd1ct]

This has been causing me an enormous headache, slight relief as a beginner when I saw that this issue was faced by many. Was too scared to try out any weird moves/changes as it might be hard to revert/make things worse.
Thank god there is a solution on here!! 😭

[jgarplind]

@brentvatne I tried doing what you described (if I understand you correctly):

try opening the https hrl from your device that is unable to connect over tunnel

i.e. I set up an ngrok tunnel from my developer machine's localhost and opened a browser tab on my test device opening the ngrok URL.

As reported by @ristewar, this works just fine.

[gabrieldonadel]

Closing this as it was fixed by 416b04b and b911ff6

[jgarplind]

416b04b seems promising. Is that available for test somewhere?

My typical workflow is to run npx expo start --tunnel. npx expo -v returns 0.17.10, and this still does not seem to work.

expo-dev-client is 3.3.11 and npx expo-doctor doesn't prompt for any upgrade.

[wodin]

416b04b seems promising. Is that available for test somewhere?

My typical workflow is to run npx expo start --tunnel. npx expo -v returns 0.17.10, and this still does not seem to work.

expo-dev-client is 3.3.11 and npx expo-doctor doesn't prompt for any upgrade.

Looks like the fix has been released for Expo SDK 51, but as far as I can see it has not yet been released for Expo SDK 50.

[jgarplind]

Upgraded to Expo 51 and it works like it used to now.