The hosted services offered by the Expo team called EAS has an implementation of an updates server that conforms to that protocol. If EAS went away or you wanted not to use EAS, you could write and operate your own server that conforms to the protocol instead.
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.
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.
Modern Expo is very different and in 2023, Expo has full support for custom native code and isn't a layer, so to speak. Ejecting is gone. React Native has also become much thinner in several ways. For instance, developers write Kotlin and Swift with the Expo Modules API and uses JSI (RN's "JavaScript Interface") to directly bind the native methods to Hermes JS methods.
Relatedly, the developer demographic has grown and a lot more developers are adding Kotlin and Swift to their skill sets. They write JS and React most of the time while also writing custom native code when they need to. Most of the best Expo apps include custom native code.
Test frameworks have also grown a lot. I suspect the issues with Detox were often from developers looking to use it with the Expo Go starter app that doesn't support custom native code. These days I hear a lot of positive things about Maestro as well and there was a nice talk on it at App.js Conf earlier this year: https://www.youtube.com/watch?v=uoCzBdFCoqc
I'm glad to hear the tech and, more importantly, the community have improved.
By "layer", I mean custom controls and animation toolkits that get bundled in an Expo-enabled project. Those are in addition to the RN-provided ones. It all adds to complexity.
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.
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.
Looking to always learn new things is great. If you find yourself looking to try out Expo and have completed the first setup steps, I'd suggest looking at making a development build of your app and the Expo Modules API for writing Kotlin and Swift code.
Almost all of the best apps made with Expo also have a small amount of custom native code. And I find it's just generally good to understand the abstraction layer above and the abstraction layer below the one you're working at to bring the two together the best you can.
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.
