I think that over the next few years, almost everyone making mobile apps will be using something like React Native/Exponent.

It's too much trouble to worry about iOS and Android separately. It takes more time and money. So I think we'll see most people who are Swift developers or Android Java developers move over, slowly. And most people who are new to mobile will just start with React Native/Exponent (or something else like it that might come along).

There is some chance that the mobile web gets good enough that that becomes a viable alternative--every time phones get faster, this gets more and more reasonable. But I think using the mobile web for apps is still pretty far away from feeling really good and not moving that fast towards getting there, even though Ionic is a good effort and people at Google and elsewhere have been doing a lot of good work to improve PWAs. The last really lauded web app I saw was Lyft's PWA, which I think falls into this valley of "I'm really impressed; I don't think I could build something that good and slick" but at the same time noticeably not as good as the native mobile apps Lyft already has. Web technologies evolve pretty slowly--for good reasons!--and so I don't expect this to be awesome soon.

I also think the building blocks of mobile aren't all supported really well by the web. If you look at the newer apps that are super popular--Snapchat and Instagram--they are very image and video focused. The building blocks of mobile web and even React Native aren't good enough to do the things you want to do with photos and videos yet, and they'll need to be in order to let people build the things people want to do on their phones in the future.

For games--at least games like the current set of games that fill the app stores--people will probably continue to use Unity for most things which seems to work well and most people seem to like.

There are some pretty gnarly problems with distribution, etc., but there are some interesting things on the horizon to address that, like Facebook Messenger Instant Games. I don't know how that will play out.

Yup, they are great people that I feel really honoured to be able to collaborate with and learn from. We are working on a project alongside them right now to make the initial React Native getting started experience easier! The goal is to reduce the TTHW (Time To Hello World), which is currently absurdly high because users need to install Xcode or Android Studio.

We also discuss pull requests that we think need attention or that they want us to comment on, roadmap, problems that we run into building apps with Exponent (or that our users run into), and all sorts of other things. You can see some of the discussions on this Facebook group: https://www.facebook.com/groups/reactnativeoss/ -- we also chat a lot in Messenger.

A short version that leaves out a lot!

James Ide and I had a vague idea that mobile development was too hard and that someone should make it better, so we started researching the problem a few years ago.

I had managed the mobile teams at Quora but hadn't actually done much native mobile development myself. And James had mostly done web stuff at Facebook. So we experimented a lot with trying to make HTML5 perform really well and decided it wasn't going to work and then built an implementation of NodeJS for iOS on top of JavaScriptCore that would let you control native views from JS and we started to build stuff with that. One of our guiding ideas has always been that we want to make doing mobile development easier than web development.

When React Native native came out, we realized it was basically the exact same approach that we'd been taking but was a little further along. Since it was open source, we just decided to use it as the basis for everything else that we wanted to do. We built a very rough MVP of Exponent that we could show people and then we joined up with Brent, Jesse, and Nik. And later Ben, Skevy, and Adam and Jess to make it into something real.

And there is a great community of people who are interested in this stuff now that we've been able to collaborate with. Some of those people help make Exponent better like the team at Facebook who works on React Native (hi girls and guys!) and Janic and Satya and Tienson. And also developers who are making super cool stuff on Exponent. One of my favorite feelings is when I see something nifty that someone made with Exponent and our work feels like a part of making that happen.

Hi Hamish! I answered this one here: hashnode.com/ama/with-exponent-ciw1qxry118wl4353o…

Short answer: you are totally safe using it. The beta flag is with respect to the pipeline itself, and not the end product. If you run into issues we are very fast to solve them. We want to help you build and ship awesome apps.

The first thing we thought we could use it for was an gallery of React Native components. Or, you might say, an "expo" of "components" --> exponent.

We also liked the idea of a non linear increase in developer productivity and thought it sounded cool! It has the right level of nerdiness for a product that is mostly about software developers.

After that, we spent a couple of nights trying to think of a better name but we couldn't come up with anything better so now we're kind of stuck with it.

We update about every month. Currently we're on React Native 0.36, tomorrow we're submitting an update to the app store with 0.37. So we're usually at most 2 versions behind, although we cherry-pick in any very useful and stable commits in advance. For example, we had native animations on Android for months before they were in React Native core. There are talks about changing the React Native release cadence from bi-weekly to monthly, in which case we may adjust our release cycle to align more closely with it.

Nope! We instead give you a way to build binaries to ship on the App and Play Store :) Check it out here: docs.getexponent.com/versions/v11.0.0/guides/buil…

We are currently 8 people (3 of us are React Native core contributors) and 4 contractors (3 of them are also React Native core contributors). Despite the small team we take support very seriously so join our Slack and ask us any questions you have, we're happy to help :)

It's conceivable that we will create some example repos for these, eg: https://github.com/exponentjs/hello-graphql shows you how to set up Exponent with a GraphQL backend, using Apollo Client. We currently have a blank, tabs (with some other features such as push notifications pre-configured) and a game template (https://github.com/exponentjs/game-template).

It would be great for the community to create some of these templates as well, we're still a small team of 8 and building and maintaining a bunch of these could add a lot of overhead.

We'd love to support all those platofrms, but we have a small team and our focus is entirely iOS and Android right now. And it will probably be that way for the medium term as well.

It works well and lots of people do it :) You probably noticed that our docs (docs.getexponent.com/versions/v11.0.0/guides/buil…) mention that it's in beta -- perhaps we should clarify that it isn't related to the actual build product but the infrastructure itself. For example, we just pushed an update last week to make the error messages fantastic when a build doesn't work for some reason (invalid credentials, too many certs on Apple developer account, etc). You still need to download the ipa and apk files manually from a link that's shown to you on the command line and run exp build:status to see updates in the build process.

So it's marked beta because the process of building doesn't feel as smooth and streamlined as it will in the future.

Not yet. We've listed a few things here: http://github.com/exponentjs/awesome-exponent

We want to compile a full directory and make it available soon. It's really fun to see and test out other people's projects, and I want the whole community to share in that feeling.

@ide is answering this one in hashnode.com/ama/with-exponent-ciw1qxry118wl4353o… :) Expect an answer from him shortly!

Hi Vojtěch! The roadmap is referring to "react-navigation" - what we believe and certainly hope will be the end of navigation related API thrashing in the React Native community. ex-navigation is going to stick around until we’re confident that react-navigation can fully superscede it. We are working on providing a clear migration path from ex-navigation to react-navigation, but understand that not everybody can migrate immediately because neither can we, and we use it on several projects. If for whatever reason ex-navigation users decide that they would like to stick with it, we could hand the project over once react-navigation has surpassed ex-navigation in terms of stability and feature completeness.

it's not on our list currently since not too many people have asked for it, but we're not against it.

In general, we want to give developers access to all peripherals and sensors through JavaScript. But since there is often an art to crafting the API that's exposed to JS (since there will be overhead in making each roundtrip across the bridge), we try to ground our APIs in real user use cases rather than just making them before we have a bunch of requests for something with clear goals that we can understand.

One thing that's tricky about HealthKit in particular is that it doesn't have an exact analog on Android (though there are some similar things on some Android phones I believe). We try to make all our APIs work the same on both platforms whenever possible, and it's not totally clear what that means here or what cross platform developers would want.

Let us know more about your use case and that will help shape the way we approach HealthKit! Though it probably isn't something we'll work on in the next few months.

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!

We currently recommend @exponent/ex-navigation, but we are working with @evv at Facebook (who wrote Navigator and NavigationExperimental) to improve on the ex-navigation architecture and create a single "blessed" library for navigation, called react-navigation. See: github.com/facebook/react-native/wiki/Roadmap

We'll be providing a migration path from ex-navigation, so there's no harm in using that today.

Eat your vegetables

I think React Native works great already for many applications. Some things that are preventing it from gaining even wider applicability and adoption, I believe, are:

1. ListView: no view recycling, so certain things (eg: contact views) are difficult and others (eg: feeds) use tons of memory.
2. Gestures: difficult to have related gestures on a view, needs to be written monolithically right now using PanResponder.
3. No high-quality, blessed solution for navigation -- this is problematic because the fragmentation leads to duplicated efforts and lots of confusion for newcomers. This is being addressed with react-navigation: github.com/facebook/react-native/wiki/Roadmap
4. Many one-off native implementations of components that should just be implemented in JS. Often this is done because of some current limitation in React Native. For example: github.com/exponentjs/exponent/issues/14 -- rather than implementing a custom activity loading spinner natively, it would be better for people to find the underlying reason why they think they need to do that and resolve it. In this case it would be implementing Animated.loop and supporting useNativeDriver: true on it. This leads to people installing tons of libraries that end up not being maintained and having many more native dependencies than they need.

Hey- good question.

We don't want to charge developers to use Exponent for a couple of reasons.

I think back to when I was 14 and was learning how to program and didn't have any money or a credit card, but was able to make some basic websites with free tools and resources that were available. If we made Exponent something you had to pay for, all kinds of kids and students and hobbyists would miss out.

The second is that I don't think it would work to charge developers to use it. There are enough good free tools out there that I think it would be very hard to charge a seat license for something compelling in this space.

What I think we can do instead is eventually help developers make money, and make a little bit ourselves if we do a good job of that. This is sort of like how YouTube makes money when people who make videos make money but doesn't charge anyone to upload videos or use it.

In the meantime, we have a small team and we keep things pretty lean so that we can stay focused on just building great tools for the moment instead of trying to make money on this just yet.

There's no particular commit I can point to and say that I'm most proud of this thing. I think that a lot of open source work is about grinding away together at a big problem -- fixing bugs here and there, adding a feature that you need, updating some documentation that you saw was missing. There's also a story beyond the commits themselves -- @ide and I have spent countless hours helping people on issues, discussing React Native with people at Facebook and in the community and pushing forward various initiatives to improve it, in particular to make it more powerful without forcing you to drop down to native code.

There are so many!

Some things that I've come across lately that I think are well done are:

• now & next from Zeit (instant deployment for node, universal JS application framework).
• Sentry & Amplitude - really nice error logging and analytics respectiely
• BuddyBuild & Fastlane. You mostly don't need these if you use Exponent, but if you are doing old school native mobile development, these tools can help you a lot. We use Fastlane.

We are actively working on this! See: blog.getexponent.com/answered-on-slack-ejecting-f…

To summarize:

• Exponent is open source, so you can take the code anywhere with you
• But that isn't always super convenient, so we're building a way for you to partially "eject" -- so you can continue to use most of Exponent but still have Xcode / Android Studio projects and add whatever native modules that you like. Our rough timeline for this is January.

Exponent is not the right fit if my project requires custom native modules.

Which ones? :) This will be less of an issue after we release eject: blog.getexponent.com/answered-on-slack-ejecting-f…

Which other use cases might Exponent not be a the right fit for?

The only other use case I can think of is if you want to deploy apps privately and host them on your own servers. Currently we (well, Amazon) host your JavaScript bundles and assets, but this may become optional in the future.