Ask anything to Expo Team

19 February 2018, 7:00 pmAsk Question

Expo is a free and open source toolchain built around React Native to help you build native iOS and Android projects using JavaScript and React. Ask anything to the team.

Ask Expo Team about:

  • React native
  • Building apps using Expo
  • Current state of hybrid apps

Hosted by:

Kashish Grover's photo

Hi guys! Thank you so much for this AMA. I am a huge fan ❤️. Here are a few questions that I have:

  1. Where is Expo headed? How will it monetise the product considering it is free and open source? 💸

  2. What does it take to be a part of the Expo team? 😄

  3. Do you plan to implement an end to end solution where Expo provides a pipeline to the app stores directly? I am talking in the terms of a Continuous Delivery platform where my build will directly be pushed on the App Stores once it is ready. 🤔

  4. Right now anything I build in Expo has a file size of about 26 MB. I read on your website that "this is because Expo includes a bunch of APIs regardless of whether or not you are using them". Is this something which can be solved someday? 🗄

  5. What is your take on React Navigation Library? Even though it is the one recommended by Facebook, certain GitHub threads for it are simply rants. I also see @brentvatne actively contributing to it. Do you see it being the perfect RN Navigation solution in the future? 🧐

  6. What does Expo team do for fun fun? 🤪

  7. A few months back, Expo experienced a down time where users could not login. What exactly happened? How did you all deal with it? 😯

  8. Redux or MobX? 🤓

Thanks for making Expo. Cheers. 🍻

Show +1 replies
Brent Vatne's photo

Hi Kashish!

What is your take on React Navigation Library? Even though it is the one recommended by Facebook, certain GitHub threads for it are simply rants.

The project has suffered over the last year from a lack of ownership. Some unfortunate circumstances led to the two creators of the project not working on it anymore, and it was being kept afloat by some generous volunteers but they didn't have a lot of time to dedicate to it.

One of the creators, Eric Vicenti, has since rejoined the project and his time working on it is being sponsored by Expo. I've also joined the project and I'm working on it close to full-time now.

I also see @brentvatne actively contributing to it. Do you see it being the perfect RN Navigation solution in the future? 🧐

My take on it is this: there is no perfect solution.

Many people will want to use the native APIs provided by the platform, and they will be willing to have to dig into ObjC and Java when they need to for further customization. React Native Navigation is a fantastic solution for these people, because most of it lives in native code and it leverages the native navigation APIs.

Many people will want to have the navigation APIs written from the ground up in tools that they understand, and in a way that is completely reusable across platforms. React Navigation only go into native when we find the React Native primitives available us to be lacking. For example, we worked with Krzysztof Magiera a couple of years ago on useNativeDriver support for Animated so that we could do the screen transitions on the main thread, and he has recently landed a change to support "Animated tracking" with the native driver, which will allow us to implement gestures that are handled entirely on the main thread. And because the logic (rather than the primitives) are implement entirely in JavaScript, users can customize, extend, or fork the implementations to suit their needs. They can write their own custom types of "navigators" and integrate them with React Navigation as well.

There is room for multiple APIs in this space. Read about the pitch & anti-pitch for React Navigation here:

Kashish Grover's photo

Tinkerer 🔧 Member of Technical Staff @ThoughtSpot 👨🏻‍💻 Drummer 🥁

Thank you so much, @ccheever and @brentvatne for your detailed responses. ☺️

Michel Martinez's photo

Hi guys! First of all thanks for your work, it really helps a lot :) But I have a question, do you intend to work with other frameworks in the future? Such as NativeScript, Weex, or NativeScript-vue

Charlie Cheever's photo

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.

Nikhilesh S's photo

No particular plans on other frameworks than React Native at the moment, but we are open to it if it becomes important to! Our mission is to support mobile development in general, and we went with React Native when we started.

Linda Campbell's photo

What tips would you give to someone who is just starting development using React Native in 2018?

Brent Vatne's photo

Hi Linda!

The best way to get started is with React Native Express (! 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:

Another good resource is the "Full Stack React Native" book ( 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 ( For gestures, dig in to react-native-gesture-handler ( 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

I hope this helps!

Mark Sen's photo

3 things you love and 3 things you hate about React Native?

Charlie Cheever's photo

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.
Andrés F's photo

Hi Guys! thanks for your hard work on Expo.

I would like to know if expo has plans to include "react-native-firebase" into the core?

Many thanks

Show +1 replies
Charlie Cheever's photo

I'm hoping we can put it into the SDK 27 release.

This is a super popular request. We only haven't done it so far because (a) you can do a lot of the things people want to do with Firebase with just JS, esp. now that blob support will be available soon, and (b) there is some complexity with integrating it into Expo, and (c) push notifications just won't work with the Expo model since we can't give out the APNS tokens for the Expo client app to everyone, for example.

But I think it still makes sense to do it so we'll do it soon (unless there are unforeseen complications which there often are with software!! And no promises on date, etc. Just telling you what I'm hoping for.)

James Ide's photo

Working on Expo, a mobile platform to write native apps just once with JavaScript.

As part of the React Native community, we worked with other community members (Philipp from Silk Labs, Satya from Callstack, and Janic from App & Flow) to land preliminary support for Blob uploads in React Native 0.54, which is currently on npm as a release candidate. Support for Blob uploads is by far the most popular Firebase-related request and will let developers upload images to Firebase. We expect Blob uploads to be part of SDK 27.

José Naves Moura Neto's photo

Are you planning some kind of "plugin" feature where 3rd party (developers / companies) can bring their "native modules" to Expo?

Brent Vatne's photo

There's a lot of discussion around this here:

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.

Joy Dasgupta's photo

Hi awesome Expo team!

I love what you guys have achieved so far! Congratulations! 🎉

What are the few limitations/restrictions of building React Native apps using Expo in 2018?

Charlie Cheever's photo


We wrote up a page in our docs address this:

Here are the high level bullet points:

  • Expo apps don’t support background code execution
  • not all iOS and Android APIs are available in Expo (in particular, payments and bluetooth and real time video streaming are still in the works)
  • If you need to keep your app size extremely lean, Expo may not be the best choice
  • If you know that you want to use a particular push notification service

There are also reasons why you may not want to use React Native. For example, if you are doing some kind of real time fluid simulation, or having the fastest possible cold boot time is critically important.

We have plans to address all of the things listed above but it will take us a little bit of time.

Anant Kumar's photo

What was the inspiration behind Expo's new design? 😁

Charlie Cheever's photo

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!

Chris Geirman's photo

I would like to tease out one of Kashish's (many) questions because I think it deserves to be addressed on it's own.

> Right now anything I build in Expo has a file size of about 26 MB. I read on your website that "this is because Expo includes a bunch of APIs regardless of whether or not you are using them". Is this something which can be solved someday?

Brent Vatne's photo

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:

Jake Davis's photo

Thanks for your amazing work, Expo Team!

I would like to ask about development workflow of the service for example:

• How are features picked?

• How do you discuss problems as a team?

• What other services do you use?

Brent Vatne's photo

Hi Jake!

How are features picked?

We pay close attention to the 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)
  • Twilio
  • DoorDash :P
  • Lyft
  • Plenty of others..
Charlie Cheever's photo

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 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 or if you have a longer rationale for something that doesn't fit there, post in the forums at

José Naves Moura Neto's photo

Hi, greetings from Brazil ! Thanks for Expo - it's amazing product !

Are you planning to create some kind of modular dependencies? I mean, the SDK are getting bigger and bigger, and I would like to chose what features I need from Expo SDK.

Brent Vatne's photo

Hi José! Yes we are planning on that. See my reply to Chris in

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.

José Naves Moura Neto's photo

What kind of support does Facebook offer to Expo?

Charlie Cheever's photo

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.

Adam Wilson's photo

I would like to ask about creating cxxreact type modules, as you have done with your OpenGL module. Was it difficult to integrate, and would you recommend this approach for integrating a cross-platform C++ library into React Native?

Nikhilesh S's photo

We didn't actually use the framework provided by and just directly bind to JavaScript through JavaScriptCore's C API. Most of our GL binding code lives at The initialization of that is done by an Obj-C native module at 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 and bound with accessed from

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.

Nandan N's photo

Is it at all possible to build for iOS using a Windows machine in React Native (and Expo)? If not, is this something Expo could potentially target someday, or is it something that Apple will never allow?

James Ide's photo

Working on Expo, a mobile platform to write native apps just once with JavaScript.

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.

Brent Vatne's photo

Yes this is possible with Expo! The native builds run on our servers, so when you run exp build:ios it builds your JS bundle and asset manifest, uploads them both to CloudFront, then kicks off a build job on MacStadium. When it's done, you can download the binary and upload it to iTunes (it may be possible to upload without a Mac, I am not entirely sure). This is only needed when you're ready to ship to the App Store, and before that the workflow is no different between a Mac and Windows when using Expo. Read more about this in our docs:

Using React Native without Expo, you can't really build for iOS without some likely painstaking workarounds involving provisioning your own mac cloud instance.

Anant Kumar's photo

What was the hardest part of developing expo? Which feature took the most amount of effort and time? :P

Brent Vatne's photo

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.

Ajay's photo

What is the average workday like at Expo headquarters?

Brent Vatne's photo

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 ;)

Charlie Cheever's photo

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: And here's people hanging out at the old place we used to work:

Sezgi Şensöz's photo

Hi guys! I'm huge fan of Expo!!

First question is:

I would like to ask you, if we need to Detaching to ExpoKit for some npm modules why we need expo? Actually i don't want to touch native iOS or Android layer. But sometimes it is hard to find module for expo compatible.

Second question:

Of course it is hard to cover all issues but some are really important. For example I'm using firebase features like realtime db etc. But i also want to use Firebase analytic (instead of google analytic), app indexing, admob etc. I believe these kind of features have to be in Expo. What you think about supporting firebase features?

Charlie Cheever's photo

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:

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

James Ide's photo

Working on Expo, a mobile platform to write native apps just once with JavaScript.

1.) When you detach and use ExpoKit, you retain most of the Expo SDK (like Expo Graphics, Audio, and Camera) that doesn't depend on Expo services. So if you use any of these APIs after detaching, you'd still want to use ExpoKit.

You also can use Native Directory ( to find libraries that are compatible with Expo. Library authors indicate which platforms they support, making it easier for developers to filter by libraries that support Expo.

2.) We would like to support several Firebase features if we can do so in a useful and sustainable way that keeps Expo APIs stable over time. Some features like App Indexing are also more challenging to implement because they are only possible in standalone apps, in contrast with the Expo client. (Since you mentioned it, you may find Expo's support for Admob useful:

Sarath C's photo

How Expo team embraces the changes in platforms, especially on iOS side, where you get hardly get 3 months from the time of WWDC to iPhone and other devices launch in Sep-Oct time frame?

Charlie Cheever's photo

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.

Brent Vatne's photo

Three months is a lot of time! There aren't too many changes on each release, and many are just handled upstream in React Native for us. It really depends on the types of changes. For example, navigation related changes need to be handled in react-navigation.

Johan's photo

Hello! I’m fan of Expo! Been following you since you started!

What’s the story behind Snack? I was briefly a contibutor of React Native Playground and I felt that Joshua (original creator, I think) had built something really awesome and I wanted to contribute by redesigning the layout which turned out to be really cool (at least I want to think so xD).


Charlie Cheever's photo

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.

Karan Sharma's photo

What are some of your favourite RN packages and why?

James Ide's photo

Working on Expo, a mobile platform to write native apps just once with JavaScript.

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" (, which is a great book for learning foundational computer science.

Brent Vatne's photo
  • react-native-gesture-handler - great gestures have never been so easy.
  • react-native-vector-icons - of course
  • react-native-animatable - super simple to drop in animations
  • react-native-paper - still early for this but I'm excited for it!
  • react-native-camera - we re-built this for Expo and people liked it so they pulled the native code out of Expo and into this library
  • react-native-tab-view - excellent
  • gl-react - it's good

plenty more that I haven't listed here!

Moses Paul R's photo

How does one become part of the expo team ??

Show +2 replies
Moses Paul R's photo

I got three out of four though, ( prolific open source contributors, voracious consumers of sci-fi, explorers of good music ). Yet to go to a University though.

Hannan Zubair's photo

Is Expo looking to hire interns?

Brent Vatne's photo

Yes, if you are based in USA then take a look at

Sezgi Şensöz's photo

Hey again!

What you suggest for in app purchase for IOS or Android? I checked before you are currently working on this feature. So far, is there any suggestion?

Thanks :)

Charlie Cheever's photo

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.

Cem Turan's photo

👋 Hi team!

1) What can the community do to help you in the great endeavor that is Expo? (besides using it)

2) If there's one feature you could wish for and have it "magically" appear on the RN and/or expo codebase what would that be?

3) Have you tried out Flutter and if so what are your takeaways.

4) Are you working on ReasonML bindings for expo?

//Stay awesome! ❤️

Charlie Cheever's photo

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

Saket Tawde's photo

Hi Expo Team. Love your work. Are there any plans to support bluetooth and BLE via some Expo apis?

Any plans for Expo or some of your apis eventually becoming separate libraries so we can only use the parts we need (even if at a extra cost per library)?

Brent Vatne's photo

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:

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.

Charlie Cheever's photo

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.

Felipe S. Santos's photo

Hello EXPO team, Congratulations on the great work done so far!

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

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

Charlie Cheever's photo

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.

James Ide's photo

Working on Expo, a mobile platform to write native apps just once with JavaScript.

1.) React Native is different from Parse in that RN is a library, while Parse was a service. All Expo apps made with React Native would continue to work if Facebook were to stop contributing to the project, and several other developers (including the Expo team) would likely continue to contribute to React Native.

In addition, Expo uses React Native as one of its libraries, but Expo is much more than React Native. We use React Native since we believe it is well-suited to building applications and we want to help grow the ecosystem and hope it continues to grow healthily. But React Native is just one piece of Expo and while we hope React Native continues to succeed, we'd work on making Expo work if React Native's momentum were to change.

2.) We definitely want to support larger companies that need to build mobile applications. One way I think about great technologies is that they're easy to learn and also have high ceilings that accommodate use cases we can't anticipate. The latter is especially important for professionals who are looking to build world-class software and accomplish their business goals.