They probably traded a really nice iOS codebase that had been maintained and improved upon for something that is going to end up with tons of special cases for when the UI is running on iOS/Android etc and make it incredibly difficult to test, reason about.
Instead of improving the code on each respective platform, you end up with an inbred red-headed step child that shares the limitations and thorns of each, all smushed together.
Now, making a change that once was once limited in scope to a single UI on Android now has the potential to affect both apps in new and exciting (read: unpredictable) ways.
I've been down this path before. There's something incredibly satisfying about reusing code, but there's such a thing as too much of a good thing.
I'd like to see a case study done in a few years once the whiskers have had some time to accumulate on this codebase.
Steve Jobs knew about the perils of this development methodology which is why he specifically put his foot down on technologies like Flash -- which (let's admit it, folks), React Native really has more in common than we'd like to admit.
I have, and most of what is written there I find correct. Wouldn't go as far as the Flash stuff. Mostly, it's down to the terrible web ecosystem and JS. Feds love it, but they don't know better. Native developers do, and most of the ones I've worked with have suffered a mental toll on having to work with RN. Now, is it an understandable from a management standpoint? Sure, especially at a company like Facebook, where there is a lot of fed experience. Does that make it a good technology? Not at all. It's a terrible compromise that has only one purpose - allow feds to develop on mobile. If only cross-platform mobile development was a concern, something like Xamarin is a lot more technologically sound, but still a big compromise.
Dude, I've been developing on the iOS platform since 2011 and Android not much later than that. I've developed in Xamarin, and RN has a MUCH better development toolchain and dev experience.
I really don't understand the JS hate. I'm using typescript for RN development and I have had 0 problems so far. JS/TS dev velocity is just so much better than ObjC/Java. Swift is a huge step in the right direction.
Not sure how you developed with Xamarin, or how long ago, but it most definitely does not have worse toolchain development. Starting with a proper IDE, to compilation, to native-interop, to performance, to actual base library that exists.
Thanks for pointing that out, forgot my old site was still in the profile.
What do you mean by feds? That's still a very confusing statement. Switched off of Xamarin about 8 months ago and haven't looked back. My organization had a ton of problems with Xamarin, without honestly that much gain at all. We still needed specific devs for Android and iOS. Sharing component and state code has been an absolute boon in productivity and speed in getting a world class suite of apps out. That plus a React stack for Web means I can help out on Web with no ramp up, and vice versa.
We are using Xamarin for our mobile apps and around 90% of .NET code is shared between both platforms. The platform specific code is basically just UI related, which makes sense given the different approaches to some UI mechanics in iOS vs Android. Also leveraging the huge .NET Ecosystem which in general has quite high quality and superb tools for development and debugging is a big plus.
We are also starting to use .NET Core for Backend Microservices which would allow more code sharing and Backend devs could in theory chime in on the mobile codebase quite easily.
With all the cross compiling/ web assembly stuff going on it will probably soon be possible to use a .NET lib in JS frontend code as well.
I agree that RN is a good alternative to this if your team is very JS dev heavy and while i did a lot of nodeJS and Angular in my life, i just loathe the JS ecosystem of today.
In our organization, it ended up being UI code that was the 90% number. The actual business logic code wasn't extremely extensive in the same way that we had to know Android and iOS, and then basically transpile mentally what we know into C#. Though almost all of the core SDK methods are named the same, so it wasn't too huge of a mental switch.
At this point with react-native, almost everything is shared. UI code, business logic, app state, etc. I think the node ecosystem opens our organization up to a lot more possibilities as well.
I've found that 3rd party react-native libraries are about the same quality as Xamarin Nuget packages. Some are good, most are meh.
Also, I upvoted you. Thanks for sharing your experiences.
Let me explain the "fed" thing. React Native's number one "feature" is that web developers are able to join in development, or even start a "native" app where it would not have been possible before due to no native development teams. In the web dev world, "fed" /front end developer/ is usually the term for the front end web developers - this is what I meant. (While iOS and Android is also front end, it seems "fed" is almost exclusively used for front end web developers.) So, normally, anyone that has extensive (or even some) experience with web development, would already be familiar with the ecosystem and concepts, while for many native developers, there is quite the cultural shock from a bad ecosystem, no base library support, very uncomfortable debug tools and a flamboyant community behavior (many ridiculously terrible click-bait Medium articles a la "why I switched from [X] to [Y] and it is the best thing ever" and "How [Z] changed the way I write code and it will change the way software development is done").
I am not sure why you have had bad experience with Xamarin. To me, using .NET for shared business logic sounds like a real winner, but I will give you the fact that it helps with web dev. However, as a purely technological observation and no interest in management considerations, I can only argue against using RN at this stage.
I think you're conflating a BS web dev culture (which is amplified extensively through the internet and feedback-loopy sites like HN) and actual development technologies.
There's always articles like you're mentioning. I mean, go look at articles when Swift was first announced - or even iOS tutorials and forums ca. 2011.
Sharing business logic is a good thing. But it's hardly the number one feature of react-native. We share almost everything, and have almost no problems doing so. It's been a very good thing for our org, while Xamarin was the opposite.
It's also worth noting that we ramped everyone up from being C# front-end to React/React-Native front-end. So nobody really came in as cutting-edge web dev experts, but our developer velocity now is insane. I think React/RN are good things.
A lot of the views mentioned were specifically poorly-performing web views... now they're well performing React Native views, and apparently sharing more code.
React Native (node-style cjs or es2015 module) based applications don't have to be poorly written, or ill-tested. I think a lot of your bias is unfounded, since Steve Jobs saw only web applications on iOS initially.
I would guess one reason for Instagram to go the RN route is simply easier hiring.
For every really good iOS/Android developer, there are probably 10 really good web developers that easily can pick up RN. As a web developer myself, it's a full time job to keep up with the JS ecosystem alone.
I tried learning ObjC a few years back but gave up because of limited time, weird syntax and very slow feedback loop.
Now I am stoked that I can finally build native apps with the web tech I spent so much time learning, and I don't think I'm alone in that regard.
Instagram is the last group that would have problems hiring iOS and Android developers. I'm almost certain that's not the reason for the switch to React Native.
The main reason to switch is that the user cannot tell the difference for their use case, and they get to iterate faster.
I'm not sure if this is still the case, but I remember hearing a year and a half ago or so that the Instagram team was still pretty small then. FB is pretty lean in terms of number of frontend devs - at that time I remember being told the number was ~250 or so, which has probably grown since then.
The thing is that any good iOS/Android developer will know the platform they are working on while good web developer may have no idea what native SDKs offer and end up reinventing the wheel, badly.
I've never used React Native, but I have done a lot of messing around with Apache Cordova / PhoneGap. From my experience, you're probably better off just developing your apps the "standard way" with Android Studio or xcode. I'm sure React Native doesn't have the exact same problems as PhoneGap, but I bet there are some problems. If there weren't any problems, the iOS and Android codebases would be nearly identical. But that's just my opinion... man.
I worked on a medium sized RN app for both Android and iOS which dealt with the camera, photos and the file system. It was 99.98% the same with only 50 lines of _my_ code difference between then (this obviously excludes framework and library differences).
As a business decision, it's outsourcing expertise of the platforms to Facebook, which has plenty of resourses working on the problem. True it's been the holy grail as long as I've been a web dev, but outside of a bit of platform lock in risk it seems like it's come a long way with relatively simple apps like Instagram. It's trading expense for risk.
Do you really think there's much expense to having two code bases for simple apps (as you said) like Instagram?
If these apps are written properly most (all) of any custom logic is done server side and they are just presentational only.
In addition, a good developer/engineer/team that's properly focused on mobile (the size of the team of Instagram) should have absolutely no problem supporting two native codebases.
Think of it as not 2, but 3 different languages. Say your backend is node - your JavaScript developers can all work across the stack. You can keep code standards more or less the same across the whole company.
Instead of improving the code on each respective platform, you end up with an inbred red-headed step child that shares the limitations and thorns of each, all smushed together.
Now, making a change that once was once limited in scope to a single UI on Android now has the potential to affect both apps in new and exciting (read: unpredictable) ways.
I've been down this path before. There's something incredibly satisfying about reusing code, but there's such a thing as too much of a good thing.
I'd like to see a case study done in a few years once the whiskers have had some time to accumulate on this codebase.
Steve Jobs knew about the perils of this development methodology which is why he specifically put his foot down on technologies like Flash -- which (let's admit it, folks), React Native really has more in common than we'd like to admit.