When I first caught wind of React Native, I thought of it as nothing more than a way for web developers to dip their feet into native mobile apps. The premise that JavaScript developers could write an iPhone app in JavaScript was definitely something that I thought was really cool, but I quickly shrugged off the idea of using it myself. After all, I had already been doing native iOS development as a hobby for many years, and professionally with Chalk + Chisel (formally Bolster) for almost two years at that point.
I had already made dozens of iOS apps — good apps that I was proud of. Apps built in Xcode and written in Objective-C, because that’s the way it’s always been. That’s what Apple gave us to make iOS apps, so that’s what I and every other developer used. Then, two years ago when Apple released the Swift programming language, I didn’t hesitate to try it out.
It was still in Xcode, and it was still (obviously) Apple-approved for developing iOS apps, so I dove right in and picked it up pretty — ahem — swiftly. I was content in my Apple ecosystem bubble. React Native seemed like a fun little experiment, but in my mind any real native app would still need to be written the real native way. It seemed like a waste of time for me to not only learn JavaScript (I had no experience), but an entirely new way of building apps when I was already beginning to master building them the “real” way.
Fast-forward a couple of months, and I’m confident enough to say I may never write an iOS app in Objective-C or Swift again.
We received a new mobile app project and I reviewed the requirements and designs. Just as I was about to click that beautiful blue Xcode icon to start a new project, our Interactive Director, Adam, walks over and says, “let’s do this one in React Native”.
He explained that part of our contract for this project was to have a clear path going forward to make this app available for Android as well . And although React Native was not yet available for Android, we knew Facebook was actively working on it. Theoretically, if we built the app in React Native for iOS, many parts of it would “just work” on Android by the time it was released.
Well, I wasn’t happy. I felt as if I was at the peak of my iOS development ability and was being asked to throw it all away. I doubted my own abilities to deliver a quality product on time given the inevitable learning curve. But even more than that, I doubted React Native in itself being capable of producing a quality product. Looking back, I don’t even think that doubt was unjustified. At the time, React Native had just come out as a beta. The documentation was lacking, the amount of open sourced React Native libraries and components was minuscule, and example code or Stack Overflow posts for reference were almost nonexistent.
I begrudgingly gave it a shot. But going in with my closed-mind attitude only did more harm. My first hurdle was learning Flexbox, React Native’s way of doing UI layout. Coming from the land of interface builder, laying out UI completely in code frustrated me beyond belief. I struggled to build even the most simple of views.
But it wasn’t just UI — everything was different. That was the biggest point of contention for me.
Every time I got stuck or didn’t understand something, I would tell myself “I could do this in 5 seconds in Objective-C”. Every time I would discover a bug in React Native (and there were a good number), I would think, “this bug doesn’t exist in Objective-C, why am I fighting with it?”
For a solid two weeks I was miserable at work. I had gone from feeling like an expert iOS developer to feeling like I’d never written a line of code in my life. It was defeating, until I took a weekend to clear my head. I took a step back and recognized that Adam had done a lot of research on React Native. I had to trust him as our Interactive Director to not be leading me down a bad path. I vowed to go into work Monday, put my head down, pretend Objective-C and Swift don’t even exist, and figure this thing out.
This content was originally published here.