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.

Not the lead of a mobile team. Not one of the mobile developers. The only one.

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 the same desk.

Mine.

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 more than 35K+ 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 not an afterthought, but the main direction of the product. 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.

Not from perfect tutorials. Not from clean demo projects. From production work, deadlines, weird bugs, rejected builds, backend changes, device-specific issues, and users who do not care why something is broken. They 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.

What happens when the app has multiple languages?

What happens when RTL breaks half your layout?

What happens when your app needs to work offline?

What happens when the backend response changes and 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 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.

It is not just about flipping the layout.

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.

No fake examples. No lorem ipsum. Just things I’ve actually had to solve in apps that are already live.

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. Tell me why I’m wrong.

See you in Part 1.