Hello World: Why I Build Cross-Platform
How I discovered that one codebase could serve two platforms without sacrificing feel — and why React Native became my default.
The first time I shipped a React Native app to both the App Store and Google Play on the same afternoon, I thought something had gone wrong.
It couldn’t be that simple. Surely the Android version would look wrong, feel sluggish, or break in some inexplicable way the moment a real user touched it. It didn’t. They both worked. And that was the moment React Native stopped being a compromise and started being my default.
How I Got Here
I started in mobile the way most developers do — picking a side. I wrote JavaScript on the web and eventually wanted to build something people could put in their pocket. The conventional wisdom at the time was clear: if you care about quality, go native.
So I learned the platform SDKs. I got comfortable with the tooling, the simulators, the review process. I shipped things. But I kept bumping into the same wall: every feature meant doing the work twice, in two different languages, against two different APIs, with two different bugs.
React Native didn’t promise to eliminate that wall. It promised to make it shorter. And after enough real projects, I’ve found it delivers — especially when you treat it as a JavaScript-first platform that can go native, not a web app that pretends to be native.
The Role of Swift and Kotlin
I still write Swift and Kotlin. When a feature genuinely needs direct platform access — a custom Keychain integration, Android Auto bindings, a performance-critical rendering loop — a native module is the right tool. But that’s the exception, not the rule.
Most apps don’t need to live at the edge of the platform. They need fast lists, smooth gestures, reliable networking, and good typography. React Native handles all of that. The native layer is there when you need it; the point is that you rarely do.
What I Care About
A few things I hold firm on regardless of the stack:
- Performance is a feature. Sixty frames per second, every time. Reanimated on the UI thread, not
setTimeouton the JS thread. - The details matter. Haptics, spring physics, loading states — the polish is what separates a good app from a great one.
- Ship early, iterate fast. You’ll never know what users actually want until your app is in their hands.
What’s Next
This blog is where I’ll share what I’m building, lessons I’m learning, and the occasional deep-dive into whatever React Native API I’ve been spending too much time with.
If you want to build something together, get in touch.