1---
2title: Debugging runtime issues
3description: Learn about different techniques available to debug your Expo project.
4sidebar_title: Runtime issues
5---
6
7import { BoxLink } from '~/ui/components/BoxLink';
8import { Step } from '~/ui/components/Step';
9import { Terminal } from '~/ui/components/Snippet';
10import ImageSpotlight from '~/components/plugins/ImageSpotlight';
11
12Whether you're developing your app locally, sending it out to select beta testers, or launching your app live to the app stores, you'll always find yourself debugging issues. It's useful to split errors into two categories:
13
14- Errors you encounter in the development
15- Errors you (or your users) encounter in production
16
17Let's go through recommended practices when dealing with each of the above situations.
18
19## Development errors
20
21They are common errors that you encounter while developing your app. Delving into them isn't always straightforward. Usually, debugging when running your app with [Expo CLI](/more/expo-cli/) is enough.
22
23One way you can debug these issues is by looking at the [stack trace](/debugging/errors-and-warnings/#stack-traces). However, in some scenarios, looking at the stack trace isn't enough as the error message traced might be a little more cryptic. For such errors, follow the steps below:
24
25- Search for the error message in Google and [Stack Overflow](https://stackoverflow.com/questions), it's likely you're not the first person to ever run into this.
26- **Isolate the code that's throwing the error**. This step is _vital_ in fixing obscure errors. To do this:
27  - Revert to a working version of your code. This may even be a completely blank `npx create-expo-app` project.
28  - Apply your recent changes piece by piece, until it breaks.
29  - If the code you're adding in each "piece" is complex, you may want to simplify what you're doing. For example, if you use a state management library such as Redux, you can try removing that from the equation completely to see if the issue lies in your state management (which is common in React apps).
30  - This should narrow down the possible sources of the error, and provide you with more information to search the internet for others who have had the same problem.
31- Use breakpoints (or `console.log`s) to check and make sure a certain piece of code is being run, or that a variable has a certain value. Using `console.log` for debugging isn't considered the best practice, however, it's fast, easy, and oftentimes provides some illuminating information.
32
33Simplifying code as much as possible to track down the source of error is a great way to debug your app and it gets exponentially easier. That's why many open-source repositories require a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) when you open an issue. It ensures you have isolated the issue and identified exactly where the problem occurs. If your app is too large and complex to do that, try and extract the functionality you're trying to add in a blank `npx create-expo-app` project, and go from there.
34
35### Native debugging
36
37You can perform full native debugging with Android Studio and Xcode by generating source code locally and building from that source.
38
39#### Android Studio
40
41<Step label="1">
42
43Generate the native code for your project by running the following command:
44
45<Terminal cmd={['$ npx expo prebuild -p android']} />
46
47This will add an **android** directory at the root of your project.
48
49</Step>
50
51<Step label="2">
52
53Open the project in Android Studio by running the command:
54
55<Terminal cmd={['$ open -a /Applications/Android Studio.app ./android']} />
56
57</Step>
58
59<Step label="3">
60
61Build the app from Android Studio and connect the debugger. See [Google's documentation](https://developer.android.com/studio/debug#startdebug) for more information.
62
63</Step>
64
65> You can delete the **android** directory when you are done with this process. This ensures that your project remains managed by Expo CLI. Keeping the directory around and manually modifying it outside of `npx expo prebuild` means you'll need to manually upgrade and configure native libraries yourself (which is bare workflow).
66
67#### Xcode
68
69> This is only available for macOS users and requires Xcode to be installed.
70
71<Step label="1">
72
73Generate the native code for your project by running the following command:
74
75<Terminal cmd={['$ npx expo prebuild -p ios']} />
76
77This will add an **ios** directory at the root of your project.
78
79</Step>
80
81<Step label="2">
82
83Open the project in Xcode by running the command which is a shortcut to open the `.xcworkspace` file from your project's **ios** directory in Xcode.
84
85<Terminal cmd={['$ xed ios']} />
86
87</Step>
88
89<Step label="3">
90
91Build the app with <kbd>Cmd ⌘</kbd> + <kbd>r</kbd> or by pressing the play button in the upper left corner of Xcode.
92
93</Step>
94
95<Step label="4">
96
97You can now utilize [**Low-level debugger (LLDB)**](https://developer.apple.com/library/archive/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/Introduction.html) and all of the other [Xcode debugging tools](https://developer.apple.com/documentation/metal/debugging_tools) to examine the native runtime.
98
99</Step>
100
101> You can delete the **ios** directory when you are done with this process. This ensures that your project remains managed by Expo CLI. Keeping the directory around and manually modifying it outside of `npx expo prebuild` means you'll need to manually upgrade and configure native libraries yourself (which is bare workflow).
102
103## Production errors
104
105Errors or bugs in your production app can be much harder to solve, mainly because you have less context around the error (that is, where, how, and why did the error occur?).
106
107**The best first step in addressing a production error is to reproduce it locally.** Once you reproduce an error locally, you can follow the [development debugging process](#development-errors) to isolate and address the root cause.
108
109> **Tip**: Sometimes, running your app in **production mode** locally will show errors that normally wouldn't be thrown. You can run the app locally in production by running `npx expo start --no-dev --minify`.
110> `--no-dev` tells the server not to be run in development mode, and `--minify` is used to minify your code the same way it is for production JavaScript bundles.
111
112### Production app is crashing
113
114It can be a frustrating scenario when a production app crashes. There is very little information to look into when it happens. It's important to reproduce the issue, and even if you can't do that, to find any related crash reports.
115
116Start by reproducing the crash using your production app and then **find an associated crash report**.
117
118#### Crash reports using adb logcat
119
120If your Android app is on Google Play, refer to the crashes section of the [Google Play Console](https://play.google.com/console/about/), or connect your Android device to your computer and run the following command:
121
122<Terminal cmd={['$ adb logcat']} />
123
124The Android Debug Bridge (`adb`) program is part of the Android SDK and allows you to view streaming logs. An alternative to avoid installing Android SDK is to use [WebADB](https://webadb.com/) in Chrome.
125
126#### Crash reports using Console app
127
128If your iOS app is on TestFlight or the App Store, you can use the [Crashes Organizer](https://developer.apple.com/news/?id=nra79npr) in Xcode.
129
130If not, you can use the **Console** app in Xcode by connecting your device to your mac. Follow the steps below on how to access the Console app:
131
132<Step label="1">
133
134Open Xcode app, and then open **Devices and Simulators** window by pressing <kbd>Shift</kbd> + <kbd>Cmd ⌘</kbd> + <kbd>2</kbd>.
135
136</Step>
137
138<Step label="2">
139
140If you've connected a physical device, select it under **Devices**. Otherwise, if you are using a simulator, select it under **Simulators**.
141
142<ImageSpotlight
143  alt="Devices and Simulators window in Xcode."
144  src="/static/images/debugging/devices-simulators.png"
145/>
146
147</Step>
148
149<Step label="3">
150
151Click on **Open Console** button shown in the window to open the console app.
152
153<ImageSpotlight
154  alt="Devices and Simulators window in Xcode."
155  src="/static/images/debugging/open-console.png"
156/>
157
158This will open the console app for you to view logs from your device or simulator.
159
160</Step>
161
162For more information, see Apple's [Diagnosing Issues Using Crash Reports and Device Logs](https://developer.apple.com/documentation/xcode/diagnosing-issues-using-crash-reports-and-device-logs) guide.
163
164### App crashes on certain (older) devices
165
166This might indicate that there is a performance issue. You likely need to run your app through a profiler to get a better idea of what processes are killing the app, and [React Native provides some great documentation for this](https://reactnative.dev/docs/profiling). We also recommend using [React DevTools](https://www.npmjs.com/package/react-devtools) and the included profiler, which makes it super easy to identify performance sinks in your app.
167
168## Stuck?
169
170The Expo community and the React and React Native communities are great resources for help when you get stuck. There's a good chance someone else has run into the same error as you, so make sure to read the documentation, search the [forums](https://forums.expo.dev/), [GitHub issues](https://github.com/expo/expo/issues/), and [Stack Overflow](https://stackoverflow.com/).
171
172## Next step
173
174<BoxLink
175  title="Debugging tools"
176  description="Learn about different tools available to debug runtime issues in your Expo project."
177  href="/debugging/tools"
178/>
179