From Web to Mobile: My React Native Dedication Week

August 18, 20252 min readby Eric Kweyunga
React NativeMobile DevelopmentExpo

For the past few years, I have been primarily building web applications. React, Next.js, and browser-based workflows were my comfort zone. This week, however, I made a deliberate shift: I committed myself fully to the mobile side of a project using React Native.

At first, the transition felt natural. React Native still uses components, state, and props the fundamentals were familiar. But very quickly, I realized that mobile development introduces challenges that do not exist on the web.

The Shift in Development

On the web, I rarely had to think about device notifications, complex UI gestures, or native navigation stacks. In React Native, these became unavoidable:

  • Expo Notifications introduced new workflows for registering devices, handling tokens, and managing permissions.
  • Bottom Sheets (using Gorhom) added a new layer of interaction design, very different from the modals I was used to on the web.
  • Stack Navigation and file-based navigation in React Native required a different mindset than routing in Next.js.

These were expected challenges. I anticipated they would take most of my time. But the real bottleneck came from something much more fundamental: the keyboard.

The Bottleneck: KeyboardAvoidingView

The keyboard is invisible on the web. Browsers handle it, and inputs rarely break layouts. On mobile, however, the keyboard slides into view and often covers what matters most: the input field or the submit button.

React Native provides KeyboardAvoidingView to help with this by shifting the UI when the keyboard appears. In theory, it should solve the problem. In practice, it became the biggest obstacle of my week.

  • On iOS and Android, the behavior was inconsistent.
  • With different behavior props (padding, position, height, and the undefined behaviour), the layout shifted too much or too little.
  • Inside bottom sheets or stack screens, the shifting became unpredictable.

I spent hours testing different configurations, swapping in KeyboardAwareScrollView, and running the app on real devices to understand the differences. Each fix solved one scenario but introduced another issue.

Lessons From the Shift

This experience made one thing clear: moving from web to mobile is not just about learning new APIs, it is about solving problems that do not exist in the browser.

  • Building native UIs, not just building anyhow.
  • Focusing on performance, application size and many more optimization issues.
  • Keyboard handling is never trivial on mobile.
  • There is no universal fix—different platforms and layouts require different solutions.
  • Real devices are essential for testing; emulators do not always reflect the true behavior.

Closing Thoughts

My dedication week was not just about building features, but about confronting the realities of mobile development. I expected notifications and navigation to be my biggest challenges, but instead, I spent most of my energy solving the keyboard shift problem.

The lesson is simple: in mobile development, the smallest details can become the hardest challenges. And it is those details that make an app truly usable.