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 ( https://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: https://docs.expo.io/versions/latest/sdk/admob.html .)

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.

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" ( https://mitpress.mit.edu/sicp/full-text/book/book.html ), which is a great book for learning foundational computer science.

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.

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.

We thought one of the first things people would want to make were components that actually felt good on mobile and were fun to share. It would be like an expo of components = Exponent 😁

The Exponent project roadmap is guided by the needs of product engineers. The feedback and requests we get from Exponent developers helps prioritize our projects across our mobile apps, APIs, and developer tools. One part of our APIs we get a lot of questions about is native modules. Currently with Exponent, you write just JavaScript and there are a lot of nice things about that! But sometimes you need some functionality that can only be invoked from native code, whether it’s a custom native component or a native API we haven’t bridged to JavaScript, like iOS’s HealthKit or Android’s Voice Actions. The surface area of the mobile platforms is really big and we know developers have such a wide set of needs so we want to give you a way to write native code if you need to while still getting Exponent’s APIs and tools. Our approach to this is something we call ExponentView. This new API lets you embed Exponent within a traditional Android or iOS project. You keep Exponent APIs and still write most of your app in JavaScript, but since you’re working inside an Android or iOS project you can write native code if you truly need to. You also can link React Native packages from npm even if they include native code. So after you start developing on Exponent, ExponentView is your escape hatch if you find yourself needing custom native code, although we strongly recommend staying on Exponent if you can. ExponentView is currently in development and we believe it addresses a lot of developers’ needs. We also believe that many apps can be written in pure JavaScript and part of our roadmap is to bridge more native capabilities so that you don’t have to. Engineers working on Exponent are often responsible for both Android and iOS so that we give you APIs that feel coherent and expose cross-platform behavior and platform-specific capabilities for when you need them. As Exponent’s APIs have grown, we’ve seen them accommodate more and more developers’ needs. With new native APIs and ExponentView both on our roadmap, we definitely have developers in mind!