We intentionally chose to not let users drop down to native -- the idea of having an interpreted language that sits on top of a native runtime on multiple platforms is not a new one, and it allows for so many benefits that you lose out on if developers can add arbitrary compiled code with direct access to system APIs.
Additionally, there is a significant value-add of using Exponent in terms of upgrades. As great as React Native is, it also moves extremely fast and it can be difficult to keep up with new releases -- a change in React Native might cause several of your native dependencies to break, and you'll need to fork those libraries and fix them if the maintainer isn't keeping on the same schedule as you. Updates with Exponent are as simple as updating JavaScript, which has much less churn and breaking changes than the native side (the React API itself is very mature, the APIs for specific native components may change).
Another nice advantage of this is that you can work on an iOS app from Windows and Linux, because you don't need to compile your app with Xcode (we handle builds for you when you want to ship to the app store, before that you can just use the Exponent client).
We ship with a bunch of APIs out of the box and are constantly improving them and adding more. We have analytics tools like Amplitude and Segment built in, Maps, Facebook login (working on Google Login), and more: https://docs.getexponent.com/versions/latest/index.html
React Native is still very early, though, and Exponent is just a small team of seven, so we understand that we can't possibly expose every API that developers working with the platform might want. So, we are working on a way for developers to be able to still take advantage of the Exponent toolchain and layer on native code. I've written up our approach in more detail here: https://blog.getexponent.com/answered-on-slack-ejecting-from...
Interesting choice, and thanks for the detailed explanation.
Sounds like at the end of the day it comes down to Exponent being committed to the user never having to build their own app. I can see that being interesting a to a single dev, or a small app or someone new to mobile development, but to be honest I don't think I could justify using Exponent at a company. On any reasonably experienced team of developers, building an app when native components change or distributing it with something like hockeyapp is not very difficult, so I just wouldn't trade the flexibility of being able to do tricky parts directly in native code for not having to build the app.
I'll dive into your architecture more later tonight, but I'm not clear on why Exponent has to handle exposing specific APIs? Couldn't it work in the same way that React Native doesn't expose specific APIs?
We intentionally chose to not let users drop down to native -- the idea of having an interpreted language that sits on top of a native runtime on multiple platforms is not a new one, and it allows for so many benefits that you lose out on if developers can add arbitrary compiled code with direct access to system APIs.
Additionally, there is a significant value-add of using Exponent in terms of upgrades. As great as React Native is, it also moves extremely fast and it can be difficult to keep up with new releases -- a change in React Native might cause several of your native dependencies to break, and you'll need to fork those libraries and fix them if the maintainer isn't keeping on the same schedule as you. Updates with Exponent are as simple as updating JavaScript, which has much less churn and breaking changes than the native side (the React API itself is very mature, the APIs for specific native components may change).
Another nice advantage of this is that you can work on an iOS app from Windows and Linux, because you don't need to compile your app with Xcode (we handle builds for you when you want to ship to the app store, before that you can just use the Exponent client).
We ship with a bunch of APIs out of the box and are constantly improving them and adding more. We have analytics tools like Amplitude and Segment built in, Maps, Facebook login (working on Google Login), and more: https://docs.getexponent.com/versions/latest/index.html
React Native is still very early, though, and Exponent is just a small team of seven, so we understand that we can't possibly expose every API that developers working with the platform might want. So, we are working on a way for developers to be able to still take advantage of the Exponent toolchain and layer on native code. I've written up our approach in more detail here: https://blog.getexponent.com/answered-on-slack-ejecting-from...