(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.

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!

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.

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: https://twitter.com/expo_io/status/842964876184055808

Bluetooth is near the top of our list but its complicated for a few reasons so that's why it's not done yet. (a) The Bluetooth stacks on iOS and Android are pretty different so its not easy or obvious how to unify those, and (a2) the native APIs are pretty imperative and stateful and we'll probably need to map that onto something declarative so it can work over an async bridge to work with RN (b) The use cases for Bluetooth vary widely--from BLE stuff to paired, etc., etc., (c) Bluetooth usage will typically involve stuff happening in the background, and we're still putting together background task support (though it should be available soon!) re: Making APIs available outside of Expo. We might do this! It would definitely be nice in some ways but doing that might hamper our ability to do other things well. It's something we talk about a lot, but in the context of many other considerations and plans for the future architecture of Expo.

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.

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.

Our way of planning stuff to do is probably close to what you would guess. We spend some time after each SDK release planning what we want to go into the next one. We use a variety of inputs into this, including votes from the feature request board at https://expo.canny.io/feature-requests and also just stuff we want ourselves or that is new. And from doing proactive interviews with users of Expo. We especially try to listen to people who are doing really cool stuff with Expo or building really big apps with it. Jason and I and sometimes other people have also been spending time talking to people who don't use Expo to find out what they would need to make Expo make sense for them. From there, Ben who is the team's PM and Jesse who is the team's engineering manager lead a process to take all this stuff we want to do, assess how hard or complicated it all is, and then synthesize a coherent vision for the next SDK that we then work towards. Sometimes random things happen also, like Nikki going on vacation to India and coming back having built EXGL on a lark. If you want to get stuff onto the Expo roadmap, post or vote on here https://expo.canny.io/feature-requests or if you have a longer rationale for something that doesn't fit there, post in the forums at https://forums.expo.io/