I have a working Expo application that was originally built on Expo 51. I recently updated the codebase to Expo 52 a couple of weeks ago and everything has seemed okay with the dev server.
However, when bringing a friend on to help with my codebase, we found that the QR code was showing a “No usable data found” message in the Camera app on iOS when scanned. I tried scanning the QR code on my end and found that it was also not working for me.
Since the tunnel had otherwise been working for me, I hadn’t been using the QR code (the app was already linked in Expo Go). As a result, I didn’t notice when this issue started happening. I do use a VPN, but this issue happens regardless of whether or not the VPN is enabled – I’ve tested multiple times in both conditions.
This is not a matter of not having Expo Go installed. I have Expo Go installed and, because I’ve already used my application on my current installation of Expo Go, I actually am able to connect to the dev server and make live changes. The tunnel still works; scanning the QR code does not.
Does anyone know what may be going on here?
npx expo-env-info output:
expo-env-info 1.2.1 environment info:
System:
OS: macOS 15.0.1
Shell: 5.9 - /bin/zsh
Binaries:
Node: 18.20.4 - ~/.nvm/versions/node/v18.20.4/bin/node
Yarn: 3.6.4 - ~/.nvm/versions/node/v18.20.4/bin/yarn
npm: 10.7.0 - ~/.nvm/versions/node/v18.20.4/bin/npm
Managers:
CocoaPods: 1.15.2 - /opt/homebrew/bin/pod
IDEs:
Xcode: /undefined - /usr/bin/xcodebuild
npmPackages:
expo: ~52.0.7 => 52.0.7
expo-router: ~4.0.6 => 4.0.6
react: 18.3.1 => 18.3.1
react-dom: 18.3.1 => 18.3.1
react-native: 0.76.2 => 0.76.2
react-native-web: ~0.19.13 => 0.19.13
Expo Workflow: managed
NOTE: I’ve tried adding this as an issue to Expo’s repo, but they require a sample codebase with an easily-reproducible example of the bug. I have not been able to do that, and this codebase is intended to remain private.
EDIT 1
I found a post that seems related to this issue, but a contributor described it as “Expected behavior”, which seems unlikely to me. Nothing has changed about my setup other than updating to Expo 52 and, again, the tunnel still works. It’s only a matter of the QR code not being formatted correctly (as far as I can tell).
Relevant post:
https://github.com/expo/expo/issues/19150#issuecomment-1699648692
2
First and foremost, stop using Expo Go for production applications as soon as possible. It’s not intended to be used for production applications – even for development purposes, unfortunately.
The reason for the QR error message is because the encoded URI is not usable by your device. It means there is no application it can target with the specified URI.
I now understand this is expected behavior.
If you started a new application using Expo’s “Getting Started” guide, it walks you through the process of setting up an application that does not leverage expo-dev-client. As a result, when you run expo start for this project, it will always start in --go mode.
Additionally, because expo-dev-client is not installed in this scenario, scanning the QR code will always link the user straight to Expo Go (instead of having to go through a prompt in the device’s browser).
For a project such as this, if you install expo-dev-client, expo start will automatically use the --dev-client flag, unless you specify otherwise. This is why you’ll get the QR error of “No usable data found”; when expo-dev-client is installed the default behavior of expo start is NOT to use Expo Go.
This was the issue in my case; I installed expo-dev-client since I had read documentation that it was required, but I did not realize it would alter how the QR code was linked – I had assumed Expo Go was the de-facto development environment.
- In short, Expo Go is not as useful as I was originally thinking it was per their recommended use cases (it’s not really a development tool, but rather a sandbox application that’s not intended for much beyond experimentation)
expo-dev-client
According to the Expo team, when expo-dev-client is installed, it alters how the expo start command behaves. This is intentional. Using expo-dev-client appears to be the only officially-supported way of developing a production application using Expo.
Refer to the linked comment for more information on how expo-dev-client alters the behavior.