jameside

Expo Modules Core is the only module that is bundled in. It is a small runtime library that defines the Expo Modules API used by other modules, and adds about 150 KB to a production build of an app downloaded from the stores. A hello world iOS app made with Expo ended up being smaller than the same hello world app that used RN without Expo due to the Xcode settings.

There are also no custom UI controls or animation libraries bundled with Expo. The Expo Go starter app includes a preset SDK, and when developers create a build for the app stores or a development build of their own app, only the libraries they use are included.

IMO it would be a meaningful improvement for the react-native package to provide the minimal runtime needed, namely JSI, Hermes, Turbo Modules, Yoga, Fabric, and perhaps a few primitive view components like View, ScrollView, and Text. The package provides more than a library needs. Animations and gestures today are better served in my experience by modules outside of the react-native package, like Reanimated and Gesture Handler that use truly native gestures. React Navigation uses the system navigator UI and Expo Router adds file-based routing and universal links. Expo Image adds support for modern image formats like AVIF and WebP and uses mature, performant image libraries like Glide and SDWebImage. So there is definitely still work to be done that can improve quality and reduce complexity in RN.

Adding support for custom native code to Expo definitely has been a game-changer for developers. Glad it has been working well for you!

Sometimes I tell people the best Expo apps have custom native code and it is a really useful skill to know Kotlin and Swift in addition to React and JavaScript. Glad to hear you have found Expo and EAS so useful! One of the features we'll be previewing during launch week is something Pinterest has been needing for a long time, and we'll make sure you hear about it.

Infinite Red has been a great partner for Expo. Thank you!

It is technically possible, of course, though I vaguely recall iOS App Store guidelines saying not to just wrap an existing website in a webview. On the flip side, PWA support in Safari has been gradually improving with better support for web manifests and web notifications, for example.

Expo and Next.js are both React frameworks and Expo also uses React Native. Expo, Next.js: frameworks, React, React Native: libraries.

EAS CLI is designed for EAS, the hosted services. It is intended to use your EAS account, which I suspect is why the PR wasn't accepted.

Expo CLI is for entirely local builds. Run "npx expo prebuild:{android,ios}" to generate your Android Studio and Xcode projects, and build them with the IDEs or their respective CLI tools directly.

This is actively being worked on. Also a big area of investment over the past couple of years has been adding support for custom native code to Expo and the Expo Modules spec. It is easier in several ways now to write your own module when an existing one doesn't work for you.

The Expo Go app needs to connect to a server for two reasons: the server gives you a signing certificate that is used to sign your project manifest, and it also fetches the list of active and recent projects and Snacks. It is certainly not intended to be invasive.

Expo Go is entirely optional and it is recommended to graduate early on in your development cycle to using a development build of your own app instead. Development builds don't sign project manifests (unless you're intentionally using end-to-end signed updates, an advanced feature). They are like regular development builds of a traditional native app.

Also if you'd like to keep using Expo Go, the signing certificate mentioned earlier has an expiry of 30 days or so IIRC, during which time you don't need to connect to a server. You may still want to provide the "--offline" flag to turn off refreshing the certificate.

These are a few things I can say as one of the Expo cofounders. We've worked on the Expo framework for over eight years, and did R&D for a year or two before that even before React Native was released. Many other companies and frameworks, even from very large companies, have come and gone in that time and Expo has endured. Paul Graham wrote he found determination "to be the most important quality in startup founders" for what you find that to be worth.

Also from the beginning we believed the Expo framework needs to be free and open source. Introspecting as developers ourselves, we thought people would be a lot more likely to try out and recommend open source frameworks and incrementally build up an ecosystem of modules and StackOverflow answers. Expo gives developers much more agency because it is open source. And it is really hard in my opinion to make a business from licensing developer tools, libraries, and frameworks. There are so many free alternatives.

The goal of the Expo framework is to be the ultimate way to build universal, native application software. Universal apps have builds for Android, iOS, the web, and future platforms. And the user experience is truly native to each respective platform, often by using the native system UI components and not a replica. It does take significant effort to maintain the Expo SDK's set of convenient APIs. It's also just one part of Expo overall.

Separately, the way we are building a business is by offering hosted services for React Native apps, called Expo Application Services (EAS for short). These are optional services for building and updating your apps and using the Expo framework doesn't require EAS. We find developers often use a combination of EAS for some tasks and their own hardware for others.

We work to build developer trust. We are a small company but try to serve developers and our customers well, sometimes better than the companies that have endless trunks of money (we've all seen killedbygoogle.com). So, that's some of how we think about things at Expo.

We also call this idea "continuous native generation". So glad to hear it is working well for you!