From: https://engineering.fb.com/data-infrastructure/messenger/
> We accomplished this by using the native OS wherever possible
Does this mean this application does not use React Native?
> We accomplished this by using the native OS wherever possible
Does this mean this application does not use React Native?
That doesn't mean React Native is not a good fit for any kind of application - for many kinds of apps, start up time and app size are a much smaller issue - but seems Facebook made the right decision for an app like Messenger which primarily needs to start fast and drain as few resources as possible.
I guess many native developers feel negatively towards it because a lot of companies will be asking "why aren't we using React Native instead of building two separate apps?" which I can imagine feeling somewhat threatening towards your area of specialisation
There seems to be a much more obvious explanation as to why people are assuming it used to be React Native. The article says:
> > Compared with the previous iOS version, this new Messenger is [mentions improvements].
> > We accomplished this by using the native OS wherever possible […]
That seems to imply that it wasn't native before and they got the gains by switching to native. And since Facebook are well-known as the creators and biggest users of React Native, it's not a big leap to make the assumption that that's where they were coming from.
[Also, in case there's any confusion please note the distinction between "native", meaning it is compiled to native code; and "React Native", which is a cross-platform framework that is not compiled to native code. "React Native" is a horrible name for something that is not native.]
If you want to go deeper or have more specialised requirements, then you might need a deeper understanding of the native platforms though.
Beyond "Hello World" all of them required me to get my hands dirty, at which point I was better off just doing C++ with native views, standard out of the box tooling available across all SDKs.
Nowadays I rather go for PWAs, or plain mobile Web, unless it is something very special that requires OS APIs or hardware access.
It does not mean it runs JS for anything critical, and very likely it does not.
My car entertainment system (GUI) run JS, and I'm fine with it. I would not if it would run on the emergency breaking system...
Fortunately, nothing quite takes the wind out of a platform's sails like watching the creator back away from the platform.
-step 2 : rewrite it in native so you greatly improve metrics while reducing code base size.
Seems like a good way to achieve great improvements in your product
There is also an inherent cost to rewriting all your codebase at once that should not be under estimated.
For something so big and integrated as messaging, I am not sure that this was a good match.
Admittedly turning messaging into a do all à la WeChat was very probably part of the initial plan.
It would seem that way.
Mind = blown!
One can only hope that Slack and other Electron apps reach this point eventually...
Given the headaches caused by Apple finally barring UIWebView (the basis of frameworks like Cordova) from new App Store submissions beginning in April, I'm not surprised FB would do this. There is plenty of rumor-mongering that Apple is going to make it increasingly difficult for apps based on hybrid frameworks through the submission process.
Apple legitimately doesn't seem to care about hybrid frameworks, they've been there since day one. Any time it's seemed like it got difficult Apple has backed down. The lack of JIT in WKWebView is probably the only thing that you could stretch here.
Cordova (and derivatives, such as Ionic) have had WKWebView available for a long time now, I think since iOS 9.
The Cordova team added a compile-time flag to force WKWebView in 5.1.0 (out since last November), and will be removing UIWebView altogether in 6.0.