Hi, I’m one of the co-founders of Expo and have worked on it for several years and have the context for why Expo works the way it does. I wrote a response to this elsewhere and since the author reposted this article on multiple sites I’m inlining the response so you can read it here. In short, the Expo team is definitely not looking to fool anyone and we make decisions with integrity and developer trust in mind.
I found several parts of this article to be incorrect or to suggest poor intent, which has never been the case at Expo. Developer trust is one of our greatest values so I’d like to explain more about Expo in a way that hopefully feels clear and understandable.
What is Expo? Expo is an open-source platform for creating universal native apps with React. Expo currently runs on Android, iOS, and web and by using JavaScript and React you can make apps that run in all three environments while getting access to many of the native capabilities of each of them. On Android and iOS we use React Native, and on web we use React DOM, which uses the native API of the web. Expo is not an “obfuscation layer,” though it does use Terser for web and uglify-es for Android and iOS, which minify your JavaScript.
If you’re interested more in the open-source aspect, check out our main GitHub repository at https://github.com/expo/expo! The GitHub repository contains the source code for the Android and iOS clients; dozens of libraries that provide support for the camera, A/V playback, custom fonts, and more; and the test infrastructure for the apps and libraries.
One part of Expo is the Android and iOS clients that assist you with development. These clients are optional but help manage part of the development workflow (we call this the “managed” workflow). They contain many different native libraries you can use in your projects, and when you are ready to submit to the App Store or Google Play, you can create standalone app binaries with the same native libraries.
Why does the Expo client contain the Facebook SDK? Most of the libraries we maintain are related to device functionality, like the camera, gyroscope sensors, screen brightness, and more. A small number of the libraries provide support for services like Facebook and Google Login — these libraries do include the services’ respective SDKs, including the Facebook SDK.
Expo supports Facebook Login (you can let your end users login with Facebook) and Facebook Ads (you can display mobile ads from Facebook in your app) because several developers needed the features and they are some of the most popular login and ad services. This is the sole reason why managed Expo apps contain the Facebook SDK. Facebook did not ask us to include the Facebook SDK in Expo.
Additionally, as of SDK 36, Expo configures the Facebook SDK not to send any HTTP requests to Facebook by default unless you explicitly opt in. If you don’t use the Facebook API, your app won’t send requests to Facebook’s servers.
Expo also supports Google Sign-In and Google AdMob for login and ads, respectively, as well as Google Maps. We also have a generic authentication library that works with a variety of OIDC and OAuth 2 services. In general, we prefer creating generalizable, company-agnostic libraries when we can.
To reaffirm, all of this source code is in a public GitHub repository, which is a great place to see our “cards,” to use the article’s metaphor. You don’t just get to see our hand — you can see just about the entire deck in our GitHub repos, where we do our development. And we’ll add an entry about the Google and Facebook libraries to our “Why not Expo?” page so it’s easier to see.
How can I exclude the Facebook SDK from an Expo app? Several Expo apps don’t include the Facebook SDK. You can do this with what we call the “bare” workflow, which gives you a high degree of control over bare Xcode and Android Studio projects.
In contrast with the managed workflow, with the bare workflow you can include and exclude libraries based on your needs. That is, if your Expo project is using the bare workflow and doesn’t include the Facebook Login and Facebook Ads libraries, your app won’t include the Facebook SDK unless you manually added it to your project some other way.
If you are using the managed workflow, the standalone apps will contain the Google and Facebook SDKs. This works for many developers and depending on your needs you can use the managed workflow or choose the bare workflow to customize and compile the app yourself.
What user data does Expo collect? We collect very little user data and, to our knowledge, specifically nothing that identifies individuals using Expo apps. If you use Expo’s managed workflow, apps request updates over HTTPS, and these requests do not contain unique device identifiers. There are many, many apps made with Expo published to the App Store and Google Play without issue and with respect & regard for user privacy. We also have a privacy policy on our website.
Does Expo collect Advertising IDs? The vast majority of Expo apps do not collect advertising IDs, and Expo (the company) does not collect nor use these IDs ourselves. Android and iOS both have advertising IDs, as mentioned in the article. They are used by the libraries for displaying ads (Google AdMob and Facebook Ads) and the Branch library. If you don’t use these libraries in your project, the advertising ID never leaves the user’s device and no service collects it.
One thing I want to be clear on is that Expo does not make money from ads. The ads libraries are solely for developers who choose to display ads in their own apps. We do not display ads to developers nor end users.
How does Expo make money? Generally, our plan for the business is to build services that help developers make and operate their apps. We’ve started with Expo Developer Services, a monthly plan for some services for making apps.
One of the features of this plan is that you get priority access when building your app binaries with the managed workflow. As Expo has grown, more developers are now submitting more builds, which requires more servers that are fairly expensive to operate. We introduced priority builds as a way for business users to help cover the server costs for building apps, which lets us in turn buy more server capacity. Fundamentally, the server cluster is a finite, shared resource and we think it’s fair that those who are paying for it get priority when using it. If you find that your build is taking too long, you can use the bare workflow and build your app binaries on your own computer (you’ll need a Mac for iOS builds).
We strongly believe in keeping the Expo platform free — keeping it free to make an Expo app on your own computer, similar to how it is free to build a web app on your own computer. It’s important to us that students can use Expo for class projects and that developers at companies can try Expo without getting a budget approved up front. We believe this is the best way Expo can succeed.
Like the web platform, we want making Expo apps to be free. And like the web platform, we want developers to be able to use whichever hardware or service providers they want to use. And like the web, some of those service providers cost money if you choose to use them.
These services are optional and part of the managed workflow — Expo manages various parts of app development for you — but you don’t need to use them with the bare workflow. That said, operating services like the app builders and over-the-air updates costs a meaningful amount of money added up across all the apps that use our services. To offer these services in a sustainable way and deliver the high performance and high reliability that projects need, we have to charge for them. There are no disingenuous motives, it’s simply reality. A lot of developers we talk to actually understand this intuitively and tell us they’d feel even better about building with Expo if they could pay for the services they are using. Directionally speaking, Expo services will be more like AWS, for example — there’s a free tier for smaller apps and for larger apps you only pay for what you use.
In summary, the Expo platform is free and open source. You don’t need to pay Expo to make an app, nor do you need to use any of our services. We’ve invested, and will continue investing, much of our time into the bare workflow so you can build your Expo apps on your own computer, host your over-the-air updates on your own web server, use your own push notification service, and so on.
In addition to the Expo platform, we operate and are working on next-generation, optional Expo services to manage parts of your development workflow for tasks like building your app binaries, deploying high-efficiency over-the-air updates, and sending high-volume push notifications. The next generation of these services will take meaningful time to develop and we don’t have a pricing model yet, but we think that AWS’s pricing model works well for a lot of people by aligning our costs with developers’ and charging only for what people use.
Lastly, I want to be unequivocally clear that developer trust is incredibly important to us and we look to do our work with integrity and quality. We made Expo open source, are working on a sustainable business model, and write posts like this to build that trust over time. Our decisions may not resonate with everyone, but this is how we do our work on Expo.
