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