Hello, I'm the Only Mobile Engineer in the Room

For the past few years, I've been the only mobile engineer at my company. There is no mobile team for me to lead or be part of.

That means every mobile decision eventually comes back to me: how we structure the app, how we connect to the backend, how we deal with store reviews, why something crashes in production, why a screen behaves differently on Android, why an App Store email arrived at 11 PM.

All of it lands on my desk.

It can be stressful. Some days, it really is. But it also changed the way I write code. When you know you are the person who will maintain it, debug it, explain it, and fix it later, you stop trying to be clever. You start caring more about code that is simple, predictable, and easy to return to after six months.

That is the kind of engineering I believe in now.

The numbers, quickly

My name is Ibrahim Fathi. I'm a mobile software engineer from Cairo, and I mostly work with React Native CLI.

So far, I've shipped 14+ production apps across iOS and Android, pushed 100+ store releases, and worked on apps with 50K+ downloads.

Some of that work has been a little outside the usual React Native path.

I built a live-streaming platform for equestrian events running on tvOS and Android TV. I worked on Arabic-first apps where RTL was the main direction of the product from the start. I also worked on a GPS workforce-tracking app using React Native's New Architecture, with offline behavior that has to keep working even when workers are in places with weak or no signal.

If you want more details, the case studies go deeper into the projects.

Why I'm writing this blog

Most of what I know about React Native, I learned by shipping real apps.

It didn't come from perfect tutorials or clean demo projects. It came from production work, deadlines, weird bugs, rejected builds, backend changes, device-specific issues, and users who do not care why something is broken and just need it to work.

A lot of React Native content online is useful when you are starting out, but it usually stops too early. It teaches you how to build a screen, use a hook, or call an API. But the hard parts often come later.

Those hard parts look like an app that has to support multiple languages, RTL breaking half your layout, an app that needs to work offline, or a backend response that changes when you are the only mobile engineer responsible for the release. Those are the things I want to write about.

What's coming first

The first series will be about one of the topics that has cost me the most time in my career: RTL and multi-language architecture in React Native.

I've worked on apps used by Arabic speakers, and supporting them took a lot more than flipping the layout. I've had to deal with the real problems that come with right-to-left layouts, translations, language switching, mixed-direction content, icons, spacing, navigation, and late-stage language additions.

In this series, I'll write about why RTL is still painful in React Native, the patterns I use to make language support easier to maintain, and how I try to make AI coding agents produce RTL-safe code instead of generating layouts that only work in English.

Every example will be something I've actually had to solve in an app that is already live, so you won't find made-up examples or lorem ipsum here.

If that sounds useful, you can subscribe through the RSS feed, or follow the posts on LinkedIn.

And if you disagree with something I write, that's fine too. The comments are open, so tell me why I'm wrong.

See you in Part 1.