I found React Native to be a mix of joy and frustration. I was amazed at how quickly our devs, who came from the web, could build polished screens that performed beautifully. Then I would become baffled at how, for example, you couldn't do a background upload in React Native. Here - it does is upload a file in the background: https://github.com/Vydia/react-native-background-upload
In RN, you have to connect JavaScript to native code with "bridges". If a bridge exists for, say, getting GPS data, you are fine. But if it doesn't, welcome to the club. I finally became relatively adept at writing these bridges, but I would have much rather have spent that time writing code for my app.
Their build system is weak. For example, the build scripts hardcode 'dev mode' unless you have a build scheme in iOS and Android called 'release'. It felt like nobody else had built RN apps that have beta and staging environments. Crash reporting sucks and we finally got it working with sentry.io and some custom build scripts to upload source maps so we could get decent JS error reports.
But that stuff will go away in time. I was blown away at the progress we made. It was painless for web devs to jump right in an be productive. So for us it's a net positive.
If you're starting something new, try it out. Make your platform choice carefully. RN isn't the only game in town. See what works for you. And don't get fooled into thinking that you don't need any native knowledge to make an app. Maybe hello world, but nothing industrial grade.
What else is there that's similar? NativeScript?
The positive: If you know JavaScript, you can get started quickly because they provide a JavaScript API and all your code is in JavaScript. Under the hood the JavaScript connects to native code. So you get a native look and feel on iOS and Android. You have a single codebase.
The negative: Back then it was impossibly hard to get an app working and/or looking correctly on both iOS and Android at the same time because Titanium was full of bugs. So many bugs. This is because for each platform they have to provide native code. Sometimes their iOS code had bugs, sometimes their Android code. It was absolutely frustrating. I often had to find workarounds which caused a lot of delay so I had to double down to keep the deadline. Titanium was a reason I quit that job after 1.5 years.
On paper it’s nice, but the implementation was terrible. I went back to web apps and have since been happy.
$40/month, but no visual builder. Eclipse-based IDE tooling (which was always flakey ime). $100/month/seat to get hyperloop and visual builder. Still not sure what 'arrow' is exactly.
The demos always looked good, but my day to day was... frustrating after a while. Possibly could have stuck with it and justified with "sunk cost" but I started looking more closely at cordova stuff. Yes, it's not pure 'native' (why I liked titanium) but the ecosystem is more flexible (or so it seems).
RN is not perfect, but it's leagues ahead of Cordova, Xamarin, and etc in a combination of performance and easiness of UI development.
I think the biggest problem with adopting React Native in a shop that already has a native team is politics. Lots of Native developers don't want to touch it.
I think it's a great fit for companies who already have a React front end team and who's mobile teams are at least open to giving it a try.
I feel like this is a huge understatement. Doing anything non-default takes ages to configure, and there's so little documentation to help you out.
On a side note, their build scripts are all js and node is probably my last choice for build scripts. As a result, you have callbacks and promises everywhere. I understand they don't want people installing more dependencies but using something common like Ruby would make it much easier to build great build tools.
For what it's worth for react-native proper we are investing a lot of time into this now. With latest sentry-cli getting sourcemaps going is a one-line change to your build script.
https://docs.sentry.io/clients/react-native/#updating-build-... (you only need the line with react-native-xcode)
At some point, you reach the limit of what the framework provides, and you need to write some native code.
I've always felt that most frameworks required you to rewrite your app in native code once you hit these limits, so it was better to just start with native code in the first place. React Native is the first framework that doesn't make me feel this way.
We pitched (and won) against a competitor who was proposing to use Outsystems last year - who's product creates a React.js Cordova app - and it's mostly only 'cause they demoed badly that we beat them, I was impressed with the capability of their tool (and without doubt their autogenerated react.js thing is well under development to produce react native apps very soon...)
Some apps will always be native code - if for no reason than to gain access to new device capabilities on launch day instead of sometime down the track when bridges or native plugins for the hybrid tools ship - but a vast number of apps can (or are being) reasonably built using hybrid tools these days...
I'd much rather see some of the positive traits of JS/RN/etc find their way into Swift/UIKit/etc so I don't have to trade away what I like about native development in its current form.
React Native basically solves this and solves it well, and can perform well in most cases.
And if there is some screen where it doesn't (ex. if you were building Snapchat and were going to work on live video filters), you can implement that in Swift/Java/Obj-C and just make that a native module that's part of your RN app.
My personal prediction is that almost all apps will be started in RN in the medium term future and most will end up mostly RN.
Honestly I think in 1-2 years at max reactnative will have the same popularity of Ionic and Phonegap at max, and probably far less if react will fall against the newcomers of the web-frontend space (vue.js, inferno.js, riot.js, etc) as fast as it seems doing right now, remembering closely the time of angular1 eof vs react beginnings.
As has been the case with all human artifacts since humans started creating them.
I'm fine with iteration as long as:
a) each one increases developer productivity
b) they remain stable for at least two product release cycles.
It's still early exploration for me, so I might change my mind on this, but I'm not expecting RN to be a game-changer. Definitely useful, but not really going to upend anything.
Mobile app projects under $20k are definitely react native. It also makes mobile app projects at the $10k level now viable. At the $40k level it'll be a tough choice, with the fact that the project wants to reuse parts for a web app being the clincher.
The other obvious reality is of course that RN isn't meant for 3D, games, or so on. But that's been the understanding from the get go. What started out as replication of whatever UI components that the first and second class FB apps were making use of has now grown into a community that covers many, many different UI cases.
RN is pushing Swift, ObjC, and Java engineers upwards to focus on the upper end but it's wiping out the bottom by letting the web devs into the mobile devs world.
At the same time, I'm sceptical that RN has escaped the earlier performance ghettos of Appcelerator, Phonegap et al., which aren't just in games, but also in complicated UIs with a lot of elements. On building a simple sudoku app, I ran into noticeable micro-lag that seems to come from overuse of Views to structure the grid--and noticeably, the performance was better on a non-retina device, causing me to remember the swamp that Java's AWT got caught in with its 'native peering' arrangement, namely that cumulative overhead killed performance in virtually all non-toy cases. React's virtual DOM is an obvious plus in the browser; I'm not so sure where native apps are concerned.
That's a problem for your designer to solve
Declarative UI, hot loading, code reusability, modularity, etc. You name it. Because of all these I feel like a dinosaur whenever touching non-react code.
Native covers the parts where React is clunky - for example some unorthodox UI elements that can't be created with simple views and flexbox styling
Core functionality is there already and with time it's only expanding.
I don't intend on turning back.
My experience is: finally, I can program like I do on the Web! And not just in the sense it uses JS, but like, double typing R to "reload" the app being super fast and seamless. Coding my first React Native app has been the most enjoyable experience I've had creating a native mobile app ever. Even small stuff like being able to use the Fetch API over whatever native gobbledegook API Android uses is a massive quality of life improvement for me.
I actually don't particularly care for React itself (the Web version), but that's because its download/execution costs are still iffy for me and I don't think JSX has a place on the web long-term. I also don't think it's opinionated enough and the roster of React "plugins" reminds me of the bad side of jQuery widgets. (If you couldn't tell, I've moved to being more of a Vanilla JS purist in recent years as the ECMAScript standard has evolved.)
With React Native though, none of those points really matter and I'm able to enjoy the "breakthrough" of self-contained JavaScript components combined with super fast debug iterations. It's a win-win in my eyes.
React native, Ionic, etc. are great for most apps out there. There is nothing special required to get a great app published in very little time, and existing developers can jump on the project and get it done - which probably results in much cheaper overhead for a startup. It really is a win-win.
The only reason I'd consider going full native these days is for mobile gaming, and anything requiring low-level control.
I've been building a React Native app and there are a couple big positives for it.
l. All the web developers at my company can manage in JS. You don't need special talent or training like you do for the other languages. Our native apps are built by completely different teams because of their native skill sets.
2. The app we're building shares most of its code between iOS and Android. This prevents you from building the same app twice in two different languages (and as I pointed out, for us, in two different teams).
They will have a hard time if we become extinct.
Expo includes a `GLView` component that provides a WebGL-like API to OpenGL ES. Things like three.js run on it directly! But CPU-side JavaScript becomes a bottleneck (the shaders themselves run at normal speeds).
One of the reasons I like React Native a lot is because it makes it so easy to drop back to native code when I need to.