(1) Some ideas: (a) make great examples of stuff using Expo that people like and make them open source so people can learn how to make them. (b) Make libraries that are compatible with expo that people can npm install, like react-native-deck-swiper (c) make videos showing how to build stuff with React Native and Expo or give talks about it at meetups, etc. (d) Submit PRs to add stuff or fix stuff

(2) A way to have a debugger running in the JS VM on the actual device and a way to connect to that from a remote server, so you could write a great debugging tool that you could have in a web browser in your computer.

(3) We are looking at it. Aside from using Dart instead of JS and a home rolled React-like component system written in Dart instead of React, the really important difference between Flutter and RN is that Flutter renders straight to GL rather than trying to leverage native OS level components or a webview or anything. There are some really nice properties to this and it might be a better approach overall, but it requires incredible fidelity to match the user's expectations. Google might be able to pull it off but even if they do, keeping up with the platforms will be tricky. I think there is about a ~30% chance that that approach turns out to be better. We'll see.

(4) Someone might be! Brent cares a lot about Reason!

We're still working on this but progress is currently stalled because Apple will sometimes reject apps if they have payments code in them but they don't collect payments, so we need to add the ability to include optional modules only sometimes before we launch this.

In the meantime, you'll just have to detach and do it yourself, unfortunately. I would look at Naoufal's payments library for this right now. https://github.com/naoufal/react-native-payments

re: not always being able to find an Expo module to do what you want to do. We're trying to solve this issue by squeezing it from both sides. (a) by continuing to support "detach" and make it better so you can write native code or react-native link native code whenever you need to. and (b) making it possible to do almost anything you want to do with just JS. For example, by continually working on improving our multimedia support so you don't need to install special modules to deal with sound or video.

For Firebase in particular, we're looking at a bunch of different options. Here is a starter snack for using the Firebase Realtime database: https://snack.expo.io/HJ1Wjg95Z

We also are looking at adding react-native-firebase in to Expo directly but there are some reasons that might not work well.

Yes, if you are based in USA then take a look at http://expo.io/jobs

What would EXPO be if Facebook reacted to ends the evolution of the RN as it did with Parse?

We have enough people who know React Native's internals pretty well that we could continue the project. This would mostly be really bad for React Native and mobile development if it happened, but we would just keep working on it. We'd probably also look more closely at competing technologies if this happened. I don't think this will happen soon. A bunch of stuff internally at Facebook is built with RN.

What is your opinion about the acceptance of the EXPO by large development companies in RN?

In general, new technologies and services are easier choices for smaller and newer companies and teams. And this is true of Expo too. Companies where they have a dedicated iOS team and a dedicated Android team aren't likely to adopt RN or Expo, except for new tools or side projects.

But as Expo has started to become the standard way to do greenfield RN apps, we've seen more big companies picking it up. There are a few things in development that I'm pretty excited about.

One good thing about being mostly client software is that there aren't too many concerns about scaling, the way there might be with a backend-as-a-service or something like that. This makes it a little easier for companies already at scale to choose to use Expo without worry.

We don't have any really formal relationship but we are friends with a lot of the people who work on React and React Native there. They are just down the road so we sometimes get together and talk about things. We sometimes ask them for help when we upstream a PR and need to get that into RN (thanks to Hector in particular!!!) We've collaborated on things in the past like create-react-native-app and yarn and I think we'll collaborate a lot more going forward.

I work from Vancouver, Canada but most of the team is in Palo Alto, California. My work day is a little different from theirs so I'll have to let someone else speak to this ;)

They vary widely. The average person shows up around 10AM though some before that and some after that. There are usually some people working from home--either from SF or out of town. People are generally pretty nice and friendly and just talk about Expo stuff all the time, with occasional forays into existentialism, cryptocurrency stuff, video games, current events, and other stuff like that.

On Thursdays, we have an all hands at 2PM. Other than that, we don't have too many structured meetings other than 1-1s.

We go out to lunch in downtown Palo Alto almost every day, unless we are in a crunch time, in which case we'll usually order in.

Here's a photo of our meeting room: https://www.instagram.com/p/BcI_DGOFLyZ/ And here's people hanging out at the old place we used to work: twitter.com/expo_io/status/842964876184055808

Our north star is to serve the people who want to make awesome stuff for phones and the people who use that stuff. We've been working with React Native since that technology has done the most to push mobile development forward in a significant way but we're always looking around at other things like NativeScript, Flutter, Kotlin, etc., etc.

We don't consider Expo to be a React Native company -- instead, we think of ourselves as a mobile development ecosystem. So, we might end up working on any of those things, though we don't have any concrete plans right now.

Hi Saket!

Are there any plans to support bluetooth and BLE via some Expo apis?

We do plan on supporting this! It's a very popular feature request: expo.canny.io/feature-requests/p/bluetooth-api

No timeline for it yet but we're making our way towards it.

Any plans for Expo or some of your apis eventually becoming separate libraries so we can only use the parts we need

Some users have started to do this , eg: react-native-camera is the Camera component extracted from the Expo codebase.

As for only using the parts you need, we plan on making it possible to opt-in to only the APIs that you need in the build step, to help reduce the size of the binary.

(even if at a extra cost per library)?

No plans for charging for that.

There's a lot of discussion around this here: expo.canny.io/feature-requests/p/native-plugins

It's not clear to me what this would look like in practice. We have been considering making it possible to inject plugins in the build step (exp build:ios/android), but not the Expo client.

Hi José! Yes we are planning on that. See my reply to Chris in hashnode.com/ama/with-expo-team-cjdqxyifm04hwt3wt…

We've been working on infrastructure and refactoring necessary to support "optional modules" -- this would allow you to selectively opt in and out of APIs to include in your standalone app. We'd also let you select which versions of the Expo SDK to include -- usually this would just be the one version that you're using.

With Expo, you write just JavaScript and can develop on Windows as long as you have an iOS device as well. When you are ready to submit your app to the App Store, you can use the Expo standalone app build service to create an IPA, the file you submit to Apple.

Hi Chris!

Yes, this can absolutely be solved. We've been working on infrastructure and refactoring necessary to support "optional modules" -- this would allow you to selectively opt in and out of APIs to include in your standalone app. We'd also let you select which versions of the Expo SDK to include -- usually this would just be the one version that you're using. More info on versions in this reply: hashnode.com/ama/with-expo-team-cjdqxyifm04hwt3wt…

Hi Anant!

This is going to be a boring answer but the truth is there is no one particular part that is / has been the most difficult. One difficult problem that comes to mind is handling versioning our native code elegantly. It's something that most people using Expo just take for granted, but there was a long period of time where the Expo client wasn't capable of doing this. The Expo client needs to support multiple versions of React Native in a single binary. If you built an app 6 months ago and want to use the Expo client to open it today, 6 releases later (we do monthly releases), it will still work. We include I believe 7 versions currently. Each of the APIs that Expo includes also needs to be versioned, and their dependencies.

Jim Lee, who is the person behind the new design -- along with design help from Bakken & Baeck and illustrations from Timo Kuilder, had this to say:

Hey great question!

Out of the many goals for our design, two stand out.

Expo has got to be a place where professionals feel like they can publish their projects and attract people who would have never crossed paths with their projects before. We think it is really cool when any creator is able to see engagement from people outside of their network, and we definitely want way more of this.

Second, Expo wouldn't be a great platform if people couldn't come to learn and get started with our tools. So we worked to made it easy to search our documentation, learn how to get started, and soon we'll make it even easier to see example code.

Over time our design will evolve with our users, and I think today we are really well positioned for that!

React Native Gesture Handler (included with Expo) is one of my favorite because it meaningfully advances the way we can compose gestures, and does so in an incremental way that lets developers migrate pieces of their app to use the new gesture system. Advancing the state of the art in a good way and heavily investing in migration paths are two great things about this library.

I also like Redux, though it's not specific to RN nor React. Redux's approach of using reducers as a chokepoint to atomically recompute state lends itself to correctness and consistency. And I find it relates to several introductory concepts covered in "Structure and Interpretation of Computer Programs" (mitpress.mit.edu/sicp/full-text/book/book.html), which is a great book for learning foundational computer science.

We didn't actually use the framework provided by github.com/facebook/react-native/blob/4454fdc219a… and just directly bind to JavaScript through JavaScriptCore's C API. Most of our GL binding code lives at github.com/expo/expo/blob/98ab9ef6a35c6d248976480…. The initialization of that is done by an Obj-C native module at github.com/expo/expo/blob/98ab9ef6a35c6d248976480…. The build process for iOS involves just adding the .cpp files as usual in Xcode (in our case we have it as a subpod), and for Android you will need to use JNI as in github.com/expo/expo/blob/98ab9ef6a35c6d248976480… and bound with github.com/expo/expo/blob/98ab9ef6a35c6d248976480… accessed from github.com/expo/expo/blob/98ab9ef6a35c6d248976480….

In terms of 'difficulty' -- it's hard to quantize since that's relative, but I would say that in the grand scheme of things the build system isn't the most difficult part, if only less defined and less documented. Actually writing the binding code is the most important bit, and is about linear in the complexity of API you want to bind. In the cpp/ directory we have some other utilities we've used in the binding.

In terms of 'recommendation' -- that's a hard judgement to make in the abstract, but concretely given a particular use case, yes it could make sense, if that is the main and only way to achieve the result you want. I would say try using the 'CxxModule' system as provided by React Native (you'll have to watch for including the headers and linking with React Native's code properly) -- we didn't do this, so have no examples to point to there. The way we did it (direct JSC C bindings) means you know exactly what's going on under the hood, which could also be what you want.

how 'bout a student who really loves programming, and would love to contribute to open source ??

Hi Jake!

How are features picked?

We pay close attention to the feature requests: https://expo.canny.io/feature-requests. In addition to that, we conduct user interviews frequently, speak to businesses who may be interested in using it or who are using it, participate in hackathons, and we build apps with Expo ourselves to get a feel for what we think it needs.

How do you discuss problems as a team?

This is a tough question to answer! Not sure I can give a concise answer to this, sorry :(

What other services do you use?

• Amplitude
• Segment
• Google Cloud
• Slack
• Dropbox Paper
• Canny
• Circle CI
• Buildkite
• GitHub (of course)
• waffle.io
• Twilio
• DoorDash :P
• Lyft
• Plenty of others..

Hi Andrés!

We're considering this. I am personally (not speaking for the team) not convinced that we need it, and I do not like having to integrate native APIs that are specific to a particular vendor (when we can avoid it). That said, there is clearly a lot of demand for Firebase (as per https://expo.canny.io/feature-requests). You can use the JS SDK for the database, authentication, and very shortly for storage (this will be available in March).

Thanks Johan! :)

Snack is a big group effort from lots of people and drawing inspiration from a lot of stuff that came before!

I made the original Snack prototype. It was inspired partially by RNPlay for sure (one of the best projects in the early days of RN!), but also JSFiddle and Codepen and every other interactive environment that I'd seen before like Smalltalk etc. I also just thought that the packager was too slow and fragile and I wanted to cut it out of the equation. That seemed easier than running a cloud version of the packager.

The prototype I made barely worked but you could see how fast it was to update, and that was exciting, so Jesse took it and made it into a real thing along with Satya.

More recently, TC along with Satya and now Nikki have picked up the mantle, adding a lot more reliability and the ability to include arbitrary npm packages. And Jimmy the intern made the thing where you can download a Snack into an XDE/exp project.

Watch out for more improvements coming along. I also am excited about taking the best parts of Snack and getting them into the command line environment and vice versa. Will take some cleverness and time to do this well though.

The first thing your question makes me think of is this open letter Steve Jobs wrote all the way back in 2010 titled "Thoughts on Flash". Mostly he was just s*tting on Flash for being slow and buggy and not keeping up with the times but there is one paragraph that's pretty interesting in it.

We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform. If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

We sort of love proving that way of thinking wrong when we can. For example, I thought it was awesome that we had ARKit support in Expo in the App Store within a week of iOS 11 (and ARKit) being released. I'd like to be able to have that near-instant turnaround with basically all new OS features, and we're thinking of ways to systematically stay on the cutting edge.

The world has become so connected and continuously updated that I think it will probably be possible to mostly achieve this over the medium term.

Also, I'm personally really excited when cool new stuff comes out for phones since that just means we can bridge it into Expo and let people make great stuff with those peripherals or features. We love doing this kind of work.

Three things I like

1. Development speed is faster than any other way to build mobile apps, and this is so important when building new stuff.
2. Flexbox was a good choice for layout I think. It's pretty intuitive compared to pre-Flexbox CSS.
3. Many people are already familiar with React, and so RN is very accessible for lots of people.

Three things I don't like

1. Takes a long time to build the initial package
2. Wish starting up JS VM and loading initial JS was faster
3. Wish debugging were better. Doing debugging by running your JS off-device inside your web browser is just kind of wacky.

Hi Linda!

The best way to get started is with React Native Express (http://reactnativeexpress.com/)! We covered most of the material from that and more in our workshop at React Europe last year, and it's all available on YouTube: youtube.com/watch

Another good resource is the "Full Stack React Native" book (https://www.fullstackreact.com/react-native/) because it guides you through several small apps. There's no substitute for this kind of practice!

When you're comfortable with the basics, be sure to learn how to use the Animated API (facebook.github.io/react-native/docs/animations.h…). For gestures, dig in to react-native-gesture-handler (https://github.com/kmagiera/react-native-gest ure-handler).

Routing and navigation is an area with a lot of active development in React Native at the moment. This is how you go from one screen to another, add a navigation back and the gesture to swipe back between screens, tab bars, etc. The approaches are: 1) re-build the navigation behavior from iOS and Android in React Native with JavaScript and React Native primitives 2) use the existing platform APIs for this. You can read more about the tradeoffs at https://reactnavigation.org/docs/pitch.html.

I hope this helps!