Emanuel Moecklin
3 min readNov 27, 2019

--

I’ve been a native Android Developer for 10 years (started with Donut 1.6). At my current company we focused on Android since 90% of our target users use Android. When faced with the decision to build the iOS client, we decided to go with React Native. The prospect here is to build the iOS version of the app and then replace the Android client at some point by the same version, eliminating a whole team of Android developers (5 engineers).
So far the experience with the React Native client is very good, no performance issues, time to implement features cross platform is at least as short as on native Android, tooling seems to be on par. I personally don’t like JavaScript (some of the RN code is written in TypeScript but I don’t like that one either) and love Kotlin but that’s just me.
Your arguments on why you don’t use cross platform tools seem to be biased. Let me explain why I came to this conclusion:
1. Popularity over time: you seem to imply (alas not explicitly) that RN and or Flutter are temporary hypes and will go the same path as Cordova and Xamarin and that support for native will always be strong while with declining interest it will decline for RN/Flutter. First of all you cannot derive anything from past data. It’s the same as stock market time series analysis. People still believe they can forecast the future by looking at charts of past stock prices. You’re also claiming that “native development has the biggest ecosystem of developers” and that it’s easier to find people with native development experience. From my experience of building two teams from scratch I can tell you that it’s incredibly hard to find iOS and Android developers (I’m Boston based), it’s easier to find backend engineers than mobile engineers (at least good ones). On the other hand it was quite easy to assemble a React Native team. While RN skills here in the US aren’t wide spread, RN has a lot of traction in many other countries because it’s cheaper to build an app in RN and it allows to tap into existing JavaScript skills.
2. Business Values/Vision: again predicting RN’s/Flutter’s future based on your experience with Xamarin isn’t a good argument. Taking that argument, no evolution would be possible, we would all stick to our good old mainframes and program in Cobol because “there is such a low risk that mainframes/Cobol will ever stop being supported”. Putting your bets on the challenger has its risk but putting your bets on the old horse will with certainty lead you down a path of decline.
3. Time savings: I agree with you that the question regarding the most efficient way to implement an application is a very complex one. From my current experience, developing in RN for iOS is probably faster than developing native Android although we haven’t established benchmarks yet (and that is just for one platform, haven’t even considered that we can with some extra effort use the same code for Android too). Talking about reusability, creation a component with RN that can be used on two platforms is definitely drier than creating two reusable components for two platforms. When it comes to time savings, I don’t see any argument for native development, at least for the type of application we develop (business application).
Overall my impression is that your opinion is biased because of your experience with Xamarin. Xamarin definitely supports some of your arguments but most of those arguments are not applicable to RN/Flutter.

--

--