Over the years, our Slack community has been home to some fantastic discussions about the evolution of our industry, of technology, best practices, methodology and more. We recently dropped an intentionally provocative phrase into the channel to spark the latest round of smarts, snark and wisdom (not to mention a strong meme game).
The result was a lively discussion with lots of interesting twists and turns, but we thought one particular topic deserved a deeper dive. Our seed phrase was “You’re a failed CTO if ______” and one of our professional freelance mobile devs chimed in with this one:
“You’re a failed CTO if you think React Native is going to save you time and money in the long run.”
Wow, ok … let’s hear it!
The following was contributed by Christina Moulton, who graciously volunteered to craft some core principles and wise guidance on the subject ...
React Native Doesn't Save You Time & Money In The Long Run
React Native is a reasonable technology choice when you’re building mobile apps for multiple platforms, but it generally won’t be cheaper or easier in the end.
What’s the trade-off?
Web-based frameworks like React Native are great for quickly launching apps on multiple platforms, but the initial development speed comes at the expense of tight mobile integration and, often, user experience quality. You’ll eventually expend more effort making it look and act great, adding features and dealing with performance issues.
True native apps are generally much more expensive out the door (or have fewer features for the same budget) but typically win on user experience and native integration. After launch, it’s also easier to improve touch-oriented user experiences, deal with performance issues, and take advantage of new hardware features.
Whether RN is really faster to ship v1.0 greatly depends on the UX and functionality required. If you’re building a slick, gorgeous app with a variety of user experience elements then you may hit the trade-off point where it’s better to work with native SDKs before you get to v1.0.
In the long run, unless you’re shipping a fairly minimal app and not improving it over time, expect similar total time and cost.
How do I choose what to start with?
You should start with RN if:
Good enough is good enough. If your users just need something that lets them use your product now, then go with RN
Your feature set doesn’t require, or improve with, native integration
You have web developers who are capable of learning the RN framework (and keeping up with regular changes). And you have designers focused on delivering solid mobile experiences who are familiar with iOS and Android standards
You should start with native if:
Your brand is very quality/experience oriented
You’re in a position to launch for a single platform and later expand to other platforms. For many brands, initially launching and iterating a single app on iOS or Android is a valid strategy.
You strongly expect the app to continue development and be an important item for your customers.
You prefer to rely on the more mature and stable native mobile SDKs provided by Apple and Google.
What three variables should I consider when making my choice?
Time to market
Polish / UX expectations of market
On time to market: React Native will usually let you release apps on iOS and Android faster than building native apps for each platform. If your users have very high expectations of the performance or user experience of the app, then RN will probably slow you down after the initial launch (or possibly stop you from easily reaching a good enough state to launch). React Native is particularly good for a few specific UX designs like news feeds but you’ll need to handle platform specific differences or users will find your app jarring and unintuitive. It’s possible to build native-like experiences in RN but because it’s based on web technologies, but it’s harder to maintain velocity during more custom front-end development.
On Polish & Performance: For UX, performance, and access to hardware capabilities, native apps are usually the better choice. Web technologies and native mobile SDKs mature differently because they’re based on different approaches. Web technologies are intended to be good for everyone so new capabilities are added more slowly, especially if it means leaving behind less capable devices. Native mobile SDKs can more easily add features that are more tightly dependent on hardware. In most cases, web technologies will eventually catch up but won’t always provide exactly the same full functionality since they can’t make the assumptions about the hardware they’re running on.
On app complexity: As web and native technologies advance, there’s always a segment of functionality only available in native mobile SDKs. Sometimes you just need to work closer to the hardware with more explicit assumptions. That segment evolves over time but it always exists.
When choosing the technologies for your mobile apps, it pays to look beyond your initial launch goals and consider the long term business value that you’re investing in.
Christina Moulton is a freelance iOS developer and the author of iOS Apps with REST APIs. She writes tutorials for iOS developers at GrokSwift.com.