First Week Working on a React Native Project

Getting through the setup

The worst part is setting up the project. Downloading Xcode and getting the simulator running took me an entire day. Of course, I could have done some of that earlier, but I was running an older version of iOS that wasn’t compatible with Xcode, so I had to update it. On top of that, my laptop didn’t have enough storage, so I had to delete a lot of things first. I chose to run the app through the simulator instead of on my actual phone. I couldn’t get it working on the phone because there was too much setup involved, and since the simulator started working first, I gave up on using a physical device.

You also need an Apple Developer account and you need to configure it in Xcode. Naturally, nothing worked on the first try, so most of the setup process turned into asking Claude for help, resetting the simulator, and trying random fixes. In the end, a colleague helped me get things working during a Slack huddle.

What felt familiar

The React Native project itself is pretty similar to a Next.js project, since it's built on top of React. As for writing the actual logic, it’s basically the same React I’m already used to. It uses a similar folder-based routing system, so creating new pages wasn’t a problem. Reading the existing code was easy and understandable.

Writing styles in the React Native project was smooth because it used NativeWind, which lets you use Tailwind-style classes that are translated into React Native styles. On top of that, the UI is built using React Native building blocks, such as View, which is basically a div, and Pressable, which represents a button.

What was new

One thing that surprised me was that every “full-screen modal” is actually treated as a route. For example, if we have a full-screen form, we might have a route likeapp/form/index.tsx. Then if the form contains something like a dropdown that also opens full-screen, that becomes another route such as app/form/companySelect/index.tsx. That’s one of the things that isn’t typically done in web projects, so it caught me off guard.

Another really nice thing is React Native’s built-in components like SafeAreaView, which automatically adjust the layout so content doesn’t overlap with the notch, status bar, and other device-specific areas. When developing responsive websites for mobile browsers, we usually handle those edge cases manually ourselves.

Thinking in mobile

Mobile development also comes with a lot of edge cases I had never really thought about before. For example, when a user taps a notification, the app should open correctly on the phone, but then you have to handle three separate scenarios: when the app is completely closed, when the app is already running in the background, and when the user is already inside the app and the notification arrives at that exact moment.

Another case I had to handle was when users clicked a link on a website that is supposed to open the mobile app. For example, if someone is browsing a product page in a browser and taps “Open in app,” the system needs to correctly detect whether the app is installed, open it to the exact same product screen using a deep link, and if the app isn’t installed, it should gracefully redirect the user to either the App Store or a web version, while still keeping track of what they originally wanted to open so they don’t lose that context.

It was interesting becoming more aware of these behaviors and thinking more deeply about how people actually use their phones and everything that needs to be covered.

Building with AI, learning beyond it

After setting up the project and spending a few days getting familiar with it, I found it really fun to work on tasks and testing. It really broke the monotony of my work, which had become too dependent on AI tools.

One thing I really noticed is the difference in how we approach projects now compared to before AI. In the past, I would definitely have watched some YouTube tutorials about React Native and how to set up Xcode, but this time I did everything through Claude Code and kept asking it for explanations.

Since I didn’t set everything up manually or follow tutorials step by step, I feel like my understanding of how React Native, navigation, and native build processes fit together didn’t fully come together at first. It felt like I was more productive in the short term, but I’m not sure how much of that knowledge will stick without revisiting the implementation later on my own. That’s exactly why I consciously stopped a few times, took a piece of paper, and sketched out the flow without just accepting what the AI had written.

I know I need to keep doing that if I really want to learn and properly understand what’s happening in the project; otherwise, things will become messy, and I don’t want to be someone who doesn’t have control over their own work.

I feel like switching to this project has made me more aware of the importance of slowing down, studying the code, and taking the time to understand things properly, instead of just relying on the AI wave.