Fix: Network Icons Missing In AppKit React Native

by Sebastian Müller 50 views

Hey guys,

We've got a bug report here about network icons not showing up in the list, and we're gonna dive deep into it. This issue is filed under the reown-com,appkit-react-native discussion category, so let's get to the nitty-gritty details and see if we can figure out what's going on.

Description

The core issue reported is that the network icons are not displaying correctly within the list. This can be a real pain for users because those icons provide a quick visual reference for the different networks they might be interacting with. Without them, it's a bit like trying to find your favorite coffee mug in a cupboard full of plain white ones – doable, but definitely not ideal.

When these network icons go missing, it can seriously impact the user experience. Imagine you're quickly switching between different blockchain networks, and you rely on those little logos to make sure you're on the right one. If they're not there, you might accidentally make a transaction on the wrong network, which can lead to all sorts of headaches. We're talking about potential loss of funds, confusion, and a generally frustrating experience. So, getting these icons back in action is super important for ensuring our users have a smooth and intuitive experience.

From a development perspective, these kinds of visual bugs can sometimes be tricky to nail down. There could be a variety of reasons why the icons aren't showing up – anything from issues with asset loading, incorrect paths, problems with the component rendering the icons, or even network-related hiccups. That's why it's crucial to gather as much information as possible, which is exactly what we're doing here. We'll be looking at the SDK version, environment details, reproduction steps, and any available code snippets or screenshots to get a complete picture of the problem. By digging deep into these details, we can narrow down the potential causes and come up with an effective solution.

AppKit SDK Version

The reported AppKit SDK version being used is "@reown/appkit-wagmi-react-native": "^1.2.6". This is a key piece of information because it tells us exactly which version of the library the user is running. Knowing the SDK version helps us to check for any known issues or bugs that might be specific to that version. For example, there might be a regression that was introduced in 1.2.6, or perhaps there's a compatibility issue with certain dependencies or environments.

Keeping track of the SDK version is crucial for a few reasons. First off, it helps us to replicate the issue in our own development environment. If we can recreate the bug locally, it becomes much easier to debug and fix. Secondly, it allows us to check the release notes and changelogs for that specific version. Sometimes, a bug might already be known and addressed in a newer version, or there might be a workaround that we can suggest to the user. Finally, knowing the SDK version helps us to understand the context of the issue. It's like having a map that shows us exactly where the problem is located, making it much easier to navigate and find the solution.

In this case, knowing that the user is on version 1.2.6 is our starting point. We can now compare this version against our bug tracking system and see if anyone else has reported similar issues. We can also check if there have been any recent changes or updates to the way network icons are handled in the SDK. This kind of information can be incredibly valuable in pointing us towards the root cause of the problem and helping us to develop a fix.

Output of npx react-native info

The output of npx react-native info provides a wealth of information about the user's development environment. Let's break it down to see what we can glean from each section:

System

  • OS: macOS 15.5: This indicates the user is running on a macOS system, specifically version 15.5. This is important because certain issues might be specific to certain operating systems. For instance, there could be compatibility problems with certain native libraries or system configurations that only occur on macOS.
  • CPU: (12) arm64 Apple M4 Pro: This tells us the user has an Apple M4 Pro chip, which is an ARM-based processor. This is significant because ARM-based architectures can sometimes behave differently than traditional x86 architectures. We need to ensure that our code is optimized and tested for ARM-based devices, especially since Apple is increasingly using these chips in their products.
  • Memory: 145.42 MB / 24.00 GB: This shows the current memory usage and total memory available. While 24 GB of RAM is plenty, it's still good to keep an eye on memory usage, especially when dealing with complex applications. If the app is running close to its memory limits, it could lead to performance issues or even crashes.
  • Shell: version: "5.9", path: /bin/zsh: The user is using Zsh as their shell, which is the default on newer macOS versions. This is more of a general piece of information, but it can be useful in understanding the user's setup and potential command-line environment.

Binaries

  • Node: version: 22.13.0, path: ~/.nvm/versions/node/v22.13.0/bin/node: The user is running Node.js version 22.13.0. This is a crucial piece of information because React Native projects rely heavily on Node.js. Different Node.js versions can have different behaviors and compatibility with various libraries and tools. We need to ensure that the Node.js version is compatible with our SDK and the user's project dependencies.
  • Yarn: Not Found: The user doesn't have Yarn installed, which means they're likely using npm as their package manager. This is good to know because we might need to adjust our instructions or troubleshooting steps depending on the package manager being used.
  • npm: version: 11.3.0, path: ~/.nvm/versions/node/v22.13.0/bin/npm: The user is running npm version 11.3.0. Just like with Node.js, the npm version can impact how dependencies are installed and managed. We need to make sure that our SDK is compatible with the user's npm version.
  • Watchman: version: 2025.06.23.00, path: /opt/homebrew/bin/watchman: Watchman is a file watching service used by React Native to detect changes in the file system and trigger rebuilds. The version information can be helpful if we suspect any issues with file watching or caching.

Managers

  • CocoaPods: version: 1.16.2, path: /opt/homebrew/bin/pod: CocoaPods is a dependency manager for iOS projects. This indicates that the user is developing for iOS, and we need to consider any potential issues related to CocoaPods and native dependencies.

SDKs

  • iOS SDK: This section provides detailed information about the iOS SDKs installed on the user's system. It lists the platforms and versions available, including DriverKit, iOS, macOS, tvOS, visionOS, and watchOS. This is crucial for ensuring that the user has the necessary SDKs installed to build and run the app on different Apple devices.
  • Android SDK: Not Found: The user doesn't have the Android SDK configured, which suggests they're primarily focused on iOS development.

IDEs

  • Android Studio: 2024.2 AI-242.23726.103.2422.13103373: The user has Android Studio installed, although the Android SDK is not configured. This might indicate that they're planning to develop for Android in the future or that they have it installed for other purposes.
  • Xcode: version: 16.2/16C5032a, path: /usr/bin/xcodebuild: The user is running Xcode version 16.2, which is the primary IDE for iOS development. This is a critical piece of information because we need to ensure that our SDK is compatible with the user's Xcode version.

Languages

  • Java: version: 17.0.14, path: /usr/bin/javac: Java is used for Android development, but since the Android SDK is not configured, this might be a system-level Java installation.
  • Ruby: version: 2.6.10, path: /usr/bin/ruby: Ruby is used by CocoaPods, so this is related to iOS development. The version information can be helpful if we encounter any issues with CocoaPods.

npmPackages

  • "@react-native-community/cli": Not Found, react: Not Found, react-native: Not Found, react-native-macos: Not Found: This is concerning because it indicates that the React Native CLI and core React Native packages are not found in the user's project. This could be a sign of a misconfigured project or installation issue. We need to investigate this further to ensure that the project is set up correctly.

npmGlobalPackages

  • "react-native": Not Found: Similar to the previous section, this indicates that React Native is not installed globally. This is not necessarily an issue, but it's good to be aware of.

Android

  • hermesEnabled: true, newArchEnabled: true: This shows that Hermes (a JavaScript engine optimized for React Native) and the New Architecture are enabled for Android. However, since the Android SDK is not configured, these settings might not be relevant in this case.

iOS

  • hermesEnabled: Not found, newArchEnabled: Not found: The status of Hermes and the New Architecture for iOS is not found. This could be due to various reasons, such as an incomplete setup or project configuration. We might need to guide the user on how to enable these features if necessary.

Additional Information

  • The output also includes information about available React Native updates. It suggests upgrading from version 0.79.5 to 0.80.2. While this might not be directly related to the issue, it's a good practice to keep React Native up to date to benefit from bug fixes and performance improvements.

Overall, the npx react-native info output provides a comprehensive snapshot of the user's development environment. The most concerning part is the missing React Native CLI and core packages, which could be a significant factor in the issue. We need to address this first to ensure that the project is set up correctly before diving deeper into the network icon problem.

Expo Version (if applies)

The Expo version being used is Expo 53.0.20. Expo is a framework that simplifies React Native development, providing a set of tools and services that streamline the development process. Knowing the Expo version is crucial because different versions can have different behaviors and compatibility with various libraries and APIs.

When we're dealing with Expo projects, the Expo SDK version is a key factor to consider. Each Expo SDK version comes with a specific set of features, bug fixes, and updates. If there's a bug in a particular version, it might be fixed in a later version. So, knowing the Expo version helps us to determine if the issue might be related to a known bug in that specific SDK version.

Additionally, Expo handles a lot of the native dependencies and build configurations for us. This means that some issues might be specific to Expo's environment and how it interacts with native code. For example, there might be issues with asset loading, image handling, or network requests that are specific to Expo. By knowing the Expo version, we can narrow down the potential causes of the problem and focus our troubleshooting efforts on Expo-related aspects.

In this case, the user is on Expo 53.0.20. We can check the Expo documentation and release notes for this version to see if there are any known issues related to asset loading or network icons. We can also compare this version against the latest Expo SDK version to see if upgrading might resolve the problem. This kind of information can be incredibly valuable in helping us to diagnose and fix the issue quickly and efficiently.

Steps to Reproduce

To reproduce the issue, the user needs to open the widget and click on the current network logo. These steps are super helpful because they give us a clear and concise way to recreate the bug in our own environment. Being able to reproduce the issue is often the first and most important step in debugging because it allows us to observe the problem firsthand and try out different solutions.

When we have a set of steps to follow, we can systematically go through them and see exactly when and where the issue occurs. This can help us to narrow down the potential causes of the bug. For example, if the icons disappear immediately after clicking on the network logo, it might suggest a problem with the component that handles the network selection. On the other hand, if the icons never load in the first place, it might indicate an issue with asset loading or initial component rendering.

The more detailed and specific the steps to reproduce are, the better. For instance, if the issue only occurs on a specific device or operating system, or if it only happens after performing a certain sequence of actions, it's crucial to include that information in the steps. This can help us to identify patterns and correlations that might not be immediately obvious. In this case, knowing that the user needs to click on the network logo is a good starting point, but we might need to ask for more details if we're unable to reproduce the issue ourselves.

Snack, Code Example, Screenshot, or Link to a Repository

The user has provided a screen recording which is super helpful. A screen recording can often give us a much clearer picture of the issue than a written description alone. We can see exactly what the user is seeing, how the app is behaving, and any error messages or visual glitches that might be present. It's like having a window into the user's screen, allowing us to experience the problem firsthand.

When we watch the screen recording, we can pay close attention to the steps the user is taking, the timing of events, and any specific UI elements that are involved. This can help us to identify potential triggers or patterns that might be causing the issue. For example, we might notice that the icons disappear after a certain animation or transition, or that they're not loading correctly in a particular view or screen. These kinds of visual cues can be incredibly valuable in guiding our debugging efforts.

In addition to the screen recording, the user has also provided a code snippet of their network configuration. This code snippet is fantastic because it shows us exactly how the user has configured their network chains. We can see which chains they're using, how they're being imported, and any custom settings or configurations that might be in place. This is crucial information because it allows us to check for any potential issues with the network configuration itself.

Let's take a closer look at the code snippet. The user is importing various chains from different libraries, such as mainnet, bsc, arbitrum, and so on. They're then creating a chains array that includes all of these imported chain configurations. This array is used to configure wagmiConfig using defaultWagmiConfig, along with a projectId and metadata. This setup looks pretty standard, but we still need to examine it carefully for any potential issues.

For example, we might want to check if all of the imported chain configurations are valid and correctly formatted. We might also want to verify that the projectId and metadata are set up correctly. If there are any typos or misconfigurations in this code, it could potentially lead to issues with network icon loading or other network-related functionality.

By combining the information from the screen recording and the code snippet, we can start to form a more complete picture of the problem. We can see how the issue manifests visually, and we can examine the code that's responsible for rendering the network icons. This is a powerful combination that can help us to narrow down the potential causes of the bug and come up with an effective solution.

Okay, so we've got a pretty good handle on this network icon issue now. We know the icons aren't showing up in the list, the user is on AppKit SDK version 1.2.6, and they're using Expo 53.0.20. We've also seen the output of npx react-native info, which gives us a ton of details about their environment. Plus, we've got a screen recording and a code snippet showing their network configuration. That's a lot to work with, guys!

Digging Deeper: Potential Causes and Solutions

Now, let's put on our detective hats and start brainstorming some potential causes for this issue. Based on the information we have, here are a few possibilities:

1. Asset Loading Issues

One of the most common reasons for missing icons is problems with asset loading. In React Native and Expo projects, icons are typically loaded as image assets. If these assets aren't loaded correctly, they won't be displayed. This could be due to a few different factors:

  • Incorrect Paths: The paths to the icon files might be incorrect. This could be a simple typo in the code, or it could be a more complex issue with how the assets are being referenced within the project.
  • Missing Assets: The icon files might not be included in the project at all. This could happen if the files were accidentally deleted, or if they weren't properly included when the project was set up.
  • Bundling Issues: There might be a problem with how the assets are being bundled when the app is built. This can happen if the asset bundling configuration is incorrect, or if there are issues with the build tools themselves.

To troubleshoot asset loading issues, we can try a few different things. First, we can double-check the paths to the icon files to make sure they're correct. We can also verify that the icon files are actually present in the project's asset directory. If we suspect a bundling issue, we can try clearing the Metro bundler cache and rebuilding the app.

2. Component Rendering Problems

Another potential cause is problems with the component that's responsible for rendering the network icons. If this component isn't working correctly, it might not be able to display the icons even if the assets are loaded properly. This could be due to:

  • Conditional Rendering: The component might have conditional rendering logic that's preventing the icons from being displayed under certain circumstances. For example, the icons might only be displayed if a certain condition is met, and that condition isn't being met in this case.
  • Styling Issues: There might be styling issues that are making the icons invisible. For example, the icons might have a display: none style, or they might be positioned off-screen.
  • Component Errors: The component itself might be throwing an error, which is preventing it from rendering correctly. This could be due to a bug in the component's code, or it could be due to a dependency issue.

To troubleshoot component rendering problems, we can start by inspecting the component's code to see if there are any obvious issues. We can also use React Native's debugging tools to inspect the component's props and state, and to see if any errors are being thrown. If we suspect a styling issue, we can use the React Native Inspector to examine the component's styles and see if anything looks out of place.

3. Network Configuration Issues

As we saw in the code snippet, the user has a specific network configuration that defines the different chains that the app supports. If there's an issue with this configuration, it could potentially lead to problems with the network icons. This could be due to:

  • Missing Icons: The network configuration might not include icon URLs or paths for all of the chains. If a chain doesn't have an associated icon, it won't be displayed.
  • Incorrect URLs: The URLs to the icons might be incorrect or broken. If the URLs are pointing to invalid resources, the icons won't be loaded.
  • Configuration Errors: There might be errors in the way the network configuration is set up. For example, there might be typos in the chain IDs or other configuration values.

To troubleshoot network configuration issues, we can start by carefully reviewing the code snippet to make sure that everything is set up correctly. We can also check the URLs to the icons to make sure they're valid and accessible. If we suspect a configuration error, we can try simplifying the configuration to see if that resolves the issue.

4. SDK or Expo Issues

Finally, it's possible that the issue is due to a bug in the AppKit SDK or in Expo itself. While this is less likely than the other causes, it's still a possibility that we need to consider. This could be due to:

  • Known Bugs: There might be a known bug in the SDK or Expo that's causing the icons to not display correctly. We can check the SDK and Expo release notes and issue trackers to see if anyone else has reported a similar issue.
  • Compatibility Issues: There might be a compatibility issue between the SDK, Expo, and the user's environment. For example, there might be a conflict between the SDK and a specific version of React Native, or there might be an issue with Expo's native dependencies.
  • Regression: A recent update to the SDK or Expo might have introduced a bug that's causing the issue. We can try downgrading to a previous version to see if that resolves the problem.

To troubleshoot SDK or Expo issues, we can start by checking the SDK and Expo documentation and issue trackers. We can also try upgrading or downgrading the SDK or Expo version to see if that makes a difference. If we suspect a compatibility issue, we can try changing the versions of other dependencies in the project.

Time to Investigate!

Okay, guys, we've got a solid list of potential causes and solutions here. Now it's time to roll up our sleeves and start investigating! I think the next step is to try reproducing the issue in our own environment. We can use the steps to reproduce that the user provided, and we can also use the code snippet to set up a similar network configuration. Once we can reproduce the issue, we can start digging deeper and try out some of the solutions we've discussed.

I'm feeling pretty confident that we can get those network icons back in action. Let's keep each other updated on our progress, and let's work together to find the root cause of this bug. We got this! 💪