I started a project in React Native a few months ago, then I left it for a couple weeks, then when I came back to it, I did the usual chore of updating libraries, and found that I could no longer compile/run the project. Purged and re created my npm_modules folder to no avail. Things kept getting worse and I simply have no clue what is going on. Started a fresh RN project and even that would not run.
I got the feeling that it's layers upon layers of leaky abstractions and the whole thing seems rather fragile.
Hey I work on Expo - this is one of the big pain points we're trying to improve. Since Expo is responsible for the native code in these apps we can do the work of keeping all the libraries up to date. You're just responsible for updating the JS code, which normally has minimal breaking changes. Many people have been able to update versions by only changing their dependencies in package.json.
It's not just that. I also need plugins for basic functionality that RN does not provide it out of the box, like playing audio, accessing the file system, reading sqlite databases, etc.
"Linking" these plugins is black box magic, if anything the fails I have absolutely no clue what is going on.
I have a feeling that some of the hairy errors I've been getting have something to do with the plugins not being up to date with the other libraries.
But like I said, I just have no idea what's going on.
If I'm going to learn how Android and iOS code needs to be structured then I prefer to just write native code. At least I will have more control.
Yes a lot of times the issue is that libraries only support certain version of React Native, so for certain sets of libraries there are no versions of React Native compatible with all of them.
The idea is that we provide a lot of nice things out of the box and then if you still need to write native code you can detach (https://docs.expo.io/versions/latest/guides/exponentkit.html) and only write the native code you need while keeping all our other APIs. You can still use `react-native link` after detaching if you want.
Is there a chance that some day your work (expo) will be merged with react native ? Conceptually, I think you are doing what people would expect the rn team to be doing. Namely providing access to the native apis through javascript, except that expo seems to provide much more features.
For me, what's holding me back from using expo is the additional complexity of yet another dependency and having to use more tooling (e.g. expo client).
I think right now it makes sense for us to be separate from React Native. Adding all of these libraries adds QA overhead and if Facebook doesn't use them internally it'd be hard for them to keep them up to date. In addition there are some other features we support that definitely don't make sense in core. For example we embed multiple versions of the React Native runtime in our app so that people can choose when they upgrade and we don't break old projects when we push a new version.
I've been an early adopter of react native for a long time.. and this was exactly my experience... it's very demoralizing and why i switched to exponent and try as hard as possible to do all I can with just JS (without detaching project form expo).
I felt that way using React itself (for the web) - it was like writing code upon so many layers I didn't have control to fix eventual hairy bugs anymore. So I didn't even try Native.
I am probably blaming React for more than it's responsible for, but I feel that, in a real world project, it's rather difficult to not fall into that zone where you have webpack, several loaders and complex configurations for different environments, babel with plugins/presets, gulp, redux or something equivalent, strange directory structures because all libraries purposely try to avoid being associated with bad old big frameworks thus giving too much freedom for the programmer to be "creative" when organizing his code, node for SSR (and then taking care for everything to also work on the server), css modules, react wrappers crashing because wrapped libs were originally written with dom manipulation in mind etc. You know the list can go on, the last time I remember my package.json had around 50 direct dependencies, and it is possible to justify every one of them. All that to write magic JS code that imports assets, transforms them, output obscure css classes and a client.js file that eventually print some crazy warnings on line 53777 column 838383937.
I know I am just complaining like a grouchy old man and not really helping understand and solve the problem, but that's what I can do right now. I would say that maybe we are building too modular software and the complexity of glueing everything together is becoming a problem? I feel like the existance of several "react + this + that" boilerplates indicates something.
I can also be wrong and everything is OK and I am problematizing.
I purposely avoid all this mess. The only thing in my "build stack" was TypeScript and a small custom script I wrote myself to assemble things together.
Before I joined that project they were using yoeman and angular and a bunch of other useless crap. I got rid of all of it.
Hi! I wrote a bunch of the code for CRNA (although it obviously builds on a lot of great work from Facebook and Expo people). Happy to answer questions.
I'll be doing a brief demo during my lightning talk at ReactConf -- livestreamed at ~5:45pm pacific time today at http://conf.reactjs.org/livestream.
I remember buying a Mac in college because I was finally going to get into Native development!! Well, that was almost 10 years ago and after many false starts it just never happened... seemed like such an insurmountable amount of cruft for even the most mundane things.
Then earlier this year I tried RN. And yes, I struggled mightily at times with building/deploying/linking libraries, but when it came to the app it finally felt closer to the level of effort I put in building web stuff. And then I finally sent an app out the door with Camera integration and some pretty neat UI elements. All thanks to this.
RN has lowered the barrier to entry in such a way that I have a feeling my story is/will be incredibly common. CRNA is yet another great step in that direction, so on behalf of us mostly part-time devs, thanks a ton!
I'm a fairly experienced backend and web developer. My first experience with RN was exactly this.
During 24 hours at a hackathon I was able to build an app that would show a live view of the camera, capture 5 frames a second to be analysed by an external api, overlay recognised food items on the screen, send it all off to the hello fresh api and display a list of recipes to the user that would use the most food items from their fridge.
The fact that I was able to accomplish all of this in 24 hours with no prior RN experience is just amazing to me.
No questions, simply saying Thanks! I've been trying to show people RN and this will make it super easy to introduce it to them. Know a lot of work in the OS community is under-appreciated, so great work & thanks!
I'm a bit unsure about this decision. Because this is tying React Native to a private entity, namely Expo, that has not open sourced it's toolchain used here. Expo takes your code and builds it on their servers and then serves it to you. That toolchain unlike React Native is not open source. This is creating a walled garden around Expo who can easily decide to charge for their server fees. Yes it is a much easier of an boarding experience then installing Xcode and Android Studio but at least with Xcode and Android Studio you own the whole toolchain. Because of this fact I don't think this is comparable to React Create App, which is excellent.
Edit: Expo has open sourced their code, see below. And CRNA does not build code on their servers, I assumed it had the same workflow as their XDE tool. It does not. But I'm still unsure of this decision. It makes Expo a vital part of React Native, or at least puts them in the position to have that position.
Also, the RN packager runs locally on your machine, there is no dependency on Expo's build services when working with Create React Native App.
The concerns you raised were front and center when we were working on this project, and we worked hard to make sure that CRNA has no service dependency, it works completely offline.
CRNA doesn't use our app building service (which is free) or integrate with it, though you can take a CRNA project and use it with the rest of our tools like the app building service.
Also, CRNA does support ejecting which gives you an Xcode project and an Android Studio project. You can really control everything you want to control here.
Which build server? If you have an Expo account you can create a "standalone app" with our service, but that's not a part of CRNA's workflow and it's certainly not required to use this tool.
No worries. I understand that you want to get the story straight. I do think you should specifically state in the blog update that this is a new tool and not a reuse of Expo's tools.
You do need an Expo account to create a standalone app. If you want to create an app for the App or Play Stores yourself (i.e. without an account), then you'll need Xcode and/or Android Studio.
I work on React Native Open Source at Facebook. We are not attaching React Native to Expo in any way. This tool simply helps developers get started with fewer dependencies than before. We are happy to collaborate with any company that makes React more accessible- not just Expo.
I find React Native dev/build environment quite straightforward (and I'm not even a "JavaScript developer"), so what exactly Expo adds to that?
Slight off-topic: is it possible to use C++ code cross-platform way for performance-critical parts? i.e. to have single C++ code for iOS and Android, in React Native.
Yup you can! That's actually how Expo's `GLView` (which exposes OpenGL ES as a WebGL'y API in React Native's JS context) works. The binding is done in common C++ code for both iOS and Android. Calling to that from Obj-C is straightforward, for Java you use JNI. This is binding is done manually and built once (not auto-exposed), then you can use the GL stuff in JS!
The native build environment is tricky for a few reasons. On iOS it takes a slow download of Xcode and simulator, plus an Apple Developer account. Before CRNA, there was no open-source way to get start building an iOS app on Windows or Linux. As for Android, there are a long list of native build dependencies and environment variables that need to be correctly established before you can build your app.
It is definitely possible to create a cross-platform C++ library to share performant across platforms, but unfortunately you need to do the plumbing for each platform by hand.
I wouldn't go so far to say that you are not 'attaching React Native to Expo in any way', this tool which will soon be the default way to create React Native projects installs the Expo SDK. This is by definition attaching Expo to the projects I create using this tool.
I wouldn't say that this tool "will soon be the default way to create React Native projects". We want React Native to recommend the set of tools that is most suited to developers, but not be tied to a particular one. For example, we have at times recommended Genymotion when we thought it was the best recommendation, even though it's tied to a private entity. We would like to hear from the React Native community what methods of getting started are the most well-regarded, before changing any recommendations on the React Native website. If you don't want to use Expo that is totally fine, you can just use `react-native init` which isn't going away.
I believe that 'react-native init' is not going away. But I'm sure that in all documentation going forward 'create-react-native-app' is going to be used as it is a simpler tool to uses the verbs people know in npm. So by that logic it will be basically be the default way.
CRNA includes an "eject" command similar to CRA's. So anyone could eject to bare React Native (like react-native init) if they want or need that option.
I see you included this warning: https://github.com/react-community/create-react-native-app/b.... I still don't understand why this had to ship with the Expo SDK. You are only going to have Newbies equate React Native with Expo. I am still of the opinion that this is not a right move for a development tool. If you want to help make 'create-react-native-app' then great, but it should not favor a private entity.
I'm very sensitive to the concerns you've raised in this thread. I've discussed these issues quite a lot, and ultimately decided that it's better to provide a net win to the React Native tooling ecosystem, and try to smooth out the gaps between React Native and Expo. I do think CRNA is a good improvement over the current state of "getting started" in React Native.
Regarding your concerns about "private entities," React Native is open source. Expo is open source. React Native was created and is maintained by Facebook, a private entity. Expo was created by and is maintained by Expo, a private entity. Do you have the same concerns about the recommendation in the RN docs to use Airbnb's maps library?
In order to use CRNA, you need to have a client that can fetch and load the JavaScript bundles. CRNA is agnostic to which client you use, which is why app.json puts any Expo specific configuration under an `expo` namespace. Anyone is welcome to implement their own client and use that if they prefer. I'd be very happy to review PRs which support loading React Native JavaScript in an alternative client. As an implementation detail of the Expo client, a number of native APIs are exposed, and it would be infeasible to block CRNA apps from accessing them.
We don't push users towards the Expo SDK, and the template project doesn't make use of any Expo APIs. If users choose to include a dependency on Expo's code, then we warn them that ejecting will break that dependency -- that's it. We choose a default choice in that prompt on the basis that we don't want to push users towards breaking their app.
Exactly you are trying to to smooth out the gaps between React Native and Expo. You have every right to help your company succeed but the way this is presented here is that you did it as a neutral party, you did not. You crossed that line as soon as you included the Expo SDK by default.
"Do you have the same concerns about the recommendation in the RN docs to use Airbnb's maps library?" No because that is not even an apt comparison. An apt comparison would be if AWS Engineers helped make 'react-create-app' and they bundled the AWS SDK as well merely to be 'helpful'. That would be an apt comparison not a recommendation on the official documentation to use a certain library.
If you don't push people towards the Expo SDK then remove it from the default 'react-native-create-app', I'm okay with it being in certain templates but a private entity should not be in a default. You clearly benefit from this decision, yet your pretending that it is only because it's in the community best interest.
The beauty of open source is that you're free to fork the repo to include your own tooling if you so wish. Those who share the same concern as you can then go ahead to use your fork.
Nobody is pushing anyone to use Expo's SDK. You are free to choose whether to use it or not. In the same way, you are free to use Facebook's React Native framework or not (bear in mind Facebook is a listed entity with its own corporate objectives as well).
What are people's feelings towards React Native vs actual native mobile development these days? Are people starting to get the sense that this is the future and coding in Swift/Objective-C/Java for mobile is dying off?
I've been doing iOS and Android for about 6 years. My latest project uses React Native. We just finished an app for both iOS and Android that has over 100 screens and did it in only 3 months with a small team. So I'm a good authority on this subject.
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.
Pretty much agree with everything you said. I'm an iOS/Android dev with about 7 years of mobile development experience and I have shipped two apps using React Native.
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.
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.
I used Appcelerator Titanium to build a couple of apps a few years ago (2011–2012).
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.
It seemed to me Appcelerator sort of abandoned the smaller/hobbyist/indie market for enterprise. I was using it in 2013/2014 and went to one of their conferences in 2014 - activity seemed to really slow to a crawl in public (hyperloop was announced, and the demo looked great, but I never saw much after that).
$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).
I've been using Titanium for years. Still do. It can be frustrating at times yes, but through using it so long, I've now learned enough Objective-C and Java to fix things or build modules to add functionality. Not enough to build an app, but it's been an enjoyable learning curve.
> Crash reporting sucks and we finally got it working with sentry.io and some custom build scripts to upload source maps
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.
I just spent whole day yesterday trying to upgrade RN0.40 -> RN0.42. It's a nightmare because there are conflicts in xcodeproj file and you have to manually merge them.
It sucks. Their default upgrade tool does more harm than good. Currently I start a new RN project then do a diff to see what I have to update on our actual app. Fun, right?
There have been frameworks for writing native-like apps since the very first iPhone was released.
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.
Sure, but that limits get further away with each advance in js/webrender speed, and as the fleet of devices you're targeting becomes newer (and more powerful) over time.
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...
It's likely not a popular opinion, but I hope React Native and similar frameworks don't come to dominate or be the only option considered in most situations. That's not to say that they have no place in the mobile space, but I do not enjoy web-style development at all. It's half the reason I'm a native mobile dev and not a front end web dev. If RN becomes king, I'll take it as my cue to find a different niche in software development.
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 or something like it is almost definitely the future. It's totally unreasonable to write two totally separate copies of your app using languages that take a while to build and compile.
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.
If the js ecosystem taught us something is that react and his derivates are going to fall and being replaced by another iteration of new tools very shortly, and then repeat.
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.
Having run through an app building exercise myself, and starting to shepherd coworkers through the same exercise, my feeling about it is the same as it was for earlier platforms (like Appcelerator) that I tried: good for certain classes of application that are mainly built around text, lists, and UI logic; weak for performance demanding areas like games. React native brings a nice dev pipeline to app development and speeds development for a lot of garden variety app development tasks, making it a real advance for prototyping or rapid iteration; it doesn't bring anything that's going to unseat native app development where native is strongest, in drawing intensive tasks.
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.
In the real world of contract software and digital agencies, RN has been a game changer over the last year.
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 my employer I can easily imagine deploying react native apps for a variety of uses, especially as we do service design : being able to run real experiments with, say, gov't services with real apps or companies looking for mobile assist on new service offerings is a huge win.
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.
Agreed -- if you're doing audio/video effects, or making a non-trivial video game, you'll probably want to be writing in C++ (and on Android, using the NDK).
React Native is definitely more aimed at applications that tend to use the typical mobile UI controls, rather than games. If you're building a 2D or 3D mobile game and you want to get the cross-platform efficiency of React Native, you might want to check out Unity instead.
Worked with RN for a year now, after 2 years of native iOS dev with Obj-C/Swift.
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've done a little Android programming over the years ever since the first beta SDK (m3) hit in November 2008. Android Studio was a revelation, but like I said, I do very little native programming and a lot of Web stuff. I haven't messed with iOS yet.
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.
Curious: why is JSX on web worse than on native? And if you're overwhelmed by React "plugins", we certainly suggest you not use them. Most of them are just components you can write yourself.
Personally, for me, it comes down to trade-offs. How quickly do you want to be able to push changes? Do you want to hire a new developer for mobile, or have an existing developer plug away on the project? Are you building a game, or does your app require very low-level code control?
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 doubt the other languages are "dying off". Javascript isn't the most elegant language but it's certainly getting better with ES6.
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).
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).
You act like web developers are a lower class of human being. There are plenty of fullstack devs capable of writing Java/Swift/Obj-C but are just far more productive in a web stack. Plus the benefit of being cross-platform is a huge cost savings.
Has the Android side improved with React Native? The last time I took a look at this which was last year, the consensus was the Android result wasn't optimal.
There's a ton of work going into polishing many different parts of React Native right now. So "the Android experience" has definitely improved overall. But it probably depends on what specifically you were running into last year that was frustrating during Android development?
Thanks for the great work on it! Will definitely check it out.
As for someone who was using Expo for a while, how's that different from the exp start and the rest of the platform? Seems like an interface or another entry point -question if necessary?
Always interesting to see how cross platform is evolving (this and also Xamarin update recently), wonder how the Google and Apple regard this.
Anyway, I just tried out the Expo App on iOS and noticed that the back swipe animation does not seem to be native in the examples. Is there a reason for that? (that's something I always try out of I want to check if an app is native).
The examples use a navigation library that is implemented entirely in JavaScript and it does not currently aim for 100% accuracy for platform gestures and animations. Pure JS navigation is a work in progress with React Native but, in my eyes, it's the ideal end-state (see a post I wrote here for more info: https://blog.expo.io/good-practices-why-you-should-use-javas...), but to get there we need some more powerful low level primitives such as a better gesture API.
Also, I'm curious which examples stood out to you. The "Growler Prowler" app intentionally pushes a screen on top without sharing a navbar, even though this is possible, because this works better for the detail screen. See the beautiful PocketCasts app (https://www.shiftyjelly.com/pocketcasts/) for the design inspiration there.
A pure-JavaScript implementation of navigation might feel almost native on today's mobile platforms if you work hard enough at it. But will it feel native in the next release of the OS? And does it feel native for all users? For example, when a user of the VoiceOver screen reader on iOS navigates to a new page in your app, do they hear VoiceOver's "new screen" sound effect, as they do when using a real UINavigationController? Also, VOiceOver has a special gesture for going back. Will that work in your nav implementation?
My point is that when you start with cross-platform and try to tweak and tune it until it's native, you might miss some subtleties, and it might still not feel native to some users.
For what it’s worth Airbnb just open sourced a React Native library that implements navigation natively on both platforms. Check it out: https://github.com/airbnb/native-navigation
Thanks for the insights! I tried out all the featured projects and they all have the "card" swipe. Reading your post I get why it's implemented like this. Getting as much in JS as possible. However if you push it too far you'll end up with something like Ionic. I guess it'll all meet somewhere in the middle where you have the basic blocks native and JS where native is too hard.
Are there any tutorials or documentation on integrating Expo with a different RN build process? For example, if we have an existing setup with TypeScript or want to use Mocha instead of Jest or whatever.
Thanks! I guess my actual question is -- what are the hook(s) Expo expects from a React Native package?
I'm used to using Webpack or Gulp or Grunt to transpile source code into something deployable on the web. The React Native / Expo packaging process feels opaque to me though. It's not clear to me, for instance, whether Expo uses https://github.com/facebook/react-native/tree/master/package... or whether it has some kind of different packaging process.
Likewise, a newly created project with the XDE builds automatically using Babel. But it's not clear from the project itself how XDE knows to use Babel. Is Babel hard-coded in the XDE? Can I turn it off?
Expo apps also all seem to have a `registerRootComponent` function, but there isn't any documentation on what this function actually does.
Babel is on by default in the React Native packager, which is indeed used under the hood by both CRNA and Expo's devtools. The template projects include a .babelrc file.
The `registerRootComponent` function is essentially a facade to `AppRegistry.registerComponent` but it also configures hooks for Expo's asset system.
It looks like the setup is still a bit messy, they do mention open issues and it seems that some people are working on making the experience smoother, it would be awesome to have something as simple as:
A bit off topic but how is react native performance compared to native? Lets say you did an Instagram type timeline, would you be able to get the same scrolling performance with RN as going native?
I've run into a few problems with lower memory Android devices - even with the optimised ListView components, there were crashes. However, there's a new FlatList[1] component coming in (I hope) 0.43 which is waaay more performant - it's practically solved all of my issues.
There are also ways of bridging over to native scroll views - see this article[2] by Wix's Tal Kol for one example.
I only do React work (not Native) so I can't definitively say, but I'd imagine it's close to native perf, because React Native spits out native UI components at the end of the day.
I believe that was only for apps that could talk to Objective C API's natively, in other words, essentially bypassing the native code review process. React Native can only do hot updates of JavaScript (which may call existing Objective C API wrappers, but not create new ones).
Rollout exposes arbitrary Objective-C APIs to JavaScript (likely using Objective-C's reflection capabilities), while React Native and Ionic/Cordova WebViews require you to explicitly bridge your own native methods. That was one of the key differences in Apple's concern.
Implementations already exist, such as react-native-invoke, that enable similar functionality. The jump from "need to explicitly bridge" and "explicitly bridge the runtime API" is very small, opening the possibility of exactly the same features as Rollout.
The clause of the app store guidelines is not just about code; it also forbids gaming the review process for adding features or changing the app purpose without an explicit review. This is regardless of the language used to write the app.
I'm confused what the point of your comment is. If you can do it natively you can do it with React Native. "The jump" for any app from not including Rollout-style invocations to including them is the same if it's a React Native app or a normal native app, and these can all be determined by static analysis by Apple during the review process.
The point is, saying "RN apps only push JS" is disingenuous. The exact same technology is used to push JS, and that JS can do things that Apple does not like, RN or not. It appears everyone working in the RN ecosystem is hellbent to distance themselves from Rollout, but the gap is very small between the two technologies.
I make a library that pre-generates all of the native apple library bridges. Isn't that equivalent, but your 'explicitly bridg[ing] your own native methods'?
"Your app, extension, and/or linked framework appears to contain code designed explicitly with the capability to change your app's behavior or functionality after App Review approval, which is not in compliance with section 3.3.2 of the Apple Developer Program License Agreement and App Store Review Guideline 2.5.2. This code, combined with a remote resource, can facilitate significant changes to your app's behavior compared to when it was initially reviewed for the App Store. While you may not be using this functionality currently, it has the potential to load private frameworks, private methods, and enable future feature changes."
I don't see why there can't be React-like libraries written and used in languages that compile to native. I'm not expecting to have JSX but I should be able to write component classes and implement their render methods, returning view trees written with some kind of object/array literal syntax.
To get as good of a development experience as React, it would require some work by the compiler and runtime people to basically let you do something like hot loading--Android has something like this now, and maybe Apple will get it too, though I'm not holding my breath.
I think it's a no-brainer for web development these days to do React because 1. you can opt out of it for parts of the page it's not going to work with for whatever reason and 2. the performance is pretty damn good compared to lots of alternatives, including writing all the UI state management logic yourself. However, I've not been convinced that the buy-in is worth it for native mobile development. Can someone who knows more tell me: is it fairly easy to do something like say "I can't/don't want to use React Native for this view controller--I'm going to implement it in code and use it and everything will just work."
Companies with large, existing apps that want to use React Native definitely share the desires written out in your last paragraph. Facebook has this need in their main app. And at React Conf today, Leland Richardson from Airbnb just gave a talk on using React Native in "brownfield" apps and seamlessly sharing a single navigation controller across React Native root views and UIViewControllers and Android Fragments. The navigation library that helps a lot with this is here: https://github.com/airbnb/native-navigation
Crashed my phone (An infinite amount of "Loading js bundle" popups appeared, creating a solid black background from all the shadows) and then it killed my server (EDIS/waveride vserver -now unreachable from outside, probably some kind of overusage protection).
Hi! Sorry you ran into problems. Was this just using the basic starter project? If you want to include some platform information in a GitHub issue I'd love to look into this.
Additional information: I was connected to the Debian server via putty/SSH with the js server open and that connection broke around the time where my phone layered infinite "loading js package" messages above each other. I guess you should at least do something to prevent that from happening on the client side. The server side and connection problems are my own demons...
Could there be any logs on my phone or server that could help you? As for the platform information, I will see what I can get once I can access the server again. It's a Moto G4 with Android 7 and the server ran some old Debian and node.js 7.x .
It worked perfectly fine on my local Windows computer.
Hi! Sorry for the very late reply, there's been a lot of interest and I haven't had time t get back to everyone yet.
I'm very surprised to hear about the behavior you ran into with the loading messages on top of each other -- we haven't run into this issue in the native client yet (I don't think). If you're interested, I think a GitHub issue may be best so that I can have a reminder to look into this later on this week.
Probably not. One of the biggest advantages of CRNA is that we built it from the ground up to not require integrating with Expo's accounts or services. If you've already opted-in to those services, then you're probably getting what CRNA offers plus a little extra.
EDIT: That said there are definitely some areas of CRNA that have had more polish than Expo's current tools, and I'm going to be spending a lot of time in the coming months bringing them closer to parity.
If you mean you'll write something in a language with a C-ish ontology (C, C++, Swift, Rust, etc.), WASM won't help you much because you can already compile these languages for both platforms and interact via bindings; WASM won't buy you anything except for mandatory interpreter overhead on iOS. If you mean a GC-ed language like JS or Java, WASM doesn't yet have native GC and likely wouldn't be much better than JavaScript as a compiler target for these languages even if/when it does.
WASM solves a totally orthogonal problem: running native-ish code in places where native code is currently unacceptable (e.g. web, other low-trust scenarios). Major mobile platforms can handle native code just fine, and WASM does precisely zero to help you write bindings for platform APIs.
I disagree. I want to dump "native" and just have a more performance engine than is JavaScript. I am assuming that more native hardware will be exposed via WASM. I want the high-level language that is compiling to WASM to isolate me from the platform differences. Perhaps is wishful thinking on my part.
What do you mean by native hardware? WASM's only goal is to expose some "hardware" in the CPU itself, all of whitch is already available to (and mostly used by) the existing JavaScript engines. Anything that goes through a driver has nothing to do with WASM; its specification explicitly does not define any APIs that WASM code can access at all.
If you want more performant code than you're getting from hand-written JavaScript, you need either (a) an improved JavaScript engine or (b) to write code in a different language. WASM isn't some magic escape hatch for high level languages.
Not quite. WASM will enable faster web-based performance, but you're still building on top of a browser. If you're using the DOM, then you're still subject to the normal performance bottlenecks there, and if you're using canvas then you need to re-implement a lot of UI code.
React Native is layer on top of actual native components on the respective platforms. They two are wildly different technologies. I enjoy RN and I do look forward to WASM as well, but I don't see them overlapping anytime soon.
First of all - I enjoy using React in browser and consider it the best browser UI tech out there. At the same time I've been working with desktop and mobile apps for past 12 years and there are things that makes me very suspicious about React Native.
1. Native apps does not have anything like browser DOM. Most of complex controls recycle views based on internal control logic. I don't see how Virtual DOM idea can be mixed with that. UITableView does not care about Virtual DOM and there is no easy way to apply Virtual DOM diff to a particular cell. To make default iOS table Virtual DOM aware you will have to rewrite it from scratch.
Quote from here - https://medium.com/@talkol/recycling-rows-for-high-performan...
>Recycling previously allocated rows that went off-screen is a very popular optimization technique for list views implemented natively in iOS and Android. The default ListView implementation of React Native avoids this specific optimization in favor of other cool benefits
2. Running event handlers in a separate thread is very bad idea. Appcelerator Titanium does same thing and it gave me all sorts of trouble in the past. For example - you scroll UIScrollView and it generates scroll events. These events asynchronously delivered to JS thread. JS thread changes view position. UIScrollView expect these changes during scroll event not after and does not optimise for that. As a result you get gazillions layout/scroll events which kills layout performance. You also get tons of locking/unlocking as a bonus.
In Titanium delay between UI event sending event and JS thread receiving it was visible with naked eye. It was virtually impossible to create responsive UI due to these delays. React Native seems much better in this area but I suspect that complex cases like I described above will break.
3. People have been trying to build cross platform UI for decades. There are dozens of desktop technologies in this space. None of them got even close to the point of replacing native UI. Maybe React Native will be first one but statistics is not on their side.
I think technologies which draw all UI themselves does better than others which provide cross platform wrappers to native controls.
- Java Swing, WPF, maybe QT - see some use, mostly in enterprise.
- Java SWT, wxWidgets (I can add AWT here) - only SWT is being used in Eclipse, others are pretty much dead.
So I'm really sceptical about React Native future as a replacement for native UI. It might be useful in niche areas but polished apps might be very problematic.
Couple of years ago I've spent few months digging into Appcelerator Titainum which is also based on JS and in a few of ways similar to React Native. After fixing few bugs in Titanium code base and even making myself familiar with WebKit internals I can tell that Titanium is complete a garbage without any hope for improvement. Major reason for this - they decided to run JS on separate thread for performance reasons.
First of all - I enjoy using React in browser and consider it the best browser UI tech out there. At the same time I've been working with desktop and mobile apps for past 12 years and there are things that makes me very suspicious about React Native.
1. Native apps does not have anything like browser DOM. Most of complex controls recycle views based on internal control logic. I don't see how Virtual DOM idea can be mixed with that. To make UITableView Virtual DOM aware you will have to rewrite it from scratch.
Quote from here - https://medium.com/@talkol/recycling-rows-for-high-performan...
>Recycling previously allocated rows that went off-screen is a very popular optimization technique for list views implemented natively in iOS and Android. The default ListView implementation of React Native avoids this specific optimization in favor of other cool benefits
2. Running event handlers in a separate thread is very bad idea. Appcelerator Titanium does same thing and it gave me all sorts of trouble in the past. For example - you scroll UIScrollView and it generates scroll events. These events asynchronously delivered to JS thread. JS thread change view position. UIScrollView expect these changes during scroll event not after and does not optimise for that. As a result you get gazillions layout/scroll events which kills layout performance. You also get tons of locking/unlocking as a bonus.
In Titanium delay between UI event sending event and JS thread receiving it was visible with naked eye. It was virtually impossible to create responsive UI due to these delays. React Native seems much better in this area but I suspect that complex cases like I described above will break.
3. People have been trying to build cross platform UI for decades. There are dozens of desktop technologies in this space. None of them got even close to the point of replacing native UI. Maybe React Native will be but statistics is not on their side.
Technologies which draw controls themselves does better than others which provide cross platform wrappers to native controls.
Java Swing, WPF, maybe QT - see some use, mostly in enterprise.
Java SWT, wxWidgets (I can add AWT here) - only SWT is being used in Eclipse, others are pretty much dead.
So I'm really sceptical about React Native future as a replacement for native UI. It might be useful in niche areas but polished apps might be very problematic.
Couple of years ago I've spent few months digging into Appcelerator Titainum which is also based on JS and in a few of ways similar to React Native. After fixing few bugs in Titanium code base and even making myself familiar with WebKit internals I can tell that Titanium is complete a garbage without any hope for improvement. Major reason for this - they decided to run JS on separate thread for performance reasons.
I got the feeling that it's layers upon layers of leaky abstractions and the whole thing seems rather fragile.